As an ArgoUML contributor I'm going to blog my activities here, so that they may draw interest by other developers or help other developers when doing tasks similar to what I've done. AND(!) the grand vision that makes an Argonaut what he is, TO THRIVE IN THE BIG DANGEROUS WORLD, TAKING THE Argo TO A GOOD SHORE ;-))

Monday, November 06, 2006

ArgoUML and OpenUsability

I found out about the OpenUsability initiative in one of the ThoughtWorks blogsJosh Evnin's– and immediately proposed it for ArgoUML. Linus finds this a good idea and I'm going to act now as a proxy between ArgoUML and OpenUsability.This is somewhat more work, but, due to one reason and another I'm getting much more sensitive to this whole usability issue and it is growing in importance in my internal priority queue.

One reason is due to my current work, where I'm working in the development of a planning tool for WDM networks. For historical reasons the usability wasn't a concern in the beginning and it continued to be so for a while (years) until the negative feedback from the users started hitting the development project. One of the issues is the lack of Undo\Redo capability, which is also a problem in ArgoUML.

Another reason is that I'm reaching a time in my professional life where I've been sufficiently exposed to good and nice to use user interfaces and bad ones to give this usability issue the importance it deserves. I now see and understand that usability isn't only about GUIs. Quite the contrary, usability may reveal itself in a command line interface, a library API and whatever is the interface to the users of some given software deliverable.

An example was shown to me just some minutes ago, when I tried to automate the build steps in the Windows shell. I have a batch file which fails to do what I ask and simply doesn't provide any help! That's a bad user interface and I just got hit... I tried to fix it by trial and error to quit and switch to the cygwin environment, where AFAIK these things work better.This is what usability is all about, helping our users to solve their problems in using our software.It is THAT important!

The root cause for some software to be bad to its users is lack of a user oriented attitude of the development project.I've found some of the signals of this to be:

  • The management doesn't use the software and its attitude is more oriented to fulfilling the contract and process than to actually help the users to fulfill their objectives.
  • The developers don't have a global concern for the usability of the application, being more preoccupied with their little small component than to the emerging consistency of the user interface of the application. [Frederick P. Brooks in his "The Mythical Man-Month" book, chapter 9, page 100 of the 20th anniversary edition, says Fostering a total-system, user-oriented attitude may well be the most important function of the programming manager.] You may check it by the way the application provides error information and the differences in behavior from one functional area to another.
  • The development process doesn't include steps where feedback is gathered from the users. They only get access to the software when the development project thinks it is finished or they get it sooner, but, with a whole list of disclaimers basically stating that if it gets out of the box and bites your head off bad luck for you. It doesn't include a polite message asking for feedback from users and how they can do it.
  • Direct contact between the development team and users of the software is discouraged, unless explicitly organized and carefully controlled by the management.
  • There is no access (or it is relatively hard to get it) to the bug and issues list. There are no users forums and no FAQ.

I think that one of the positive things of the agile manifesto is the focus on providing value to the users and fostering conversation and collaboration. I contrast this with the typical silo approach of the majority of the development projects in the industry, where there are a bunch of persons who are allowed to interact with the users. These screen out direct communication, not because it affects negatively the productivity of the persons developing the work, but, because it enables "better" control of the user/client interaction.

It isn't something that only the development side must work out, also it is common that the user side has the tendency to get inside info from informal communication channels and use it for finger pointing and contract revoking, so, this new old way of working requires maturity and good common sense from both sides.

1 comment:

Todd Moy said...
This comment has been removed by the author.

Reader Shared items