esjewett.com

I've been doing a bit of research on widgets for the day job. Hopefully I'll be able to make the results of that work available in some form within the next month. In the meantime, here's a demo showing how web standards are creating a situation in which widgets and dashboards are becoming more self-service. (The movie opens in a pop-up.)

The enabling technologies in the video above are

• Creation of dynamically updating gadgets from within Google Docs ("gadget" is Google-ese for "widget")
• Safari/Dashboard Web Clip functionality available in OS 10.5, which allows you to turn a piece of a page into a Dashboard widget.

Key functionalities that we are seeing are the ability to create meaningful, dynamic content in a self-service environment as well as easy re-mixing of content into personal dashboards as needed.

In other words, you don't need to be a programmer to do cool and useful stuff, though you do have to have a fair amount of patience on the widget creation side of the house. If history is any guide, the amount of patience required will decrease significantly as the user interfaces to this technology improve.

We're seeing similar trends in the enterprise space. Technologies are pretty much in place but take-up isn't great, probably because of similar pain points in user interface and ongoing work embedding re-mixing and dashboarding services into traditional information workflows.

Occasionally I'm impressed that the right people are on Twitter at the right time to participate in a conversation, argument, or quip of mutual interest. These little meetings of the mind turn out to be very much in the moment, held together by mutual attention. Afterwards, the individual messages float apart and exist on their own, interspersed with bits of other conversations and status updates, disconnected from the original context. There is, to my knowledge, no place where any given conversation on Twitter can be replayed.

One of those evanescent conversations took place on Twitter today, but I've gone to the trouble to recreate it again after the fact. Hopefully I captured enough relevant bits to convey the gist.

