roy

Edit: I realize this is a longer post than I intended - I couldn't sleep (I now regret not taking my sleeping pills), so I decided to write.

So the short version of this post is this: enterprise software sucks because the buyers aren't the users, and because UI design get unduly influenced by engineers.

You may now skip the rest of the post.

. . .

Much credit to this post, which is pretty much where I'm lifting a lot of ideas from.

Check out this advertisement from Lotus notes, which (Khoi correctly) embodies why enterprise software sucks:

The text:

"Imagine if you could take the qualities of your favorite animals and combine them into one. That's the principle behind the new Lotus Notes 8 from IBM."

Yes, please combine the smelly farts of dogs with the hairball coughing from cats with the shrill chirping of parakeets. That'll really be awesome. Oh, and the gills from fish. I'd really like to keep my dogcatfish in a ginormous dogcatfish tank. (Or maybe I'd just create a manbearpig instead).

Anyways, these types of adverts demonstrate the problem with enterprise software: the buyers of enterprise software are not the users of enterprise software. The people who pay for enterprise software (and thus fund enterprise software) look for 3 things:

1. High overlap of acronyms for the buyers' existing IT infrastructure with the enterprise softwares' feature lie - stuff like LDAP, Windows * (Forms, Server, Enterprise, take-your-pick-of-MSFT-product), WebDAV tend to play well here
2. High overlap of acronyms/buzzwords read in latest industry journal - for those really bleeding edge buyers, they'll bust out acronyms like OpenID, AJAX, mashups, and APIs
3. High degree of control over perceived "disgruntled" employee problems - never mind that Wikipedia seems to function fine with anonymous people editing page - people in the buyers' organization seem to be filled with employees just waiting to risk their paycheck on destroying a wiki (where content is never really destroyed).

Let me expound on that last moment, which leads me up to the second reason why enterprise software sucks.

When a buyer wants more control over their enterprise software, they'll request a feature like: "I'd like to take this one page and allow people from this LDAP group to just comment it, but let people from this group edit it, and then everybody else who is an employee should be able to view it, but our contractors shouldn't be able to see it at all."

Now let me just say there isn't a problem with this feature request. Modern day organizations are complex, and I understand that. But the problem is how it gets solved:

Eager engineer goes, "I understand the underlying data model that I designed underneath the API interface. I'll just write a GUI wrapper to expose it all!" UI engineer goes: "Shit, that's a lot of data! We need to find out the use cases and catch those common cases!" Project manager goes: "WE NEED TO SHIP THIS WEEK. JUST WRAP A GUI AROUND THE FUNCTIONALITY!" So the poor UI engineer has to just "get it done" and dies a little inside, as the confusing enterprise product goes out the door.

This type of screen usually indicates this type of problem:

Now maybe MSFT did throw a lot of money at optimizing the UI. I don't know. I can only speculate, but Lord knows that every time I want to change an option, I want to nest in 3 pop-ups deep.

If you want an example of investment in good UI design paying off, look at Gimp and Photoshop. Both are strikingly similar in functionality, yet nobody can figure out Gimp.

Unfortunately, it's been my experience that when developing features for Deki Wiki, it takes far longer for the UI implementation to be perfected than the actual engineering implementation. The engineering implementation, as daunting as it may be, is discretely measurable: given these inputs, give these outputs. How you want to achieve it (and whether you write clean, maintainable code) doesn't really matter, because as long as the output is correct, you've been successful. Unfortunately, just exposing a UI interface is rarely ever the correct solution.

As we target Deki Wiki more for enterprise sales, there's a natural tendency to de-emphasize the user interface. Instead of focusing on improving existing users' experience with the product, we're more interested in adding features and add-ons that we can sell.

I remember the early days of Deki Wiki were all about user experience. Those were the best days. It's sad that those conversations never come up anymore - nowadays the conversations revolve around me exposing some technical requirement or updating an existing feature to be more "powerful" (synonym for "complex"). The user interface for Deki Wiki is simply taken for granted now, and it stagnates as a result. And although I'm probably the only one who thinks this, I think the user experience is one of the huge reasons why Deki Wiki took off - the interface is clean and the system uses WYSIWYG so no wikitext knowledge is required.

(And now I'm going off on a personal tangent) It becomes such a struggle to implement user-oriented features. When was the last time we implemented a feature for the user? The new version of Deki Wiki has many user experience improvements, but they pale in comparison to the hours we've put in elsewhere. It's just a fact of the matter that for enterprise software, designers, engineers, and project managers rarely have their self-interests line up with the users ... and thus ... users suffer.

So anyways, if you wanted to know why enterprise software sucks, you know why.

And if you want to know, yes, I'm totally guilty of contributing to the suckiness of enterprise software. Oftentimes Corey will come to me with a completely legitimate customer request, and I'll disregard it either because i'm a self-serving (1) engineer who knows better than anybody how functionality should be implemented (2) a designer who claims to know better than anybody how things should be designed and anybody who says otherwise is an idiot or (3) a project manager who's just trying to ship on time. C'est la vie.