![[Home]](/static/yumyum.gif)
A list of ten most stupid things you can do with my password to your website or other service:
I recently gave a talk on the Google Summer of Code Mentor Summit about usability, in particular about so called Cognitive Dimensions. Then I thought that I might actually write about it in some more detail. You see, Cognitive Dimensions (or some variation of them) may be very useful for programmers or web developers who are forced to make their user interface decisions on the fly without a help from an expert and/or usability testing. They let you foresee the consequences of the decisions, at least to some degree, and pick the alternatives that have a good chance of being more usable.
Since the dimensions don’t really have any formal unit or scale, you cannot really use them to evaluate the usability of interfaces. All you can do is taking two possible solutions and telling which one is “better” in certain dimensions. If in addition to that you can somehow imagine which dimensions are more important for you at that particular place, you can pick the solution that suits you better.
Ok, enough, here come the Cognitive Dimensions (of Notation):
This is the distance between the smallest little detail that your user interface supports, and the largest general thing in it. The shorter that distance, that is, the smaller the difference between the detailed and the general things in your application, the better. If the users have to manage little details and at the same time keep an eye on the overall structure, they will get tired quickly.
You should pick the level of abstraction most adequate for the task and stick with it as closely as possible. You may even want to structure the workflow in such a way that it is divided into tasks with different levels of abstraction but narrow scale of abstraction in each of them – but beware, because it will affect the other dimensions.
Usually the elements and controls of your user interface represent something – they map to some real or virtual objects and terms. Closeness of mapping tells how closely they resemble what they map to. The resemblance need not me visual – in fact, it’s in the ways that are important for your particular application that they should be similar. In the very simplest approach, this tells how far are the things you are manipulating from their controls – but it’s not just limited to that.
The canonical example of a bad mapping, beloved by all usability experts, are the valves and burners on a kitchen stove: the burners are aligned into a square, but the valves are usually aligned linearly. It’s very easy to open the wrong valve – because the mapping it and the thing it operates – the burner – is not very close.
We all know that consistency is good, but how to measure it? We can say that two features are implemented in consistent (with each other) way if by learning to use one of them you have already learned to use the other – it just works the same, or similar, way. Your interface should be internally consistent – all the elements should be consistent with each other where possible – but it should also be consistent with the operating system it runs on, other applications the user may be using or have used in the past, etc.
How dense is the information you are showing? How much of it fits on the screen or a page? How much of it is actually necessary – can you remove any irrelevant information, or show it in a way that is easier to understand? You should generally favor terse notation over sparse one – the fewer the users need to look at, the better, as long as it lets them get the job done.
What errors and mistake can the user make when using your interface? Could any of those be avoided or somehow made harder to make? You can try using some Poka-yoke techniques.
Are those errors fatal? Can you do something to make them non-fatal? Maybe an undo function or some sort of sanitizing the input?
How early are the mistakes detected and reported? Maybe you could notify the user earlier and save him some time before he goes on building upon bad a foundation?
Some operations are hard for humans and are much better performed by machines. Your interface shouldn’t force users to perform hard operations, such as: calculating, remembering things, counting, searching and locating, inventing names or passwords, repeating, aligning things, etc.
Note: human short-term memory can hold a limited number of items – usually from 4 to 10, depending on how concentrated you are and such. If you interrupt one thing and ask the users to do something else, and you do it several times, they will forget what they were doing in the first place – or will need some time and effort to recall that. Remember about that and try not to nest tasks within each other, even if it makes sense from the programming point of view.
Dependencies between elements of your interface, or objects they manipulate, should be as obvious as possible. When manipulating something also affects other things, the way they change should be preferably visible, or at least indicated in some way. Don’t make the users constantly switch between screens just to tune something exactly how they want it.
This is a clever trick to check how well your display reflects the important aspects of your application. Just put two instances of your application, with different data in each, next to each other. Can you tell at a glance that the data is different? Can you tell what is exactly different? Can you tell what operations you need to make on one instance to get it to the state of the other?
Premature commitment is when you ask your users for some data that they don’t have yet, they are not sure about yet or that may change in the near future – and you insist that they input it here and now. Even worse, you may make it hard to change it later. This is bad. Try to avoid “trap doors” in your user interface – always let the users change their minds and correct their mistakes. Also, make sure that it’s cheap – don’t make them reboot their computer just because they have chosen the wrong option, or restart filling a registration form because they have picked a user name that is already in use by someone else.
Provide immediate feedback on user’s input. Display partial results, and show how the user inputs affects them. If some data is missing use some default values. This way the users are in control, can learn faster and can notice their errors earlier. If displaying the results is expensive, display a lower quality preview that just shows the important details. If the input is not finished (for example, the user is typing code and didn’t finish it yet, so there is a syntax error), at least display something – even if it may be wrong.
Make sure that it is obvious what each element of your interface is for. Make buttons look like buttons, links look like links, decorations look like irrelevant fluff (or get rid of them entirely), etc. Make sure you don’t use the same thing to mean two different things – even if it’s aesthetically pleasing. The users should be able to tell what they can do with interface elements and what will happen then. Follow well established traditions and “intuitive” meanings (beware! they change from culture to culture).
Allow the users to put more information than is strictly necessary. Let them leave comments and notes for themselves and for other users. Variable names and comments in code, margin notes in books, syntax highlighting in text editors, text formatting in blog posts – even such a simple thing as ignoring multiple spaces and newlines in data files – it all helps the users to add helpful things you didn’t think about. Humans don’t like rigid environments, so leave some wiggle room for them.
This is basically how hard it is to change something in your application once it is done. Generally the easier it is, the better. High viscosity often happens when the operations you provide are on a lower abstraction level than the operations the users want to perform – like a text editor that allows inserting and removing spaces, but not indenting and unindenting whole blocks of code. The difficulty may come from a number of different sources:
Knock-On viscosity happens when there are many interdependent elements, and changing one requires you to change others and this change may in turn require further changes, etc. You may need to rethink your presentation or provide operations that adjust the dependent elements too.
Repetition viscosity is similar in that it requires many changes, but this time it’s the same change repeated all over. Following the DRY (Don’t Repeat Yourself) principle helps here.
Scope viscosity happens when adding or removing something suddenly requires you to use a completely different representation. For example, you started your drawing too close to an edge and made it too big, and now you need a larger sheet of paper – but of course that requires you to redo or copy the picture somehow. This sometimes happens when you have a “simple” and “advanced” mode.
Are all the elements and information that users need visible? How easy they are to find? How hard it is to access them? Are they presented in a convenient and understandable way? Are they obscured by other elements at the moment when users need them?
Are important things more prominent than irrelevant details? Things may be hidden not just because they are obscured or not displayed, but also because hey are lost in a sea of information.
It’s not a secret that the font picking dialogs in contemporary applications suck. They were designed back when graphical user interfaces were born, and when you had 5 different font faces available on your computer. The situation has changed dramatically since then, but the font selection interface only went through minor improvements, and that’s not everywhere.
The task of designing a working, comfortable font chooser is hard. I don’t know of any approach that would actually work in the wild. I was thinking about this for some time, however, and I seem to have some ideas. Most of them involve storing additional meta-information with the font files – probably in some additional font storage system. You just cannot present the variety of font faces efficiently with the limited amount of information.
This is the first observation, easy to make – for example – on a freshly installed Ubuntu system. If you look at the list of font, you will notice that there is about a dozen useful fonts installed, all the rest being fonts for various exotic scripts and languages. This is true even if your native language and script is pretty exotic – of course, you are grateful that the fonts for yours are there, but all the others are just littering the list. Yes, it’s nice that you can go to some Chinese web site and see all the glyphs rendered properly, instead of empty boxes or random symbols. Even if you can’t understand them. But the probability that you will ever want to actually select such a font face in your word processor or graphical editor is rather slim, and the effort of browsing through them – rather tedious.
That’s why the first distinction that the system should make about the fonts is “will the user ever want to select them?” No point making them selectable if he won’t. Note, that although you can do pretty good guessing based on the system’s defaults and user’s locale, this should be still configurable for the user – it should be possible to select the “system” fonts, just maybe with one click more than usual.
The “system fonts” would include:
The “user fonts” include:
“Divide and conquer” is a good way to tame complexity, so maybe we can continue in this direction. Have more font categories – for a start let’s take the ones from CSS specification: monospace, sans-serif, serif, fantasy, cursive. Make them tags, so that a font can be in multiple categories at a time. Add some more categories – the research and user testing will show which ones. Allow users to create their own categories, such as “beautiful” and “corporation’s default”.
Preselect some of the categories where it makes sense. For example, when picking a font for a terminal or plain text editor, it makes sense to only show the “monospace” category.
Today’s font choosers will often have some form of font preview: usually, they will have the font’s name written in the font itself. This doesn’t work. Well, ok, it works sometimes, but not always. Consider a Japanese font – should its name be displayed in Kanji? It will be unreadable for most users. So in Romanji? it won’t show how the font face actually looks!
The solution is more meta-data. Of course, when the user has selected some text and is picking a font for it – display that in the preview. But if not, you should display a “sample” that is configured per font. Some fonts will display their name, others will show the most characteristic letters, etc. The name should be displayed separately, with the system’s default font.
Most modern font picking dialogs are getting it right already, but there are some that don’t, so I will mention it. Don’t display “Myriad”, “Myriad Semibold”, “Myriad Bold”, “Myriad Italic”, “Myriad Semibold Italic”, “Myriad Semibodl Italic Extended”, etc. as separate entries! Have checkboxes for these parameters, or at least a separate list for variants of the selected font.
That’s all for now. I will probably come back to it, because it’s something that bites me everyday, with GIMP’s, Scribus’ and Inkscape’s completely unusable font management. I’m glad I don’t use word processors.
Maybe try to post your idea (that seems really nice for me, i’ve always hated ‘select font dialogs’) on http://brainstorm.ubuntu.com/ ?
– Robert Pankowecki 2008-03-04 11:23 UTC
Radek, that’s a very good point.
Actually, I’m currently trying to understand ConTeXt’s font system. It is very sophisticated and not very easy to use - at least in the beginning - but this is mainly due to difficult-to-understand documentation (at least I have problems with it). But I’m pretty sure that the system is well-thought and very, very flexible. It allows to use fonts with different formats, different encodings, use OpenType’s “features”, enable protruding characters - all of it using a similar interface from the end-user’s point of view. Obviously, this is TeX stuff, so you don’t have dialogs &c, but ASCII files
; but still, I guess there are quite a few good ideas. I’ll probably write something about it when I finally get how it works
.
– Marcin Borkowski 2008-03-04 17:50 UTC
Robert, since that site requires registration and login, I will just wait for someone who’s already registered to post it there
– RadomirDopieralski 2008-03-05 14:57 UTC
Add a comment