Better specified than sorry

posted 09:29PM Aug 07, 2008 with tags productmanagement softwaredevelopment specification usability by Lars Trieloff

Long time no posts here, thanks to Mento I have switched very much to link blogging, but if you happen to be interested in the stuff I write, feel free to follow me at FriendFeed.

Today I learnt an interesting fact about interaction with developers: if you as a product manager want a feature implemented, do not talk to the developer first, write a specification and a mockup first. If you skip writing the specification first (which can and will be changed afterwards) things can turn against you.

In our new web content management product we will have quite powerful support for tagging (that can be used in a folksonomy-like way, as categories, as a taxonomy and even as a thesaurus, as I said, quite powerful). I did specify the conceptual model, the content model, created some mockups (for another product that will use the tagging feature) and discussed with the developer how to implement the tagging user interface.

Together we refined the original idea I had for the user interface, given my general experience what works in AJAX web UI, and his more recent experience with the particular widget framework we are using, examined a set of model application that already implemented some of the metaphors used and came up with a simple, but powerful (and extensible) solution. I knew what the developer would do, the developer knew what he should do, everything was fine and I rushed to the next item in my busy schedule.

Then the unpredictable happened: Schedules were rearranged, priorities shifted, the developer switched to another task, went to vacation, schedules were rearranged again, priorities shifted again, another developer picked up - and knew nothing about our previous discussion and our common mental specification, so he started coming up with his own solution, because he could not use the specification I skipped writing, ran into problems and I had to troubleshoot.

Needless to say, the troubleshooting took more time than writing a helpful specification would have taken, and a written specification would have helped our initial concept discussion as I had to explain less and we could work in a more well-structured way.

Lesson learnt: better specify than sorry!

| Comments[2]

posted 10:38AM May 23, 2007 with tags gnome usability webdevelopment by Lars Trieloff

What makes a good icon? A good icon is a good visual representation of the subject of the icon. In cases where no visual representation is possible, icon designers usually use metaphors. A good metaphor is the stop symbol that is modeled after the street sign: A red (warning color in most cultures) sign with eight corners is percieved as a stop sign, even without the four letters STOP on it. A case where no metaphor is neccessary are the icons for bold, underline and italic. Just an bold, underlined or italic letter is enough to make the point.

What about link icons, especially the insert link button that can be found in many visual HTML editors of WYSIWYG Wikis: A long time ago an icon designer must have decided to go with an metaphor, more specifically using the fact that a link in the english language can denote a hyperlink or a link in a chain. Thus, the chain became the most prevalent symbol for hyperlinks. In order to emphasize the hyperlink-nature, often a globe symbol was added to the icon, making the original chain almost irrecognizable. A very good icon modeled after the hyperlink=chain link idea can be found in the GNOME desktop:

http://weblogs.goshaky.com/weblogs/lars/resource/gnome-link.png

The problem with this icon and all other icons modeled after the idea of equivalence of hyperlinks and links of a chain is that it is not understood by non-native english speakers who do not recoginze the chain link in the icon and do not equate the concept of a link in a chain with a hyperlink between web pages. The other problem is that is metaphor is not neccessary. When you ask people what mental model of a link they have you will get not one single answer, but when asking how links are perceived, the answer is clear: "a link is underlined text, often blue that turns my mouse cursor into a hand when hovering". Following this observation, my take on a link icon would be modeling what the user percieves as a link, similar to the text formatting icons mentioned before:

http://weblogs.goshaky.com/weblogs/lars/resource/mindquarry-link.png

Now I have only one problem left: What is a good icon for a concept like WikiWords or hot links, e.g. an action that takes the currently selected text and creates a link out of it?

| Comments[2]

Installing Mindquarry got a little bit easier

posted 03:13PM Mar 16, 2007 with tags administration mindquarry usability by Lars Trieloff

Adrian Sutton attempted to try out Mindquarry and failed. To be honest, I have to agree totally to his criticism. Mindquarry is hard to install, as it requires two complex software systems to play together nicely: Apache (with Subversion) and Mindquarry, running in a Java Virtual Machine. To combine these two requires either creating an enormous package that contains everything needed by Mindquarry (and possibly duplicating a lot of existing infrastructure), or leaving it up to the user to find out how to set up everything (after all installing Apache 2, Subversion, mod_perl, a Java Virtual Machine, a Servlet Engine and setting some configuration variables is not hard for the average geek). We decided to find a middle course: We provide packages for some operating systems and a generic binary that leaves enough freedom to adjust the configuration to other scenarios.

Adrian made some suggestions on how to improve the installation experience:

  1. Include the installation requirements, specifically tailored for the particular package, in the package itself. The Windows package should only contain Windows installation instructions, the Linux one only Linux instructions etc.
  2. Include even a brief note on where the heck the server is going to be running when I start it. A getting started guide would be better, but I'll settle for a simple port number.
  3. Write something to the logs. If there's a permissions problem and you can't write to the logs, write to the console when the server starts up. The logs should tell me whether or not the server started successfully at the bare minimum. If it does start it should tell me what ports it's listening on or what URLs it thinks I should use.

This week I have made following adjustments to our packaging and documentation (without modifing the souce code, so some of Adrian's suggestions have to wait for the next release)

  1. We have a VMWare image of Mindquarry available at the Mindquarry 1.0-M1 Download page for a quick start
  2. There is a binary installer for Linux and Mac OS X that checks that installation requirements are met, adjusts permissions and writes configuration files
  3. There are separate installation guides for Mindquarry on Linux, Mindquarry on Windows and Mindquarry on a Mac made using profiling support in the Maven 2 DocBook plugin. Of couse there is also the combined installation guide covering all operating systems.

Unfortunately I cannot test all configurations and operating systems beforehand, but I am happy to hear from your experiences and your ideas for improvement.

Guide or Reading Lists? Reading Lists!

posted 12:35PM Apr 12, 2006 with tags opml usability by Lars Trieloff

Pito Salas asks whether the "Guides" in Blogbridge (my favorite RSS aggregator) should be renamed to "Reading Lists". From my point of view the concept of "Reading Lists" is much more focused than "Guides", because Reading Lists are either a list of recommended reading created by myself or other people (OPML bookmarks), but "Guides" only indicate that other and only other people guide me or tell me what to read.

By the way I would completely drop the mapping of one "Guide" to multiple OPML files (or Reading Lists). Just have one Reading List for every OPML file subscribed to.