Wednesday, December 19, 2007

Back in Time

Argh, I'm still busy. I write this at 02.23 A.M. I have just finished working for the day.

I upgraded my Mac OS to 10.5 (Leopard) recently. I had several reasons for doing this (being a geek is one), but there were two in particular that might be of interest:

I wanted a better backup system than the one I have used previously. Leopard comes with the much touted Time Machine.

I have done a lot of work on how the choice of requirements analysis methodology affects the final product lately. This has revived my interest in an interaction design methodology, Goal-Directed Design. I don't know if Time Machine was designed using GDD, but it was certainly designed using a very similar philosophy.

Time Machine is extremely simple to use. The only thing you need to do to get going is to plug in an external hard drive (I use a 160GB Iomega dedicated to backups only) and start the program. Time machine backs up the internal hard drive. From then on, it makes hourly backups.

Time Machine is defined by what it doesn't do as much as by what it does. There is no way to configure the time and frequency of backups. No choice about when to do full or incremental backups.

The interesting thing is that the lack of features increase the value of Time Machine enormously. The backup system I used previously had a lot of features. The developers had tried to avoid using technical jargon in the GUI. Unfortunately they just managed to confuse everyone. It was difficult to tell whether you had configured the system to make full or incremental backups, for example. Making backups with that system was a chore.

With Time Machine, I no longer have to care. Backups are taken care of invisibly, without me even noticing. Restoring files is easy. As you can see in the picture above, the interface for restoring backed up files is a bit spaced out. (The background star field is animated.) Still, it is extremely easy to use.

Someone put a lot of thought into this. For example, most people restore files rarely, so they will be perpetual beginners. Nobody but a system administrator wants to learn how to use backup software. It should just be there and fix the problem. Time Machine does that.

I also find it interesting that there is no way to come up with Time Machine if you use functional requirements. For all the talk about use cases and user interaction design, most development teams I see still use functional requirements, or something very close to it. They often dress the functional requirements up a bit by calling them "use cases", but that is as far as it goes.

Interaction design is a different beast entirely. The focus is on identifying user goals, and design software so that users can achieve the goals. Some goals are directly related to tasks, such as "write a report that looks good", or "make sure everyone in the company gets paid on payday".

Other goals are quite different, for example "feel good about the job I'm doing", "keep in touch with my family", or "be valued by my boss". Designing software that helps users achieve those goals is a challenge, but it is possible.

Enterprise systems have many users, and these users can have conflicting goals. A user may for example have "be in control of my own work" as a goal, while a supervisor may have "keep close tabs on what everyone is doing" as a goal. An Evaporating Cloud, a conflict resolution diagram, can help resolve such conflicts.

If you have read my old posts, you may recall that I was working on a book quite some time ago. I haven't had time to work on it for some time, but the project isn't dead, just comatose. I might be able to resuscitate it in January. If I anage that, I'll incorporate material on how to use interaction design and TOC busness analysis techniques to build a clear picture of what users really need.