Fashion vs. Function

I've been thinking about the "new" UI Best Practices Working Group, and specifically what that means for next June's Ganymede release.

Leaving the debate about scope creep aside, I'm a big supporter of "usability-centric design" or "user-centered design" or "outside-in design" or whatever the buzz you want to call it. Here's my take:

Should we enforce a "make it useable" theme for Ganymede? That's not really policeable, I know, but if everyone buys in to the idea, it means we're all working with usability in mind (or "consumability" of you prefer that term).

I know for me personally, the first pass at a piece of code is often the 'function' side, not the 'fashion' side (making it pretty or making it usable by anyone other than me), but the fact is a chunk of code is only as useful as its adoption by users. The second pass is 'let someone try it out' and then 'document how it works, if it's not already obvious.' Documentation SHOULD be something you don't need to do often, because realistically, no one (or maybe that's just me?) RTFM's the first time they try something out. Tools should be (in theory) easy enough to grasp the gist without having to grab for the manual. And if installing said tool requires grabbing a manual or FAQ, well, there's a problem there too.

You can build a super efficient car with a useless dashboard and ugly paint job and it won't sell. Make it usable (and sexy!), and it'll sell.

The added problem, again using my own work as an example, is that what's "usable" for me is not what's usable for my users (the Modeling project java developers). The great thing about that fact is that it forces me to design for people who don't want to have to work/think like I do. No one wants to use lengthy shell script commands to run or promote a build, but they're happy to click a few buttons on a website. No one wants to have to update properties or map files by hand, but they're happy to use a web-based generator that takes point-and-click input and turns it into data the build can use. No one wants to input arcane mysql queries at our release notes database, but they're happy to use the output of those queries, again, via a clean web UI. And because I'm inherently lazy and hate doing the same crap over and over, I'm compelled to find ways to make tools more consumable for me, too, so I can move on to solving the next problem.

Taking this example inside Eclipse to the plugins & projects that make up Eclipse / Europa / Ganymede, what this simply means is: 'assume your users don't want to know how the crap under the covers works'. Make it easy. Use it yourself. Try it out. If it annoys you (and you built it) it'll annoy people who didn't build it and don't have control over fixing it.

If you don't know what your users want, and can't think like them... it's time for the time-honored tradition used in many successful first dates: ask them. Let them talk about themselves, their wants, their desires, their pains. Answer their newsgroup questions. Chat with them on IRC. Watch for patterns.

Anyway, long rant aside, my point is simply this: never stop asking yourself if what you're building will be useful for your users, and if it balances function with fashion enough that there will be buy-in. Because if you build it, they will come... but if you build it badly, they won't stay.