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.

Automating the svn update and build process of ArgoUML

As for the majority of persons working in open source projects I get to work only some 2 or 3 hours in ArgoUML at a time. When I start working I like to get up-to-date with the current trunk of ArgoUML and its projects. This is a process that takes normally about 20 minutes and includes:

  1. svn update of all checked out projects of ArgoUML
  2. build and run the tests of all relevant (for me) projects
  3. check the results and fix problems (this isn't needed normally :-))

The first and second steps are easy to automate, just create shell scripts that contains the individual updates and build commands.


svn update argoeclipse
svn update argouml
svn update argouml-andromda
svn update argouml-classfile
svn update argouml-cpp
svn update argouml-csharp
svn update argouml-gen
svn update argouml-idl
svn update argouml-python

<dir_for_co>\build.bat [Note that this isn't working yet, help would be appreciated!]:

cd argouml\src_new
build package alltests
cd ..\..\argouml-cpp [fails here, this step isn't executed]
build tests
cd ..

Thursday, November 02, 2006


I've finally been able to restart working in ArgoUML! The module is in the new Subversion repository, and I tried to follow the instructions to checkout with eclipse. It was after several failures that I got back to the good old command line and in 1:30 hours it was checkout (argouml and argouml-cpp) with my tigris user, built and unit tested.Here follows the steps:

<dir_for_co>>svn co --username USER --password PASS argouml
<dir_for_co>>svn co --username USER --password PASS argouml-cpp
<dir_for_co>>cd argouml\src_new
<dir_for_co>argouml\src_new>build package
<dir_for_co>argouml\src_new>cd ..\..\argouml-cpp
<dir_for_co>argouml-cpp\>ant tests

Then point your browser to file:///<dir_for_co>/argouml-cpp/build/tests/reports/html/index.html and check if all is well. Note that I had to use Ant directly, because there is something wrong for me in the way the BAT files are working.

Reader Shared items