Google Plus: Modeling Real Life Social Interactions

While the service may be in its infancy, I think G+ shows some real promise. Of particular interest to me is the ways in which the Circles feature models social interactions from the real world. I believe that in this aspect it is far better than Facebook, though it will take time for these interactions to click with users.

Circles: Just Like Real Social Circles

Quickly, think of one of your real life social circles. For most people, they will think of a group of friends, coworkers, or family that is tight knit and perhaps share some commonality. In many circumstances, these people will show up in multiple circles. G+ models this perfectly. You can easily take a person and put them in as many circles as you'd like.

Again much like real life, that person doesn't know that you consider them part of a particular circle unless they know implicitly or you tell them. That person may be on your "frenemies" list. Perhaps you only consider them to be an acquaintance (we'll get back to this) but you don't want them to get the wrong idea that you're keeping them at arms length.

You may never use this feature to its full potential, but one of the aspects of social software is that it allows you to organize and catalog your life in new and novel ways. The implementation on G+ is both easy and visual. You may learn something about how you think of your friends by attempting to put them into circles.

Sharing Controls Allow More Frank Conversations

When you share something on G+ a key feature is that you can easily limit or expand the scope of sharing. I know some people consider this to be a confusing extra step but it is necessary to model these interactions. It allows people to conveniently have separate social circles that need not often interact.

Think about it, is your mom or boss on Facebook? This answer is increasingly "yes." With Facebook's privacy settings it is complicated to avoid sharing sensitive information with these people. It's likely none of your boss's business that you were out partying all weekend, but it is so easy to inadvertently tell her just that. In order to avoid this you must either not befriend these people on Facebook (smart, but sometimes awkward) or go through a fairly unintuitive procedure to modify who can see a particular post. It's not impossible, in fact I have custom security settings that keep several people who are officially "friends" from seeing the content on my wall, but it is nowhere near as intuitive nor as central as it is on G+.

As an aside, I think that Google is placing their bets that by enabling you to have more control over who sees what info you will in turn feel more comfortable sharing things. If that becomes true then people who share relatively little now could find new life in a product like this. Also, I should note, the addition control is not absolute. Just like in the real world, if you say something to anyone then that person has the ability to share that information. Digital communications are easier to copy and verify, so it's not like this would give you carte blanche to trash talk your employer or openly cheat on your spouse.

Dealing With Acquaintances and Beyond

The way Circles work will allow for far less awkward interactions with people you don't know or don't know well. If a random person adds you to a Circle, you can simply ignore it and they will only see public posts. Any posts they share with you will go to your Incoming page. You simply don't have to see those people, and it requires no action on your part. Sure, you can block them if you really want. A better strategy would be to simply treat public posts as you would any other public speech and not say anything too personal or socially unacceptable and you don't have to do anything about them.

Say that guy you met at the party last weekend adds you, and you might share some stuff with him based on what you know about him but you don't want him to know too much about your personal life, then file him under Acquaintances. When you share personal info don't share it with Acquaintances. Or create another group that's even less intimate. Chances are that most sharing of this sort barely has a real world model because many acquaintances don't have frequent interactions after the fact. So even if you never share anything with these people you shouldn't feel bad about.

A Conversation With a Circle

In the real world it is unlikely you will have a chance to talk to people from all of your social circles at once more than a few times in your life. The one time this is likely to happen, at your wedding, is something that many people only have happen once, and others only a few times. Good luck getting your coworkers to buy you a fourth wedding gift.

Instead, you probably have conversations with a one circle of friends at a time. It's likely that you tell these groups many of the same things, but you probably choose not to tell certain groups certain things, and other times you probably change things slightly to match the group. Each group likely reacts differently, even if similarly, to the same conversation. Sometimes, you would tell two people the same thing, but not when they are in the same room. That's how social dynamics work. It's a dynamic that Facebook breaks and G+ models somewhat correctly.

For some people, Facebook has changed this social dynamic forever. Any public announcement will be just that: public for all and for all to comment on. They probably value the varied interactions of their different circles of friends meshing together. Fortunately for these people, G+ offers the "My Circles" and "My Extended Circles" sharing settings, not to mention "Public".

