Dear readers,

I'm taking a one month summer break from blogging, twittering, JungleDragon development and everything else I do online. I'll be back fully recharged in the beginning of August. Enjoy your summer!

In the meanwhile, you may want to check out my extensive archive of articles.

Juan F. Ruiz has been so kind to translate the latest version of Blogo (v1.75) to Spanish. I'm really flattered and touched by this voluntary effort. Thank you Juan! You can find the download page here. Keep the frog alive! For those not familiar with Blogo, please check out the  screenshot tour to see what Blogo can do. Finally, there is also a .NET version of Blogo called Blogo.NET, which is also available in Spanish. Enjoy! And by the way, I'm very interested in public websites that run Blogo. If you would like to be added to the screenshot section, please contact me.

Having invested a bit in learning a bit about the usability of user interfaces I tend to look at websites differently now. I spot flaws and broken design conventions even when I'm not looking for them. Although I am of course not a real authority on usability I do have a strong drive to express my views.

Today this came to mind:

It's a technical article on the MySQL site. It breaks quite a lot of web writing rules:

• It is a wall of text that is extremely uninviting to read. Web writing is different from normal writing. Web writing means you cut 50% of your text, since web users do not read your text, they only scan text.
• The block of text has almost no indicators of structure, no headlines, bullet lists, highlighted parts. It is not scannable.
• It takes a lot of reading before you actually know what the article is about.
• The column is far too wide. In fact, it is as wide as your screen is, whilst web writing rules says that beyond a certain limit in width (let's say 600 pixels) readers have trouble finding the next line when they are at the end of a line.
• Hardly any white space is used, whilst it is white space that can bring peace and structure to long pieces of content. The side margins are practically zero and stick to the edge of your browser window and the navigation sidebar on the left. Somehow there is plenty of white space between lines though, in fact too much I would say.

All of this seems like nitpicking but usability studies report that web users are extremely impatient and that web writing really is a much different ball game than classic writing. Additional web writing rules not broken by the example above, yet that apply in general:

• Write at a 6th grade reading comprehension level
• Cut the marketing speak, get to the point
• Avoid fancy words and especially made-up words

Surely I have broken many of these rules myself, but it's never too late to change.

PS: no offense intended at the MySQL website, article and author. I was merely refering to how the content is presented.

Many companies that do custom application development do not have dedicated designers, front-end engineers, interaction designers, or whatever they are called today. Instead, these companies rely on application developers to develop a user interface for an application. This situation can have consequences on the usability of the resulting user interface. A common pattern that I personally have been stuck in for years is the CRUD pattern:

CRUD stands for Create Read Update Delete, the basic interactions you need on pretty much any entity you introduce into your application. In your architecture CRUD is likely to appear in multiple layers. If you have a users table, you may have CRUD operations in stored procedures, a Data Access Layer (DAL) and a Business Layer (BL) to carry out the basic CRUD operations on that user table.

The design mistake occurs when you extend that pattern to the user interface. Let's reuse the users table example. If you extend the CRUD model to the UI, you'd probably create a page that enlists users along with links to view, edit or delete an individual user. You'll create a page to view a user and one to edit a user. You'll name your fields and labels to the names used in your actual table. You may even generate the whole UI since it leans so much on the database model.

Through a few simple, subtle examples I want to show you how it can be beneficial to usability to think outside this CRUD model for user interfaces. Here they are:

1. Think about your labels

Labels are what you call your links, buttons, menu options, form labels, etc. They are crucial for usability. A subtle example here is a form label. If we had a users table containing a description field how would you call the form label on the edit form?

The CRUD way is to call it "description", just like the field name. A better label would be "describe yourself", which is actionable, or "About me" which makes more sense to a user. The difference seems subtle, but if you apply this to all labels throughout your design, your UI usability will improve. Form labels are only a start, navigation and button labels are of equal importance.

2. Tables do not equal screens

Stuck in the CRUD-model, we tend to make a one to one relationship between a table and a screen. We build an edit form containing all fields of the user table that should be editable. This does not always make sense, as users tend to think task-oriented, not storage-oriented. This example from Digg.com illustrates my point:

Notice how Digg.com provides different options to edit different parts that evolve around a user. Each option has a dedicated screen that is optimized for the task. Although it is likely that Digg stores all of this stuff in a single user profile table, this is not reflected into their UI. There's even a possibility to do an inline edit of a single field (the avatar icon). Clearly, this part of the Digg UI is task oriented, the way it is stored in the database is abstracted away. In a CRUD approach, we'd have a single user profile edit form containing all fields.

3. Users do not think in fields. They think in natural language.

In CRUD design mode, we visualize data (in read mode) similar to the way we store it. Tabular, data-like, as if we're looking directly at the content of a record or table. Users, however, are not database administrators and not everybody is an accountant. Sometimes natural language is better. Consider this example from Digg (again) where some key fields of the user profile are used to form a natural sentence:

Not only does this take up much less screen space, it also reads a lot more fluently. It is as if I as a user do not have to connect the dots to learn about this great person, the application has already translated it to language I can understand. The application turned data into information. They're not the same.

Conclusion

Surely my examples do not apply in every situation, but they are just examples. I hope this article inspired you to understand the subtle difference between a database-inspired UI (CRUD) and a user-inspired UI (tasks, natural language). It takes practice to think outside the CRUD box, but I feel the result is rewarding. We as developers may not all be professional usability experts, but it never hurts to develop a change in mindset.

Please do rate/comment below.

If you're a regular reader of this blog, you will not have missed my pet project JungleDragon that I keep rambling about. Since I haven't exactly been able to show you much of it, chances are that you stopped caring or are waiting for some more concrete information on what all of it means in practice. 

I'm hoping to change that. Last monday I opened a dedicated JungleDragon blog. Today I am sharing a first batch of screenshots. This batch is focusing on how users and their reputation are visualized in JungleDragon:

JungleDragon Blog: Visualizing users, avatars, karma and classes

Enjoy, and please do leave some feedback in the comments. I'm anxious to hear about your first impressions.

Continue reading...