Car parts in a box

A couple of decades ago I spent quite a lot of time working on my car. To be honest it was near the end of its life when I bought it at auction but I had only saved/borrowed enough for a car of that age and at the time I thought I knew a lot more about maintenance than I really did but what I did not know I now had my own car to learn from. As you might expect it was not too long before disaster struck and driving home one day the engine died and resisted my attempts to revive it. Time to to get stuck into car maintenance 101.

Once I had the engine in pieces I discovered that every piston ring had broken causing a complete lack of compression. I had however been very lucky and the pieces had caused minimal scoring of the combustion chamber. So all I really needed was a new set of rings. Since I had taken the engine apart I thought it would be a prime opportunity to update the main bearings and extend the life of the engine. With that in mind I made out a list and headed off to a specialist to obtain the parts.

If you have never been into such a place it is very different from the comparatively glitzy motor factors of today. Anyway after I listed out everything I thought I needed the guy behind the counter disappeared into the back room collecting all the parts I had asked for. Some time later he came back with a collection of grubby boxes and started entering the part numbers into a terminal. In those days most stock managing systems were centralised using remote terminals for access of serial lines. The screens 80x25 character displays.

What sticks in my memory was the speed with which the part numbers were entered. The guy’s fingers fair flew over the keys and he hardly looked at the screen. He had become so used to entering the stock numbers that he did not need to reference the screen while entering the details.

At the end of the process he hit a function key and without stopping started to put the parts in a bag.

This sort of interface was common. Graphical user interface had not made it out of the research labs into the mainstream. Operators were required to learn the systems rather than the systems be tailored to them.

When graphical user interfaces became more popular we designed interfaces that were easier to learn and use. Mice became the ubiquitous way of selecting items from list and moving the input focus from one field to the next.

My recent experiences at the motor factors are quite different from the earlier stories but one theme that I have seen time and again is that the data entry tasks take a lot longer than I remember. The introduction of the mouse has reduced the barrier to entry for most systems and allowed people to become functional at interacting with a system through this common interface but the cost of switching back and forth between the mouse and keyboard has an ongoing cost for every interaction.

The guys over at JetBrains have just launched a very interesting but tracking system. The fact that they have developed a bug tracker is not the interesting point for me. The interesting bit that caused me to remember the guy entering all the serial numbers is the interface that they have developed.

On the face of it the interface is a sophisticated web application but they have instilled a sophisticated text based user interface inside the graphical one. They have put together a domain specific language (DSL) that gives the user extensive control over the data model behind the interface.

People using issue management typically spend a lot of time interacting with the system and are willing to invest time in learning how to be more effective with the tool. Introducing a text based UI seems like a very valid approach in this case. The user is given a now familiar graphical user interface to start working with the tool and then a more expressive and powerful interface as they become more familiar and want to do more.