If you have a computer product that people use, it will have an interface whether it's a website, a desktop application, or an embedded device like an iPod. The interface is the way that people interact with your machine.
Our job is to make this interaction as simple as possible so that your product is easy to use. A hard-to-use product will have a harder time in the market place than an easier one because people will prefer one that just works.
Think of the interface as a translator than converts your user's actions into something that the machine can understand and then obey; and also that converts the machines actions back into something that your users can understand. If the translator is poor, the user's wishes will not be clear to the machine which will not then be able to obey them. Likewise, if the interface communicates the machine's messages confusingly, the user will not be able to understand the machine's state.
Viewing an interface as analogous to a translator allows us to understand interfaces more easily. Syntax refers to the way in which words are structured to give us complete sentences and we can use our analogy to think of the way an interface is structured as its syntax. Semantics (the meaning of words) can refer to the choices that a user makes within the interface.
With these points in mind, structuring an interface can be seen as a process in which it is the job of the designers (i.e., us) to help users create a conversation with your machines. Let's work through an example using a file dialog.
File dialogs are common on just about every GUI. Typically, a user wants to open a document in the current application. This involves several tasks which can be simplified and greatly understood by using the conversation analogy.
User: "I want to look at the file, 'document.doc'"
Computer: "..."
So no good speaking to it. Instead, the conversation with the machine is mediated entirely through the machine's interface.
User: "I want to look at the file, 'document.doc'. The "open file" menu items approximates this. By selecting it, I am telling you that I want "open file" and I guess I will have to tell you the document later."
Computer: "Ok, you want to open a file somewhere. Here are some files" (a dialog appears)
User: "You are saying that I have to specify which file to select from these options. When I specify a file, I will tell you and you will 'open' it for me."
From this conversation, you can see a few minor issues exist. For the conversation to occur, the user needs to understand the interface's syntax: first tell the machine what action you want to do, then tell it where to (i.e., what file), and finally tell it that you have chosen what you want.
But a better conversation might be like this:
User: "The last file I opened? I want to look at it again."
Computer: "Ah ok. I'll open it for you to view."
This is a simler dialog and is achieved when the user selects the 'recently opened files' option somewhere (often in the 'file' menu). It's helped by the fact that the user wanted the last file he or she opened but the problems start when users want to engage in a richer dialogue:
User: "That file I made 6 months ago about my gardening programme - I want to look at it again. FYI, I viewed it last month."
Computer: "You last opened files with these names: 'TV schedule.doc', 'letter to Aunt Peg.doc', 'list of CDs.doc' and 'shopping list.doc'"
User: No, not those. It has my gardening programme on it and I need to know if I should water my roses today."
Computer: "You last opened files with these names: 'TV schedule.doc', 'letter to Aunt Peg.doc', 'list of CDs.doc' and 'shopping list.doc'"
User: "Oh..."
And this is not a good conversation. Recent file lists can be useful but only so much. Working with a computer can be frustrating because it has an extremely limited and filtered ways of understanding our communications.
I'll cover a better example in the next part of this article which will show how we can generate a system-wide usability analysis framework using this idea.
No comments:
Post a Comment