Usability

As I was hiking on my recent holiday trying to give my mind a rest, it occurred to me how easy it is to become fixated; trying to improve within a narrow band but lose the plot. I think this happens within the IT industry frequently. For example, Usability becomes fixated on user interfaces (screens). It seems as if most analysts automatically assume to convert paper form shuffling to electronic form shuffling. Isn't a system more usable if there is less of it to have to use.

Can the forms be removed altogether? Customers enter their details on-line once. Systems are integrated to remove data re-entry. Rules engines are used to process information. Perhaps the system simply notifies someone by email if there is an exception with pre-meditated choices of action. An Information Architect should first attempt to remove all visible traces of the system before starting to design any user interface.

Secondly, the WIMP (Windows, Icons, Mouse, Pull-down menus) style dominates current user interface design. Xerox first developed the familiar user interface adopted first by Macs and then Microsoft with Windows. However, the design was developed with reviewing documents on-line in mind. Xerox wanted a more intuitive user interface for users to reviews documents WYSIWYG (What You See Is What You Get) before printing to paper. However, we already know that use of a mouse and pull-down menus slows down data entry. Perhaps some other user interface using email or SMS is appropriate for action orientated systems. If you can reduce the number of data entry clerks and people behind a desk then systems can be designed that better support people engaged in face to face interaction.

In the words of Antoinè De Saint-Exupéry, "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

Ant vs Maven

I've recently moved the build tool of a large multi-project system from Ant to Maven. I liked the concept of Maven, in particular, the ability to declare dependencies on third-party libraries and load them from a shared repository, the ability to work with a hierarchical project structure, and in general, a tool that makes common build tasks simple.

In the end, I'm not sure if a complex build environment can be neatly abstracted from lower level coding or whether Maven is just poorly implemented in parts.

Firstly, the dependency management feature has introduced as many problems as it has saved. I end up downloading more JAR files than I expected since the third party libraries I use have their dependencies which have their dependencies and so on. Some of the libraries in the public repositories don't seem to do a good job of keeping dependencies to a minimum required set. In addition, the same library will be downloaded multiple times as each dependent library specifies a difference version. So the reality is a great deal of time is required to specify exclusions and research the dependency trees of various libraries. Therefore, little time is saved compared with manually downloading only the necessary libraries.

Secondly, doing anything out of the ordinary quickly gets difficult and complex. For example, copying an artifact to a non-default location requires adding and configuring a plugin. Many complex tasks must resort to using the Maven Antrun plugin to run ant tasks (which defeats the purpose of moving from ant) or to writing your own plugin.

Thirdly, many of the plugins are poorly documented and implemented. For example, the Maven Archetype plugin used to create a project template uses Velocity to perform variable substitution in template files. However, if you want to use Velocity template files as part of the project template you can't.

The verdict is I'm sorry I spent a great deal of time moving to Maven. Maven is faster for straightforward projects with a standard compile, test, package and deploy lifecycle. But once you need to automate other tasks, such as generating Hibernate mapping files, or manage a large number of dependencies, Maven quickly starts to become an obstacle rather than an enabler.

Bootstrap Code Generation Framework Released

Development of the Bootstrap Framework started in December 2003 while I had a long wait at an airport. It was born out of frustration that getting applications started took too long and distracted from concentrating on the core business functionality. It also became a personal tool to integrate new technologies, such as Hibernate, to quickly create working applications to better understand how to use the new technologies. The core domain model of an application remains fairly consistent while infrastructure technologies - to persist state to a database, create the user interface, etc, change frequently.

While earlier versions of the framework generated applications using Struts and EJB2, its has evolved to integrate technologies such as the Spring Framework and Hibernate. This first published release uses Spring, Hibernate, and Flex as the front-end in response to a recent presentation I gave at a Flex Users Group and my recent learning to better understand Flex 2 and its integration with Java.

Publishing this first release was also dependent on migrating from Ant to Maven to improve the build of generated applications and management of third-party library dependencies. This was a much bigger task than I had expected.

I am releasing the code under the LGPL license. The intent is to ensure that any improvements to the generator and templates is made available back to the community, while generated applications may be used for commercial applications.

I welcome feedback.