Lecture Ergonomical Design @ UTwente

Archive for the ‘engineering’ Category

Don’t get fooled by Architects

Posted by mschmettow on 22. February 2010

Managing complexity

Working as an HCI specialist in a development team is working in a different culture having it’s own history, language, beliefs, powers and so on. Modern software systems are the most complex artefacts mankind is able to build. Accordingly, dealing with complexity has ever been a major issue in Software Engineering.

A central idea in software development is modularization, in general: How can we divide the total project into pieces that are manageable by small teams, but can be easily integrated again later on. This basically is what software engineers mean when they talk about architecture: dividing the system into components.

For independent development it is required that the components are loosely coupled, this means: Changing the internals of one component does not affect the development of any other component.

Three-tier architecture

A famous example of such an architecture is the three-tier architecture. It divides the system into the following components:

  1. Data layer: Responsible for proper delivery and storage of data

  2. Application layer: Here resides the functional part of the system. Real world processes are represented by software functions.

  3. Presentation layer: This is where functions and data objects are finally presented to the user.

Such an architecture makes it much easier to handle complexity. It also adds a great deal of flexibility. For example, new user devices can be supported by replacing the current presentation layer with a different one, which may for example make the application accessible on smartphones. Also, the data layer can support different applications. For example, a webshop may (and typically does) use the same data layer for handling the incoming orders and for managing the warehouse.

Architecture and usability

You may ask: If architectures are so marvellous, why shouldn’t we get fooled? Here it goes: Remember the quote:

The product is nearly finished, except for the usability”
anonymous developer

In user-centered design it is common sense to do usability first, for example: Know your users, know their tasks. But, if the presentation layer can be developed independent of the other components, why not doing usability last?

The answer is: Independent development, i.e. coding, does not mean that the components are independent wrt. requirements. The presentation layer can only display, what is supported by the application layer and the data layer. One may be able to quickly change colors, fonts, type of charts or even the device on which data is represented, but, if a data object is not available in the lower layer, there’s no way to display it.

Not so obvious: Several functions that are demanded by well-known usability guidelines need serious implementation on the two lower layers. Just to name a three:

Speak the user’s language

Imagine you have a nicely designed, successful website and want to make it available in a second language. This requires every data object to be held in more than one language instance. If this hasn’t been foreseen in the data model, you’ll have a hard time.

User control and freedom – Undo

Enabling the user to make every action undone is sth. we would ever demand for virtually any application. It helps so much, to safely explore the system and to recover from errors. But, an Undo function imposes serious requirements on the application and data layers: The application layer has to keep a record of every action the user has done and also has to “know” the reverse of each action.The data layer has to make sure that any “historical” state of the data is kept in order to recover it.

User control and freedom – Cancel

Setting the user in control also means to be able to cancel any long-running process at any time. Here, application and data layer together have to make sure that every incomplete (i.e. cancelled) action leaves the system in a well-defined state. This is often referred to as a rollback, and it is far from trivial.

Conclusion

Architectures are a wonderful thing and developers usually present them with pride. But, as long as some software developers think of usability as a skin-deep property, the three-tier architecture is harmful. Whenever you hear a software developer say something like:

We have a three-tier architecture, we can make the user interface look as we want at any time.

Ask him oder her:

  • Can we make this website multilingual, once it has become a success?

  • Do we have an Undo function for every filter the user applies to the image?

  • Can the user at any time cancel the defragmentation of his hard disk?

Posted in ED2010, engineering, Usability | 5 Comments »