For everyone else, the genie can be put back in the bottle. If you have a conversation with one group of friends no one else need know. You can have the same conversation multiple times shared with multiple groups and avoid any interaction.

Why would you want to do this? Well, maybe you want to give your close friends a low down on your trip to Cancun, but you want to share photos with your family. You don't want your rowdy friends commenting where Granny can read. Or, maybe you know people from Ohio and Michigan and you want to discuss the fine mess that OSU's football program got itself into but you'd rather it not become a huge flame war.

A Conversation From a Circle

Here's another key difference. Right now G+ does not have a "wall" that anyone can write on. Some people think this is terrible, others love it. I like it because it gives me control over who sees what my friends say to me. However, the real benefit of this is that it models how interactions from a circle of friends to you work in the real world.

If you're hanging out with a circle of friends one of them might say something to you that everyone in the circle can hear. This could strike up a conversation within the circle, and maybe it's a story you would recount later to others but people outside the circle would not likely be involved.

How you model this in G+ is to make a post directed at your circle and tag the person you are speaking to. This will allow your mutual friends to comment on this post. If your friend wants to share it more broadly he can do so by clicking Share and selecting more of his circles. By sharing it with your mutual circle of friends you can have the same sort of intimate, candid conversations you would have in the real world. If it's something you want more people to talk about you retell it by sharing, the same as you would need to otherwise.

This again empowers you to control who sees what information. If you think about Facebook's wall, the idea of allowing someone to write on your wall is like asking for someone to write graffiti on your house or draw a penis on your forehead. Sure, it's also like having them sign a cast, but even then they normally ask permission. Think of resharing as your wall plus asking permission.

Public Speaking

Public speaking is something that Twitter does pretty well. Conversations on Twitter are so disjointed that it is more a broadcast platform than anything else. Of course, conversational discourse is kneecapped on Twitter due to the size limitation. Facebook makes most of the things you say into a semi-public event that is invite only. Unless your profile is open to the public only your friends will see it, but then those people not in your friends list can't interact with it. G+ is modeled a little bit after both services, allowing you to have both private and public conversations. However, G+'s public conversations are far superior to Twitter and more shareable than Facebook.

Anything you post that is aimed at the Public should be considered to be something of a seminar. It's like gathering all of your friends, acquaintances, fans, etc. into a big room and offering for anyone to comment. You can assume that this will be fairly public, as it is tied to Google after all, but the people who will immediately know about it are the ones who have you in their circles. Thus, you practically have an attendance roster right on your Circles page. Unless you disable comments then you can allow public interaction on these items, basically anyone with a G+ account can comment.

Getting Along with G+, Acceptance & Adoption

When we deal with a new service like this one we must be careful. Some people will proclaim it the next big thing, others will call it DOA, and still others will begrudgingly drag themselves along for the ride. We'll recall Google Wave (over and over again) and Orkut. We'll think of MySpace, which is funny because it was a huge success that just didn't have staying power. Maybe we'll think of all the other projects Google has done that no one would give a chance to yet have proven to be popular over time, like GMail, Google Maps, and Android.

Chances are that people like me will be more lenient on the service. I don't mean because of the reasons laid out above, but rather that I tend to love Google interfaces. Even their quirks often agree with me. I try to cheque my fanboyism and be objective. Certainly, as someone who does interface design for a living I can be critical of their choices. Still, it works for me for the most part.

