Monday, July 11, 2005 

Grids, lists, and the like

I don't like grids. The only grid-based program I like is the spreadsheet, for reasons I'll explain later. The heavy presence of grids is often the symptom of a terminal disease: the computer as a filing cabinet or, as I call it, the "useless computer".
The usual grid-based program works like this:
- the user can insert new information into the program, usually through a form.
- the user can later search for information, usually by scrolling through a long grid and/or by applying filters and sorting on some fields.
- the user can update the information, either in-place or in the same form as above, or see more details, again in a form.
- alternatively, once he has found the information, he's sent to another grid, e.g.: now that you've found your customer, pick the products.
This is so commonplace that people tend to believe it's good. However, the computer is totally useless here. Sure, it's faster than the old filing cabinet. There are also a few constraints checked here and there, so inconsistencies are somewhat trapped. Still, it's a file cabinet on steroids. Duh. Very exciting... : (.
This kind of application is common because it's easy to write. Extremely easy. Almost in the realm of end-user programming. It takes little understanding of the (real) business. Little or no understanding of the user. Little or no interaction design. With a modern tool, it doesn't take much understanding of technology either. Instead, moving away from the "useless computer" approach takes a large effort in understanding the business and the user. It takes creativity, and may require a larger investment: for instance, the barcode has been conceived to move some applications away from the grid paradigm, but without a large dissemination effort, it would have been useless. Often the solution to the grid disease must be found in a stronger integration between applications, sometimes in a stronger integration with the physical world (see the barcode, and its modern RFID incarnation).
Another real-world example can be useful here. Some time ago, one of my customers (a bank) showed me a prototype for a backoffice application. The application was intended to enable users to keep track of a complex workflow. The user would select a customer and guess what? He would get a lengthy list of documents, provided by the customer or to the customer, in a [nice] grid with a date field, a status field, and so on. Very common sense. Very commonplace. And totally wrong.
The user would have to understand, from the list of documents, the next steps in the workflow. Are there any missing documents? What I've got to do next? Why is not this !@#$@# computer helping me?
Consider now a different interface: since the workflow is so important, show the workflow. Show the user the steps he has been through, and display documents associated to each step with a click. Highlight the next steps. Help him visualize what he's got to do next.
More complicated to design and implement? Sure. More useful? You bet!
Back to the spreadsheet: here we have a grid too, but the interaction model is completely different. You write numbers and formulas and you play what-if scenarios. The computer is extremely useful. It's not acting as a fast filing cabinet. It's a thinking tool. Exactly what I want.
L'ho girato al mio capo che è un patito di programmi con griglie. Chissà cosa ne pensa...
Post a Comment

<< Home