I have been thinking about my design philosophy of a database system. (By db I mean a database centric application. The actual scenario is not relevant so ignore it except in the most abstract way of having users and some purpose)
This though relates indirectly to a post I read a few days ago about a programmer who had given their all to a project and had come to resent the users for not using the product the way it was designed and doing all sorts of stupid things which by his attempts to deal with them proceeded to turn the back-end code into rubbish in an attempt to cope with user stupidity.
Anyway, there are so many things wrong with the point of view expressed in the post that its hard to know where to start, but the point is not to attack the writer, it was just another seed for the idea I actually want to talk about.
The point I am trying to get around to is the idea of designing the tool to fit the user rather than trying to fit the user to the tool ( training, using it the "right way" etc).... seems obvious when I say it this way... but read on...
There is always a certain amount of tension between training the user to use the system and modifying the system to fit the users. There are economic arguments for an against both propositions and they underpin various business,design and engineering decisions... however all this aside and ignoring the issues with the limitations of interfaces and lack of computing resources and all the other limits and assumptions that come to the design table... there is still a point worth making. And it is...
A data centric application is, at its simplest, a sheet of blank paper. This is the fundamental metaphor upon which a database application is built. We will call this Layer 0 of the abstraction stack.
Layer 0. Medium.
The user can write on it, they can change things and erase things and freely scrawl whatever they like. The paper is infinite in size and there are no limits about where or what or why. They can share it and let others draw on it as they like. Everyone's drawings are mixed together. Think of a sheet of butchers paper on a table at a children's birthday party. Hand around the crayons and see what happens...
Layer 1. Structure.
The next simplest idea is to begin applying some simple helpful structure. Divide the paper into two areas with a single line (again infinitely long etc etc) Anything written on one side of the line has one meaning, and everything on the other side of the line has another. (The meanings are only in the head of the user at the moment, the paper does not "enforce" any meaning in any way.) The only useful rule in this case is that things should not cross the line or exist on both sides at the same time as this would be ambiguous. However the paper in no way enforces this concept, so its still quite possible for the user to put their stuff wherever they like, line or no line.
Obviously, one can then add more lines to the paper and arbitrarily assign meaning to the areas that are starting to be defined. These fields have no intrinsic relationships, except that of mutual exclusivity due to the dimensional nature of paper. However its possible to create relationships using ideas like Venn diagrams. Once you reach the level of sets and set theory you're wandering off into abstractions that are dealing with other ideas and not the point I am working on... so back up a bit. Keep it at the simple level of a 4yr old child with a sheet of paper.
Layer 2. Limits.
Rather than drawing lines on the paper, cut it into pieces. It's now less possible to draw or write something that spans two areas. Simply by moving the two pieces of paper apart, anything over the edges looses coherency and is divided. This is the simplest concept of enforcing a limit with this metaphor.
The things on the paper are now "in" or "out". Venn diagrams with scissors start to not really work out so well. The divisions become much clearer and unambiguous. Its still possible to write the same information or draw the same scrawl in two places, but they are two clearly and functionally separate places.
Another useful property is that the pieces of paper can be shared more easily. They can be passed around individually and manipulated separately. ( I think I just invented the foundation of data security in the metaphor... but lets not rush ahead)
Layer 3. Tools.
Ink versus pencil. One is permanent while the other is malleable. By introducing this idea, some drawing start to be unable to be erased or changed while others are still free to be added and removed, changed, reworked etc.
The concept of read, write, edit, delete, modify etc have suddenly become more clearly defined. We are no longer talking about the surface on which the writing is done but the properties of the writing itself. How permanent is it, what can happen to it in the future, what has happened to it in the past? These concepts and others can now be determined from intrinsic properties of the writing.
Layer 4. Properties.
Color. This is an intrinsic property of the writing tool but does not carry a semantic meaning beyond what we ascribe to it. Put down a handful of colored pens and pencils at a party. Each child picks one up and you can immediately start to determine authorship of each potato-headed figure on the paper. However, every time they swap pens with someone else the whole system collapses. So authorship is difficult to identify or verify from the data itself; no matter how much everyone wants to believe they can do it... its just layers of "proof" based on nothing.... there is no intrinsic property of the system that can identify authorship....without additional external ... something.
Try it at a party, be vigilant and write the name of the children next to each drawing, get all the parents to do the same, once you start this system, I figure it will be about 30 seconds before the children start writing their own names and the parents start helping them.... then a few minutes later the children are writing each others names and the parents have stopped supervising them.... after that... hows your system going now?
So whats the point? Am I saying all Users are like 4yr old children? Not quite, however the value of this comparison is that its a useful thought exercise. (The fact that the aggregate behavior of many "qualified" and mature staff in a large organisation is very similar to the aggregate effect of 4yr old's at a birthday party is amazingly similar... (even before the red cordial hits their systems)
The point is that a business system needs to be built from Layer 0 upward, not imposed with the expectation of the users being other than they are...
The other interesting point is that the layer model stops being useful pretty quickly as the ideas are not dependent upon each other in any order.... (might need to polish that idea a bit later)
So how does this gel into a useful idea?
Rather than building a system that is a mess of fields and data entry boxes and business rules, start with a sheet of paper and some pens and slowly add limits and boundaries that are realistic. Evolve the design by adding a simple concept rather than starting with complexity and expecting people to use it in the right way.
Damn but this is probably one of the most rambling posts I have written so far. And you know what... its working. I have turned over the ideas and tried to articulate them and most importantly I have captured the raw flow as it developed.
These writings are not intended to be a polished paper, they are raw ideas that are bubbling around. I write here to capture them while they are fresh. I can come back and edit them later when they gel again.
Simply by letting the idea flow out illustrates part of the point of this post. People use their sheets of paper differently. The role of the designer is to accommodate that while finding ways to extract business value from that process.
This maybe by allowing the content on the paper to be stored by machine, read by machine, shared with others, structured in small or large ways, edited, preserved, reported on etc. Thus the role of the application designer grows, but at its heart is the idea of a sheet of paper that someone wants to write on. The balance comes from making the process of writing easy and fluid while still being able to extract the business value.
And then the rubber hits the road with all the force of a cheap special effect and you get hit by all the compromises and limitations of the environment that we work in. Price, time, tools, resources, compromise, decisions etc..... all the bullshit and complexity of software engineering that obscures the reality...
..... of that simple sheet of paper and the brightly colored crayons in the hands of a 4yr old.
Edit.
The following casts a different perspective on the same issue. Redmond Reality Distortion Field. Same idea, different source.
http://www.stepto.com/Lists/Posts/Post.aspx?ID=486
No comments:
Post a Comment