Ionrock Dot Org

I have heard some recent discussions recently that made me think about what kinds of problems you want to provide users. That seems like heresy in that you really never want to give users problems, but in the real world the facts suggest that users will have issues with software. As a programmer it is our responsibility to consider what will be an issue in terms of finding potential bugs. We should also consider going beyond bugs and consider what situational issues could arise from using our software along with how users can (and will) work around known issues. This is different from something like test coverage where a user hits a corner case that wasn’t coded for by the developer. The “issues” in this case are situational and would be different for every single user depending on how they consider the application within the scope of the virtual world.

In the world of HCI this is pretty much analyzing how well the application design matches the perceived viewpoint of the user. In other words, how well does the application meet user’s expectations. This is where you see metaphors come into play and dictate a real world situation where people map experiences on top of some application they are using. The problem goes beyond this though, because even within a metaphor or design, there are questions the user must answer in order to use the application. This is where a great application can buckle under the greatest design.

In an application like MS Word, there are many types of users. There are those people who struggle to get hanging indents and work with random changes affecting the entire document and users who manage to reflect daily on proper use of obscure dialogs and settings. In both of these cases, the user is forced to make a design decision in how they create their document. This is very similar to what objects a developer will use to create an application, which is always a very subjective decision depending on the constraints and requirements. It is this kind of issue that developers, if possible, should avoid at all costs.

Take subversion for example, they made a decision to push the terminology of branches, trunk, and tags to be a documentation issue. They rely on conventions to push users towards a workflow instead of hard coding those items within the application. From the developer standpoint this is great because there is no end to wealth of configurations and work flows you can use. But from the standpoint of someone trying to get something done, it doesn’t make a bit of difference. I am not saying it is not handy or valuable, but rather there was some cost for the added flexibility.

When you are creating an application for a more traditional user, it is important that they do not get hung up on details that do not reflect getting actual work done. In the case of subversion, a poorly laid out repository can be a real pain. In the case of a traditional user application, it can be a crippling bit if flexibility that has catastrophic affects on both the productivity with the application as well as the continued success. This does not mean all applications should lock user’s into their internal model, but rather sacrificing flexibility in order to reduce the design issues can prevent issues from ever cropping up. In addition to this, it can create the market for other orthogonal applications that can compliment each other in completely different means. Applications centered around deployment are one good example of a tool that can be complimentary to a confined application.

It is not that flexibility is inherently bad, but forcing the user to make a design decision will always leave the door open for poor experiences, which in the long run, makes the application difficult to use.