http://stuffthathappens.com/blog/2008/03/05/simplicity/

Users consume applications through the interface - one chance to either deliver a satisfying experience or fail miserably.

It is a topic I have very strong and passionate opinions of, and motivated by this beautiful prose by Jono over at Not the User's Fault, these are my guidelines for user interaction design:

Know your users

The first step in interaction design is to know who it will be interacting with. Users can be profiled on many criteria, such as age, technical orientation, vocation, cultural background and more. The user profiles created from segmentation of those criteria are called Personas.

While defining Personas is a common practice for designing user interactions, it might not be possible to engage in all the steps required to fully understand the needs and tendencies of the users they represent - such as interviews, surveys, focus groups etc.

This is especially true on the web, where projects have limited funds and are very quick from inception to implementation. In this case, experience and common sense rule the day - but it is still important to define the base Personas for which the interaction under design applies. Going through the process brings out some considerations that can influence design decisions.

Watching actual users go through an interaction is very important to learn about its effectiveness. Watching live users in action is the best learning experience in interaction design.

Know yourself

Knowing your users is the most basic step to interaction design. Yet, for each user type and interaction requirements there are as many possible implementations as there are interaction designers. At this point the interaction designer has to make choices for his users based on his experience, attitude and style.

It is sometimes hard to avoid designing an interaction for yourself rather than for your users. It is a natural tendency to try to solve interaction problems in a way that seems most natural to you, however that might not always be in the user's best interest.

Ideally, the interaction designer is a part of the target audience. When that is not the case, observing prospective users is very important to understanding their needs and deciding on the approach to solve their problems.

I believe that good UI design is more intuitive than science, and in that respect it is not so different from graphical design. However the two should never be confused - as I've argued in my post on common misconceptions in web development.

Keep it as simple as possible

This old mantra is very much an integral part of a successful user interface. By keeping interactions as simple as possible you will:

• Have less opportunities to fail your users
• Give your users less to think about, allowing them to make easier decisions
• Reward your users quicker (at the completion of the interaction)
• Increase the chance that the interaction will get completed at all

A large part of the success of web-based services can be attributed to the simpler interfaces they provide compared to desktop solutions. Some of this is a result of technological limitations on the delivery software (ie, web browsers), but it's hard to argue with the results.

There are several common ways to simplify interactions:

• Use intelligent defaults
• Hide optional paths (or form fields) by default (progressive disclosure)
• Remove unnecessary steps from the interaction (and do so aggressively)
• Reduce mouse clicks. Make each click do more

This is obviously a very partial list, but it's a good start.

For me as a developer, the KISS principle is deeply ingrained in my thought process. Translating it into user interface design took some getting used to, but once it happened it became second nature.

In fact, many parallels can be drawn between UI design and software architecture design almost to the point you wonder why most developers aren't interested in designing interactions (actually I know why - most developers resent users for constantly breaking their code. I know this since a couple years back I had the same mindset).

Don't break conventions - And if you do, make it obvious

The tools available to us developers have evolved much in recent years, allowing us to create richer interfaces and interactions. With power comes responsibility - we need to apply discretion when using advanced techniques and tools, as to not confuse users.

Breaking interface conventions by using new technologies where they are not needed is a mistake.

Conventions should only be broken when they result in a bad user experience or when the alternative is significantly better. The latter is very uncommon when the former does not apply, so be advised.