It's also important to remember that this service was launched early in the development stages. It is clear that they intend to follow their pattern of rapid iterations and live testing. Google is capable of developing slick interfaces that work well, but often their first generation is somewhat clunky and pointedly favors geek culture with features like keyboard shortcuts. If you're not so much of a geek (or sometimes if you're just that much of a geek) then you won't appreciate this as much as people like me.

I'm sure there are more ways that this service both mimics and deviates from real life social interactions. After all, it is a piece of software and it does do things that are impossible or difficult to physically accomplish, like bringing together people from geographically divergent places. However, I'm not exactly a social scientist nor will I proclaim myself to be a social media expert. This is all I've thought of up to now and it was inspired by several conversations with various friends. This may not be the last I write on the subject, I only hope that the next thing I write isn't a post-mortem.

Windows Server 2008 R2 and COM Objects

So we just went through a huge ordeal while trying to decommission an old server and move a legacy website onto a new one. The old server was a 32 bit Windows Server 2003 machine, the new one is 64 bit Windows Server 2008 R2. The website is classic ASP that uses Dimac's JMail control and SoftArtisan's FileUp control, which are both 32 bit.

The result was several HTTP 500 errors and a relatively generic set of log messages. Actually we weren't always seeing anything in the logs. It was fairly perplexing. When we did get error messages they were like this:

800a01ad|ActiveX_component_can't_create_object

8000ffff|Enque:_Error__no_pickupdirectory_found.

80004005|[Microsoft][ODBC_Driver_Manager]_Data_source_name_not_found_and_no_default_driver_specified

The first part of the solution was to set the application pool for that website to 32 bit. You do this by opening IIS Manager, select Application Pools, select the application pool you're modifying, in the Actions pane click Advanced Settings..., then set Enable 32-Bit Applications to True. After you've done that, reset IIS and try your site. If the site still isn't working, reboot your machine. Apparently Windows isn't all that keen on switching between 64 and 32 bit, so sometimes a reboot is in order. [We had to.]

Maybe that will fix your problems, it didn't for us. In fact, the ODBC error seems to stem from this action. Apparently when you create an ODBC DSN it's only available to 64 bit processes. You have to create the DSN in the 32 bit space by using the 32 bit Data Source Administrator from the SysWOW64 directory [odbcad32.exe].

We still had those pesky JMail errors. The object was created successfully but we were getting File I/O errors. We followed advice that suggested we should copy the DLL to the SysWOW64 directory and register it there. No change. We modified the permissions on the DLL to allow everyone to read and execute it. No change.

What we hadn't thought of yet was to modify permissions on the SMTP pickup folder. We didn't think of this because the test page we'd created had everything but the instantiation commented. Still, this simple change made all the difference. For whatever reason, giving write permission to the IUSR didn't fix this. We tried a few other users before we gave up and just gave all local users write permission to the pickup folder. This did the trick.

Overall this was a royal pain. That's why I stopped to do this quick write up. I hope it helps.

Feature Creep: The Enemy of an In-House Developer

If you do in-house development then you probably have first-hand knowledge of feature creep. If you don't know what that is, or you haven't seen it happen, then I envy you. It's an ugly monster and the bane of my work. The problem is not limited to in-house developers; it is particularly acute in that environment, though.

This is because development cost is a taboo topic in most in-house development environments. The developers and their immediate management don't want to talk about it because they don't want to remind senior management that in-house development is expensive. Senior management is happy to ignore it because they crave the finite control, costs be damned. So a game is played to balance the quality of the product with costs, where the quality is generally lower than a prepackaged system and the cost is generally higher. In general, this works fine. It helps keep developers employed and management happy.

The real problems start as the customization culture trickles down the management chain. Depending on how vertical the structure of your company is, you may have dozens of management steps between the top and the developers. Typically, when software is not a primary focus of the company, your developers and their managers will be quite low on the org chart. This puts them at a disadvantage when dealing with almost any manager and makes saying no quite difficult.

Therein you have the perfect storm: A situation where discussion about cost is a taboo, but the number of powerful voices calling for increased cost is huge. It's worse yet, though. When management's focus is not on software but instead specifically on how to make software work for them (as in, each manager personally) there is often little to no concern about the cost of feature creep to usability. In fact, usability is typically not in a non-technical manager's vocabulary. Outside of the developer group no one cares about usability, and often inside the developer group it is neglected because of the notion that client doesn't care.

Unfortunately, even if the user thinks they don't care about usability they really do. The difference between great software and passable software is often usability. The difference between a truly happy client and a client who is merely happy that development is done is usually usability. Software is supposed to solve a problem, to help a user achieve a goal. If it is too difficult to use it creates more problems than it solves, or it hinders the users from achieving their goals. At that point it should be considered a failure, though reality shows that this rarely happens.

Failed development projects, whether they are recognized or not, are dangerous. They put developers on shaky ground. They cause managers to think of the taboo of their in-house development: cost. If they aren't thrilled with the product then they will be far more likely to consider whether it is worth the money. The only thing that keeps this from happening is that they are often too egotistical to admit failures, but eventually if feature creep continues they will come around. When they do they will externalize the failure to the development group, after all it is their job to make this software and if it's so much more expensive then it should be better, right?

Wrong. There is little connection between cost and quality in software. Devs don't dare tell a manager this, except maybe as a last resort. Lest he add things together and realize that he could put company resources to better use.

Of course, most developers actually do want to put resources to better use. With less pet projects on their plate most developers will try to automate processes to save the company money. They'll refine existing systems to make them more efficient. In this aspect, in-house developers yearn to be more like system and network administrators; if you can't tell I'm there then that means I'm doing my job. Occasionally they might venture off course to test some new technology or try to solve a particularly complex problem, but for the most part a dedicated in-house developer is happy with the sense of accomplishment that comes when he or she knows that their product made a truly positive impact.

Developers have a responsibility to fight against feature creep. Don't buy into the false mantra that your job is to do as you're told. Your job, at any level of any company, is to act in the company's interest. That means to be truthful about costs and try to help management make the right decisions. There is no room for complacency in this. Feature creep is the developer's enemy and it is our duty to fight.

The Benefit of Consistent Naming

In late 2007 I started a project that required a pass-through database to allow for auditing and change approval to occur between our CRM product and Outlook. I was, and am, acting as the database administrator (DBA) on this project. I was fortunate enough to be able to create the database almost single-handedly.

Doing everything yourself is tedious work. It can also go very wrong if you assume that you're not just doing it alone, but doing it for yourself. I stuck to some best practices to create cleanly formatted, self-documenting, and commented SQL code. This has allowed me to have exchanges like this:

Coworker: "What is the procedure to get a contact's information?"
Me: "getContact"
Coworker: "Oh."
Coworker: "What if I want to add this user as a subscriber?"
Me: "Use the addSubscriber procedure, pass it the contact ID and the user name."
Coworker: "Oh."

Eventually they stop asking because almost everything is so predictable. These exchanges may make them feel ridiculous but that's the point. If you stick to a well defined naming scheme then your code should do a lot of self-documentation. If the code is documented then it will normally be equally convenient to simply reference the code. This is a benefit to everyone. There is less need to bother me. The code is more readily available to the other developers than I am anyway.

Another benefit became apparent to me a few times recently: It helps you find when you are about to do the same thing twice. This is a big database that my team has been working on for the last year. There are almost 200 stored procedures and functions. Unfortunately, I was not able to create them all. I did create the vast majority, though, sticking to my same naming conventions each time. Now we are actively developing parts of this project again, so I need to put new functionality in the database. At least twice in recent weeks, a procedure I was prepared to create already existed, was named exactly what I intended to name it and did exactly what I wanted.

The lesson here is the power of doing things the right way for the sake of it truly being the right way. I could have probably done things faster if I didn't take the time to properly indent my SQL queries or if I used the query designer every now and then. Yet, I would cost myself and the company time in the long run because it would be far more difficult to decipher those queries to troubleshoot or change them. I could have used procedure names that were less descriptive to save some typing time or avoid names such as "getAcceptedCompanyMinorityStatusValues" but then I couldn't tell you exactly what the procedure does without looking at the code, and if I needed that later I might use a different naming scheme and do the same work twice. It is usually quicker to do it right once than it is to do it half right twice, especially when twice is likely to grow exponentially.

The Problem with Integration

The more you integrate products the more that product A's operation relies on how well product B works. A bug in product A can cripple product B.

That's pretty obvious, but what's less obvious is that you have to be able to trust everyone involved in the integrated products. If you can't trust the developer, or the code, of product B then product A may be doomed. If you're integrating products so that they use the same data then you not only have to worry about the developers, but the operators as well.

On Monday an application stopped working. It's part of our Intranet, but it displays human resources data, and it ties into our accounting system. It turns out that the accounting department had not opened a new period in the system, which broke everything.