(Read from the bottom up, click for larger version of the image. I'm @esjewett on Twitter.)

I see the sentiments expressed by @mkrigsman pop up quite often, and normally I'm not bothered by it. But I'm impressed by Michael Krigsman's level-headed analysis at his blog, so I felt the need to jump in and make a nuisance of myself.

My concern, as expressed on Twitter, is that we often (especially on the internet) attribute business decisions to some sort of ill-intent. This is especially true for decisions made by Microsoft, and increasingly Apple. Sometimes we go so far as to brand a company evil. This is a bit much in most situations. It's a questionable characterization when companies turn over private information to unjust regimes, but it's a little silly when we're talking about the delivery of iPod firmware updates. (Of course, silliness happens all the time on Twitter, and I suspect @mkrigsman was purposefully being a bit sensationalist to stimulate conversation. Mission accomplished!)

Frankly, on close examination it appears that most untoward behavior on the part of large organizations is the result of ineptitude rather than ill-intent. Most companies just can't get everything (or even most things) right. Even those that excel in a particular area, like Apple in user experience, are bound to miss every once in a while.

As always, we should try to give a charitable interpretation of actions. But where that fails, Hanlon's razor applies:

Never attribute to malice that which can be adequately explained by stupidity.

I usually like where Michael ends up his analyses, and this case was no different. We do indeed live in a complicated world.

Privacy controls are an area of continuing concern in social applications. Michael Krigsman has hit on the point in a sensationalist manner on his IT Project Failures blog in a post titled Twitter is Dangerous. I think Michael is off-base because I think Twitter gets it right by keeping it simple: Your stuff is either private or public. It's hard to misunderstand that.

The important thing is that users of a given system clearly understand the privacy implications of entering data into that system. In order for this to happen, the user interface and explanation within the application have to correspond with the terms of service and technical platform. As I said, I think Twitter gets it right, but others may disagree.

We see a more muddled case with the recent addition of social sharing in Google Reader. Google could have done better with the initial launch of this feature, but to the credit of the Reader team, they got the message and fixed the problem. For the interaction design nerds out there, I think that the problem here was actually not with the sharing feature per se, but with a user/developer disconnect around the privacy implications of "Sharing" an item via a publicly indexed feed with an obfuscated URL. Many users thought of the feed as private while I'm pretty sure the Reader developers thought of the Shared items feed as public.

Let's wend our way to the point of this post, which amazingly enough isn't Facebook's Beacon. No, I'm going to talk about the Plaxo Pulse and a conversation I've been having with John McCrea on Twitter. The situation is that I, apparently, had a misconception about how Plaxo shares my Pulse items when I elect to make them "Public".

Specifically, I thought that making a feed "Public" would broadcast it to all of my Plaxo Connections. Connections on Plaxo are like Facebook Friends, both they and I have to agree to being connections. When you make a connection, you categorize the contact as any combination of business, friend, or family. As such, I assumed that I had exact knowledge of who would receive my Plaxo Pulse broadcasts, though I recognize that the material being broadcast is totally public for anyone who actually looks for it.

I was wrong. What actually happens is (apparently) that anyone who uses Plaxo and has me in their address book receives a broadcast in their Pulse feed of entries I set as "Public". In other words, I have no idea who I'm spamming with these entries.

At the risk of sounding self-righteous, I'm going to blame the Plaxo user interface for this one. (Whew, I feel better already.) Here's why:

1. The copy reading "choose which of your connections ..." clearly indicates that I'm choosing which Connections have permission to see the feed. Plaxo creates a strong division between the Pulse feature and the Address Book feature in their documentation (for example) so when Plaxo says "Connections", I assume they mean it. There is an expectation of consistency in copy across a site.
2. When "Public" is checked, it automatically checks and grays out the business, friends, and family options, creating the possibility that "Public" corresponds to "All of the above" or "All connections". This interpretation is clearly ambiguous and draws on my (fairly common) experience with HTML check-boxes and multiple choice tests, but any ambiguity is probably a bug in a scenario like this one.

I'll be clear that no damage was done here and all of the Pulse feeds I share are public information, so Michael Krigsman can rest easy. For me this is an academic exercise. But it is conceivable, for example, that a client who has me in his or her address book and uses Plaxo was getting spammed by my tweets and del.icio.us bookmarks 10-15 times per day. I'm a pretty public person, at least online, but I prefer to allow people the choice of whether they want to subscribe to a steady stream of my random thoughts. As such, I've un-Publicized all of my Plaxo Pulse feeds. If you want to see 'em, Connect with me.

I think this is a good example of one thing that can go wrong while designing and changing privacy settings. The complexities are similar to other UI problems, but the ramifications in this area are often invisible to the user and the consequences of misunderstanding could be severe. Combined, these two ingredients put the user at the mercy of the developer and this trust should be respected by taking care in design decisions and testing against real user expectations.

Michael Krigsman blogs at his IT Project Failures in response to a Robert Scoble post asking why enterprise software isn't sexy. Vinnie Mirchandani also responds on his Deal Architect blog. Scoble is asking why enterprise software doesn't get more press, and Krigsman and Mirchandani hold that it doesn't get press because it's doing important things. More likely it doesn't get press because your everyday blog reader doesn't really want to know about the software that processes invoices and manages supply chains, nor should they.

But I think this misses the point. It's not just your person on the street that doesn't care. The people that use this software every day don't care about it. A lot of people use software from SAP, Oracle, and Microsoft but very few of these people view the software as anything other than a necessary evil. I don't think it's unreasonable to attribute this lack of interest on the part of actual users to a lack of sexiness, usability, humanization, etc. on the part of the software.

So back to Scoble's question: Why the lack of sexiness?

I believe it comes down to a tendency to discount aspects of software that encourage use because in the case of enterprise software we can require use. This, of course, despite the fact that you can both require and encourage use.

Because of this mentality, and the resulting software (or vice versa), people don't care about the software they use every day. Not caring results in resignation and a cycle develops under which individual employees don't have and don't expect to have control over their software, their business processes (enshrined in the software), or their workflow (also increasingly in the software). This begins to shape up into a recruiting and retention issue because people who care won't want to work with software that they can't control. But it's also a issue because we leave a huge amount of business and user interaction expertise on the table when designing enterprise software for resigned users.

Now, that's money on the table, but I think the amount of money on the table here is dwarfed by the loss of whole areas of enterprise software. Companies are just starting to try to figure out social software and the jury is still out on this area, though there are some positive signs. How about user-controlled business process modeling, even just for analysis processes? Most people are still using Excel for this.

One area of enterprise software that has been an unmitigated failure is the knowledge management arena. A big part of problem is the fact that people have to be able to integrate the KM software into every aspect of their workflow in order to achieve the necessary level of information transfer into a knowledge management environment. Enterprise software traditionally doesn't enable this type of user control, so failure ensues. Sure, documents show up in KM repositories, but a working knowledge management system isn't really about the documents, it's about ideas and knowledge diffusion.

This is all especially concerning when we have Gartner analyst/VP Jeff Mann holding that "social interaction is the way most value is delivered in the modern work environment" and that "by 2012, the primary role of business networks will be to support social interactions, not routine business transactions." (Yes, I really love this quote.) I assume that Mann includes social knowledge creation in his calculus.

I think we can agree that un-sexy software probably doesn't do a very good job of enabling social interaction. And that's a big problem.