If you do design a unique interaction (or at least, one that isn't in common use) - make it as obvious as possible for the user. A user can only begin to understand your new interaction when he realizes that something is different. Disguising buttons as links, hiding drop down menus in small target zones, making background changes to the document without notifying the user - all result in user confusion and a bad user experience.

The more you need to educate the user on how to complete an interaction - the less likely he will bother to. Good interactions are self explanatory.

Interactions should be fun

Users interact with your application since they want to achieve a goal. That goal might be to complete an item purchase, to indulge a curiosity, to gather information and many others. There are several factors that affect the user's motivation to complete an interaction:

• How important is the interaction to achieving the user's goal
• How unique is your application (ie, how easy would it be for the user to find a better place to achieve his goal)
• How hard it is for the user to complete the interaction

Negative factors can be offset by a fourth one:

• How fun is it to progress through the interaction

The fun factor in interactions is often ignored as they are considered strictly functional. It's no coincidence the word functional begins with fun. The fun factor of an interaction increases motivation for completing it - it makes your application more unique and it increases the user's tolerance for the interaction.

There are several ways to increase the fun factor of an interaction:

Increasing aesthetics

Making your interface prettier will have a positive effect on your users' perception of it. It's no secret that most of the illusion of Apple's superior OS interface is made on the grounds of aesthetics.

Make it gamely

Computer games have some of the best interfaces of any computer software, and it's no coincidence. You can make your interactions more gamely by adding feedback, reward the user for completing steps and transmit the feeling that the interaction is a part of the user's journey towards his goal, rather than a functional requirement that he must take care of.

Make the interaction do more with less

The user's time and patience are limited. Advance the interaction as much as you can with each user input. Make the user feel the interaction is smart and that it is working with him towards completion.

Learn from others

Those are my thoughts on user interaction design, born out of my experience in web development and of my introspection as a long-time user.

If you are interested in user interface design, the GNOME Human Interface guidelines is as good a reference as you will find.

My favorite web authors on the subject include Jono at Not the User's Fault, Bill Scott at Looks Good Works Well and Aza at Aza's Thoughts.

1. OO code is less performant than procedural code

The number one argument against OO application design from procedural advocates. This argument is based more on intuition than fact. The usual examples pit short procedural code against equivalent OO code in which procedural code comes out triumphant as more terse and performant.

//Procedural, quick and to the point!
$string = 'hello world';
echo $string;
 
//OO, verbose and ineffecient...
class Speaker {
	public function say($string) {
		echo $string;
	}
}
 
$me = new Speaker();
$me -> say('hello world');

Actually, this example compares apples to oranges. Both approaches use 'echo' to output a string, only in the OO approach it is wrapped inside a class method. A more appropriate example for the procedural code would be:

function say($string) {
	echo $string;
}
 
say('hello string');

Which is very similar to the OO code written before. Strong application structure actually does not differ greatly between OO and procedural/functional approaches as my second example suggests, and it is mainly a function of the developer's skill and experience.

OO methodology however gives more language features and scope constructs to deal with code complexities and to handle code reuse, features that would require much more discipline and experience to implement using procedural programming only.

In reality, it is the efficiency of the language parser that will determine performance differences between procedural and OO code. There are no inherent noticeable performance differences between both methodologies for common usage in web applications. More typically in the web environment, IO operations such as server requests or database queries are the bottlenecks of performance / scalability.

Since it's impossible to know in advance what the bottlenecks will be (you can only make educated guesses), I try to follow the Rules Of Optimization:

1. First rule of optimization - Don't
2. Second rule of optimization - Don't ... yet
3. Third rule of optimization - Profile before optimizing

It is much more important to pick a methodology that will promote more maintainable and structured code, as OOP does, to possible minor performance gains. With a well structured design, profiling an application and refactoring slow-performing code is a relatively straightforward process.

2. The backend is the most important part of development

I often see web developers treat HTML, CSS and Javascript as second class languages. While HTML and CSS are not programming languages per-se, correct implementation of both in a cross-browser and semantic way requires much experience and skill that I often see lacking in otherwise proficient web developers.

It is not uncommon to relegate implementation of those two markup languages to web designers or "client-side developers" (which are usually regarded as lower level developers) or to use auto-generating tools for creating markup.

Both approaches are wrong - the client side is an important aspect of the web development process, especially because of the unique environment a web site or application runs in on the Internet - the browser, which has many different flavours each with its own set of problems and constraints.

Javascript (or DHTML) is another domain expertise which is undervalued and yet has become such a common requirement in today's rich Internet applications. Many web developers coming from a server-side language background have an intrinsic dislike for Javascript because of its weird OO syntax, its difficult debugging scheme and its un-uniform implementation across browsers . I would admit to once have thought the same way, however through necessity I came to like Javascript and now consider it an indispensable skill for a serious web developer.

Don't disrespect the client side languages. Sometimes the greatest challenges in web development are found there.

3. Graphical designers are good at user interface design

* This is more relevant for web applications as opposed to web sites

While there is a connection between graphical design and UI design, graphical designers do not naturally make for good UI designers. I can not emphasis this enough. User interface and user experience design is a separate expertise from graphical design. How a user will interact with a site / application is different from how he will view it. It is connected - but not the same.

Quoting wikipedia:

Where traditional graphic design seeks to make the object or application physically attractive, the goal of user interface design is to make the user's interaction as simple and efficient as possible

Graphical designers with no expertise in UI design tend to prefer aesthetics over usability, and this is only natural as it accentuates their strengths. On the flip side, (web) developers don't usually make for good UI designers either.

UI design is important for creating a usable application. Make sure the right people are creating it.

4. The existence of a superior programming language

While some programming languages are considered superior to others (higher level, more featured, better syntax etc.), no one language can be considered the superior language. Debating that one exists is more a statement of personal preferences than a declaration of actual merit.

All modern languages have roughly the same features and can perform most tasks equally well. Some languages might be more suited to specific problems than others, however no one language does everything better than the others.

Some promote specific languages because of highly acclaimed frameworks developed for them (I'm referring to Ruby on Rails, naturally). While this is a more relevant argument, currently all the major languages have at least one serious framework (Django for python, Zend Framework / CakePHP / Symphony for PHP).

Use the language you are comfortable with, but don't deride others based on your inexperience with them.

5. XML is more economic than a DB

Database are notorious for being the major bottleneck for many successful web sites / applications. It is this notoriety that prompts novice developers to seek out alternative persistence layers - and XML is the common alternative.

In general, parsing XML is slower and more resource intensive than querying a database. This is dependent on the complexity of the query, but holds true for 99% of the cases. Furthermore, databases have a much more complete language to fetch, order and manipulate result sets.

XML is a portable format for storing hierarchical data. It is useful for porting data between different databases or between databases and interfaces. However XML is not a database, so don't treat it as one.

If you have more to add to this list, I would love to hear about it.

A design pattern is a general reusable solution to a recurring design problem in object-oriented systems. Design patterns are essentially blueprints that suggest how to solve a particular set of OO design problems while adhering to OO best good-practices (which I've recounted in my Object Oriented part of this series).

To explain by example, lets have a look at the Model-View-Controller pattern, a common pattern in use on the web and a source of much confusion amongst aspiring developers. The Model-View-Controller pattern (abbr. MVC) is a general solution for decoupling domain logic from the user interface, resulting in much better maintainability for both.

MVC suggests an application structure composed of three basic elements:

1. Models - which encapsulate domain logic (such as business rules and database access)
2. Views - which encapsulate presentation logic (such as HTML markup and recurring formatting decorators)
3. Controllers - which handle the application flow by handling requests and match models to views accordingly.

By separating those three concerns MVC aims to provide a reusable solution for improving maintainability, as each can theoretically be changed independently (in practice, things are never so simple). My personal experience has been that MVC is a huge improvement over common PHP development which promotes spaghetti code since PHP can be very easily integrated with markup (HTML).

The MVC patterns is often used with the Front-Controller pattern, which defines a single entry point to an application and allows for ever greater control of application flow (a technique also known as bootstrapping).

There are plenty of other useful patterns for the web-environment, such as Composite, Singleton (and Registry), Factory and Decorator among others.

Design patterns broke into the software mainstream with the release of the apt named book Design Patterns: Elements of Reusable Object-Oriented Software (which I think any serious developer should read). The WikiWikiWeb, which has the book authors among others as contributors, contains many articles on design patters - such as an overview of its history and a discussion on whether design patterns should be language features to name a few.

Design patterns are not limited to software design, and there are many patterns for design problems in all aspects of web development - such as graphical design and user interactions.

Extra reference material:
Patterns for PHP
User interface patterns for the web
Design patterns in web programming
Web patterns by Berkeley University
Ajax patterns

Previously: Testing, Next up: API

After automatic updates does its thing, it promptly suggests to restart the computer. Two options are given - Restart now and Restart later. What 'Restart now' does should be obvious, however 'Restart later' is apparently open to interpretation - as Windows will constantly remind you to restart every 10 minutes or so, and will forcibly restart the computer itself if left unattended.

What is the reasoning behind this nagging reminder? everybody will shutdown / restart their computer eventually. If I chose not to restart it now, could it be that I won't want to restart it in 10 minutes either? is my security compromised to such a degree that I need to be annoyed into submission to restart the computer?

This annoyance is either amplified or dampened (depending on your perspective) by Windows inability to perform system shutdown without user guidance. Often it will stop on one or more open programs which have unsaved data, prompting the user for action (Save? Yes, No, Cancel). If no action is taken, system shutdown will never complete. Too many times I trusted Windows to complete my laptop's shutdown procedure only to discover an hour later that it ran out of battery waiting for my confirmation... (at least hibernation can happen automatically. Thank god for small miracles).

I will conclude this rant by shifting focus to a company I used to respect for having a good user experience - Adobe. Recently, all Adobe products have Automatic Updates turned on for some reason - with no obvious way to turn it off permanently. No offense Adobe, but unless someone can hack into my computer through Photoshop - I don't need your stinking updates. Especially when they clock at around 500Mb since you try to transparently push Adobe Air on to my computer.

Adobe, don't be like Microsoft. Respect your users (or risk losing them).

Disable Adobe updater

UPDATE: Apparently, I am not the only one annoyed by Windows Automatic Updates (big surprise there). Check out this handy guide over at Coding Horror for making your life a little bit better.

When I try to submit my article I am presented with the following form:

First thing I wonder, is what the hell do they mean by reciprocal URL. I know what the term means, but what am I expected to write there? no clue in sight, and no 'help' link to be found.

So I try to fill it up the best as I can, only to receive the following cryptic error:

Hmmm... Listing seems to be broken. No kidding. WTF?? Check it manually? what am I supposed to do with this? I tried variations with the URL (with and without http://), tried changing the reciprocal URL, nada. I looked around the site to see other submitted tutorials and found no clue as to what I was doing wrong.

What is the failure here:

• A cryptic error message
• No further help is offered
• The error is preventing me from completing the process
• No contact email or any other way to ask for assistance

This is what you get when you let programmers design user interactions. (If anybody has any idea on how to solve this, I would appreciate it)