There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. — Charles Antony Richard Hoare Feature-creep or featuritis is a tendency to constantly add features which inevitably leads to complex products that are confusing and hard to use. To make matters worse, by adding features we move the product away from solving primary issues - the reason for making the product in the first place. Some products are even conceived with featuritis. Adding features is the easiest to do in the world of software. There is no need for physical changes plus they are quick and easy to accomplish. Thus, most software products suffer from this disease. What causes feature creep? Most software suffering from feature creep are technologically rich solutions which arise from user and business people requests, as well as from marketing research. Engineers add features because they want to create a technologically better product. Because they are the ones controling the development process, we get a technologically advanced software which fullfils the business requirements, but is very difficult to use. On the other hand, business people want a product filled with features believing that would make it more competitive and wanted on the market. However, it must meet client requirements as well. Everything is about quantity with them: requirements, time and resources. By asking the wrong questions like "Wouldn't it be cool to add this feature?", development teams add functionalities which are unnecessary for basic software purpose, the one that supports users' primary activities. As we know, intermediate users use only a part of software functionality, so a large part of the added features is not going to be used at all. Even when the team agrees to focus on core functionalities only, no one is quite sure what these are. There are only assumptions and guesses which easily lead to feature creep. Users and their goals Features are important - they present a picture of software capabilities and value. However, there is something more important which is usually left out - people. People who use the software. Without users in mind, without knowing why they do something, you only ask what are we building and how. The why is left out. Nobody is wandering if there is a need to build something. The users have goals and needs different from those whose create or sell software. When user goals are not recognized, the only thing that we can focus on is individual activities and tasks. Tasks and activities, however, are only steps a user takes in order to achieve their goals. A task is uploading a CV, an activity would be applying for a job, but the goal is to get a good job. Since goals are what motivates people their tasks and activities will serve in achieving their goals; and as tasks and activities map onto features, it is clear they too are serving this purpose. If we don't know what the goals are, there is no limit to adding new functionality. This is where the true nature of featuritis lies. Missing design process A successful product requires not only good technology platform and satisfaction of business needs but also an adequate design process, which is usually missing. Instead of non-designers asking questions about cool features and making decisions based on that professional designers should, as an integral part of the team, seek answers to who the users are, how do they act, which activities they wish to perform and how the software should behave in order to meet their requirements. Answers to these questions are available through various research methods, which should come before the development process begins. Research results should be modeled into Personas - presenting the central point for design process. Personas will always remind us of who we are designing (and developing) the software for and keep features under control. Furthermore, various ideas will be researched and validated, iteratively, through people testing thus allowing us to create software accommodated to users rather than forcing them to accommodate to a software product filled with fancy features. So, an iterative, user-centric design keeps the users in focus throughout the design process and enables us to meet users' needs and goals. Thus keeping non-important features out of scope. Good and bad (and very ugly) example Take Dropbox for example - Dropbox does one thing and it's doing it well - it synchronizes your offline data with their online copy. No fancy features here. Dropbox is focused on what the users need. By answering the question "Why is Dropbox popular and not something similar, like Windows Live Sync, which is free?", Michael Wolfe explains in a short and effective way what's standing behind Dropbox success. To much regret, it is far easier and cheaper to build a feature-rich software than to satisfy the needs and goals of users. We know this due to a large number of bad examples. I once came across an article (can't remember which or where, if anyone knows, please share) explaining how the problem of featuritis was solved by adding a feature which let's you choose a mode: beginner or expert. Another feature to cure featuritis! Unfortunately, this is how many software products look like today - difficult to maintain metastasized mutants, which scare the users. Looks like something you saw recently?

There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. — Charles Antony Richard Hoare Feature-creep or featuritis is a tendency to constantly add features which inevitably leads to complex products that are confusing and hard to use. To make matters worse, by adding features we move the product away from solving primary issues - the reason for making the product in the first place. Some products are even conceived with featuritis. Adding features is the easiest to do in the world of software. There is no need for physical changes plus they are quick and easy to accomplish. Thus, most software products suffer from this disease. What causes feature creep? Most software suffering from feature creep are technologically rich solutions which arise from user and business people requests, as well as from marketing research. Engineers add features because they want to create a technologically better product. Because they are the ones controling the development process, we get a technologically advanced software which fullfils the business requirements, but is very difficult to use. On the other hand, business people want a product filled with features believing that would make it more competitive and wanted on the market. However, it must meet client requirements as well. Everything is about quantity with them: requirements, time and resources. By asking the wrong questions like "Wouldn't it be cool to add this feature?", development teams add functionalities which are unnecessary for basic software purpose, the one that supports users' primary activities. As we know, intermediate users use only a part of software functionality, so a large part of the added features is not going to be used at all. Even when the team agrees to focus on core functionalities only, no one is quite sure what these are. There are only assumptions and guesses which easily lead to feature creep. Users and their goals Features are important - they present a picture of software capabilities and value. However, there is something more important which is usually left out - people. People who use the software. Without users in mind, without knowing why they do something, you only ask what are we building and how. The why is left out. Nobody is wandering if there is a need to build something. The users have goals and needs different from those whose create or sell software. When user goals are not recognized, the only thing that we can focus on is individual activities and tasks. Tasks and activities, however, are only steps a user takes in order to achieve their goals. A task is uploading a CV, an activity would be applying for a job, but the goal is to get a good job. Since goals are what motivates people their tasks and activities will serve in achieving their goals; and as tasks and activities map onto features, it is clear they too are serving this purpose. If we don't know what the goals are, there is no limit to adding new functionality. This is where the true nature of featuritis lies. Missing design process A successful product requires not only good technology platform and satisfaction of business needs but also an adequate design process, which is usually missing. Instead of non-designers asking questions about cool features and making decisions based on that professional designers should, as an integral part of the team, seek answers to who the users are, how do they act, which activities they wish to perform and how the software should behave in order to meet their requirements. Answers to these questions are available through various research methods, which should come before the development process begins. Research results should be modeled into Personas - presenting the central point for design process. Personas will always remind us of who we are designing (and developing) the software for and keep features under control. Furthermore, various ideas will be researched and validated, iteratively, through people testing thus allowing us to create software accommodated to users rather than forcing them to accommodate to a software product filled with fancy features. So, an iterative, user-centric design keeps the users in focus throughout the design process and enables us to meet users' needs and goals. Thus keeping non-important features out of scope. Good and bad (and very ugly) example Take Dropbox for example - Dropbox does one thing and it's doing it well - it synchronizes your offline data with their online copy. No fancy features here. Dropbox is focused on what the users need. By answering the question "Why is Dropbox popular and not something similar, like Windows Live Sync, which is free?", Michael Wolfe explains in a short and effective way what's standing behind Dropbox success. To much regret, it is far easier and cheaper to build a feature-rich software than to satisfy the needs and goals of users. We know this due to a large number of bad examples. I once came across an article (can't remember which or where, if anyone knows, please share) explaining how the problem of featuritis was solved by adding a feature which let's you choose a mode: beginner or expert. Another feature to cure featuritis! Unfortunately, this is how many software products look like today - difficult to maintain metastasized mutants, which scare the users. Looks like something you saw recently?

There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. — Charles Antony Richard Hoare Feature-creep or featuritis is a tendency to constantly add features which inevitably leads to complex products that are confusing and hard to use. To make matters worse, by adding features we move the product away from solving primary issues - the reason for making the product in the first place. Some products are even conceived with featuritis. Adding features is the easiest to do in the world of software. There is no need for physical changes plus they are quick and easy to accomplish. Thus, most software products suffer from this disease. What causes feature creep? Most software suffering from feature creep are technologically rich solutions which arise from user and business people requests, as well as from marketing research. Engineers add features because they want to create a technologically better product. Because they are the ones controling the development process, we get a technologically advanced software which fullfils the business requirements, but is very difficult to use. On the other hand, business people want a product filled with features believing that would make it more competitive and wanted on the market. However, it must meet client requirements as well. Everything is about quantity with them: requirements, time and resources. By asking the wrong questions like "Wouldn't it be cool to add this feature?", development teams add functionalities which are unnecessary for basic software purpose, the one that supports users' primary activities. As we know, intermediate users use only a part of software functionality, so a large part of the added features is not going to be used at all. Even when the team agrees to focus on core functionalities only, no one is quite sure what these are. There are only assumptions and guesses which easily lead to feature creep. Users and their goals Features are important - they present a picture of software capabilities and value. However, there is something more important which is usually left out - people. People who use the software. Without users in mind, without knowing why they do something, you only ask what are we building and how. The why is left out. Nobody is wandering if there is a need to build something. The users have goals and needs different from those whose create or sell software. When user goals are not recognized, the only thing that we can focus on is individual activities and tasks. Tasks and activities, however, are only steps a user takes in order to achieve their goals. A task is uploading a CV, an activity would be applying for a job, but the goal is to get a good job. Since goals are what motivates people their tasks and activities will serve in achieving their goals; and as tasks and activities map onto features, it is clear they too are serving this purpose. If we don't know what the goals are, there is no limit to adding new functionality. This is where the true nature of featuritis lies. Missing design process A successful product requires not only good technology platform and satisfaction of business needs but also an adequate design process, which is usually missing. Instead of non-designers asking questions about cool features and making decisions based on that professional designers should, as an integral part of the team, seek answers to who the users are, how do they act, which activities they wish to perform and how the software should behave in order to meet their requirements. Answers to these questions are available through various research methods, which should come before the development process begins. Research results should be modeled into Personas - presenting the central point for design process. Personas will always remind us of who we are designing (and developing) the software for and keep features under control. Furthermore, various ideas will be researched and validated, iteratively, through people testing thus allowing us to create software accommodated to users rather than forcing them to accommodate to a software product filled with fancy features. So, an iterative, user-centric design keeps the users in focus throughout the design process and enables us to meet users' needs and goals. Thus keeping non-important features out of scope. Good and bad (and very ugly) example Take Dropbox for example - Dropbox does one thing and it's doing it well - it synchronizes your offline data with their online copy. No fancy features here. Dropbox is focused on what the users need. By answering the question "Why is Dropbox popular and not something similar, like Windows Live Sync, which is free?", Michael Wolfe explains in a short and effective way what's standing behind Dropbox success. To much regret, it is far easier and cheaper to build a feature-rich software than to satisfy the needs and goals of users. We know this due to a large number of bad examples. I once came across an article (can't remember which or where, if anyone knows, please share) explaining how the problem of featuritis was solved by adding a feature which let's you choose a mode: beginner or expert. Another feature to cure featuritis! Unfortunately, this is how many software products look like today - difficult to maintain metastasized mutants, which scare the users. Looks like something you saw recently?

I was in the middle of writing a long text in one online web application when my FireFox crashed. I lost the most of what I wrote just because the application didn't have one simple function - autosave. This functionality periodically saves user's work and thus prevents data loss, or at least minimizes it - in case of software crash, only changes that are made after the last save will be lost. Although it seems as if it is quite simple function, there are some issues that need to be considered. Frequency Software crash doesn't have to be the only reason for data loss. Sometimes the internet connection breaks or user simply presses the wrong button - she closes Firefox window instead of one tab. This means that autosave should happen often enough to minimize the effect of unpredictable events. Alan Cooper suggests that, if possible, autosave should be performed after each keystroke or, in other case, when user stops interacting with the interface. When choosing autosave frequency one should always consider application performance and responsiveness, though. Enable autosave by default If an application implements autosave, it should be enabled by default. If autosave isn't enabled, chances are that beginners and perpetual intermediaries will never discover it. I believe I fall into  intermediaries when it comes to Inkscape and I didn't even know it has autosave. But it has autosave functionality which is disabled by default. And since it crashes quite often, it happens that I lose hours of work. Although I am trigger-happy when it comes to saving, I tend to be carried away with design work and simply forget to save. Unobtrusiveness Besides this, autosave should be unobtrusive, which means that it should be performed in background without interrupting user's work. Here's an example of how things can go wrong for users when autosave isn't unobtrusive. I was typing an extremely important email in my webmail client when suddenly a green message box appeared - the same message box which appears after email is successfully sent. I instantly started to look for cancel/discard action and pressed it once I found it. Only seconds after I realized that was an autosave message. But the draft was deleted and I was quite frustrated. Among many others, Google Docs is another example of obtrusiveness - after each autosave the cursor moves to the top of the text. I am sure this is a bug that will be solved but currently it is obviously more than annoying. Besides this bug, Google docs is a good example of how autosave should be done.

When document isn't saved there is information about the last save and enabled Save button next to it. After autosave the message changes and Save button become disabled. Also, autosave is being performed after each keystroke which eliminates the need for "Do you want to save changes?” popups. A problem However, autosave raises one important question - with each save, all previous versions of the same document become unavailable (undo can sometimes be helpful but not enough). Autosave overwrites the same document over and over again. For instance, user might want to edit some template and just print it without saving it at any moment, but autosave might overwrite the template. Some applications use versioning to fix this issue (by adding timestamp to a file name for example). Some, on the other hand, keeps the history of actions where each action refers to one of the previous document versions. But those solutions tends to be complicated and seems as if there's no definite solution to this problem. In any case, if you are not sure about autosave functionality, don't think anymore and implement it - and keep the common save functionality and unavoidable keyboard support.

As I mentioned before forgiveness is very important principle in UI design. But error prevention is even more important - whenever possible try to prevent an error instead of recovering from it. Preventing an error to happen is known as Poka-Yoke principle. The first time I heard of it was in the book Designing for Interaction by Dan Saffer, but it is just another term for "fail-safe". The purpose of Poka-Yoke is, according to Wikipedia "to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur. The concept was formalized, and the term adopted, by Shigeo Shingo as part of the Toyota Production System. It was originally described as baka-yoke, but as this means "fool-proofing" (or "idiot-proofing") the name was changed to the milder poka-yoke." If you search for Poka-Yoke you will find some nice examples such as 3.5" floppy disks, where the shape of disks prevents people from inserting them improperly. But Poka-Yoke can be used in user interface design as well. Applying it to UI design means to prevent an error using constraints and correction, and to warn/inform users about the reasons for prevention. Prevent actions and disable elements Naturally, forms are ideal for applying Poka-Yoke. Its most obvious usage is preventing an action to begin until all of the conditions necessary to perform that action are met. For instance, don't allow form submission until all required fields are filled in. Disable submit button if input field is empty. Disable Delete all link if less than two items in the list are selected. Examples are numerous. I'd recommend you to read (a bit old but good) discussion on ixda.org Hiding and Disabling Menu Items. Restrict user's input You can restrict user's input in many ways - allow only numeric characters, disallow special characters, limit user's input to a specific range or limit the size of user's input. This is usually done by rejecting user's input if invalid characters are detected. You should always make clear to the user why rejection happened (e.g. "You can enter only numbers"). Plugins like alphanumeric can be a good choice here. Mask user's input Similar to previous technique, masking forces users to enter information in a specific format. It is a good practice to reveal mask in input field upfront and make it clear to the user which format is allowed. The problem with masking is that help text is not always clear enough - would users know what "~9.99 ~9,999.99" means? In case when masking pattern is not easily understandable, it is better to show users an example of usage. Correct user's input In some cases, the application will be able to correct the user's input automatically without interrupting her/him. For instance, the application can automatically add "http://" to an URL if user omitted it. Another example is when user enters a value that is larger than maximum allowed. In this case the application can replace the user's input with maximum allowed value while letting the user accept it or change to another value. Other helpful techniques Use defaults In some cases defaults can help further in error prevention. If user wants to book a flight and have to choose a number of passengers, you can set 1 as default (instead of leaving this field empty which will trigger validation later). Another good example I can think of is my android-based mobile phone. Each time user starts a new SMS message, upper-case button is turned on. When user types the first letter it turns off. Use appropriate controls Another good way to provide fail safe is to use specialized controls. Instead of using input fields for dates, use date picker controls and disable associated input fields. Conclusion Those were just some of the examples of how to apply Poka-Yoke in user interface design. The important thing to remember is that whenever an error is detected, make sure you provide a clear explanation of why the process is stopped.

The goal of software, be it web, mobile or desktop applications, is to help achieve business goals. However, without achieving people's goals, and with that the ones of software users, it is very unlikely that the business will achieve its own goals. This is why software projects should start with design, not programming. User centric design, that is, where accent is on understanding users and especially their activities. Not to diminish the value of other aspects, the quality of user experience is the most important. You would think this is obvious? Absolutely not. The fact is that a large number of software projects neglect design completely and this inevitably brings about bad user experience. After posting Designing User Interfaces For Business Web Applications on Smashing Magazine and a large number of comments and e-mails that followed, I realised that problems I faced are still there and little is done to understand them and solve them. And, what are these problems? The first problem is competency and responsibility. Most companies don't have a person in charge of making design decisions. That's what Bill Buxton calls Chief Design Officer (CDO) in his book Sketching User Experiences. Instead of having a person who'll make decisions and understand why they were made and what the consequences are, design is often everybody's and nobody's responsibility. The next problem follows on to the first, and this is the work process. Although it is very ungrateful to generalise things, we could say that the process of developing a typical software project is oriented almost entirely at its functionality. By this I mean implementing business requirements. The problem is that business requirements describe only what and how the system should do (business rules), leaving out the fact that software will be used by people. The process looks something like this:

Project starts by gathering requirements and writing a specification Based on this, resources are planned and estimates given Further decomposition happens to get from abstract to necessary implementation documentation Backend and frontend are implemented Designer is found to create a "theme" for the application (when I hear something like this my left eye starts to twitch) Software is delivered (with a huge delay) Users start using the software, after which starts a series of usability issues, complaints and a lot of work for support staff After a while, it turns out that only 20% of delivered software is being used and sometimes it's not even used at all.

Although I've caricatured a little, you get the point. Many of us have taken part in this type of projects. Where are the users? Where is the interaction with people? Software is used by users and not analysts, project managers, or developers. Most project stakeholders create the software to suit their own needs i.e. for themselves. Most developers, for instance, just don't have the knowledge necessary to design a UI for humans. Just because it makes technical sense, it doesn't mean that it will help user experience. The technology is there to help people and not to make them its slaves. To avoid these catastrophic scenarios, it's necessary to change the whole idea of software development, root and branch. So, instead of creating a "clean, professional and good looking theme" for a completed software it is necessary to design the behaviour of user inteface before the software is created. This includes various aspects of design, from determining the scope to interaction and interface design. Thus, decisions on user interface should affect the behaviour of the system and not vice versa. Technical contraints and business rules permitting, UI behaviour should not be stipulated by system backend implementation. As Jessy James Garett says in his book The elements of user experience: Everything user experiences should be the result of a conscious decision on your part. Realistically, you might have to make a compromise here and there because of the time or expense involved in creating a better solution. But a user centric design process ensures that those compromises don't happen by accident. ... It can be easy to fall into the trap of thinking that we are designing our site for one idealized user - someone exactly like us. But we aren't designing for ourselves; we're designing for other people, and if those other people are going to like and use what we create, we need to understand who they are and what they need. This is certainly easier said than done, because as I have already said in the SM article - a good software product takes harmonization between needs and goals of both the business and the users. To achieve this you need to harmonize management, design and development. Otherwise, we come to a situation where everybody is frustrated, from developers and managers to clients and users. Since this subject is somewhat neglected, I'd like to hear your experiences and opinions.

The true value of undo lies not only in the ability to correct mistakes but also in encouraging exploration and learning which affects confidence in work. It is especially important that Web interfaces be forgiving and allow the users to get confidence since they mostly don't have it.

Although this topic was discussed earlier, a recent debate with colleagues lead me to once again, briefly, point out the importance of undo feature. Back in 2007, A List Apart published Never Use a Warning When you Mean Undo, and we are still not there yet. It is a shame that in 2010 this feature is almost ignored on the Web. The problem is that designers overlook the possibility to undo things on Web. Except for a few examples, all you can have are confirmation dialogs. Forgiving, but not enough.  Users make easy decisions and perform fast actions when they know they are correctable. They are confident in using such systems. For instance, they easily add a product to shopping cart but they are not even closely confident when placing the order. In his book The Laws of Simplicity, John Maeda writes about undoable purchases: Knowing that a purchase is correctable later makes the shopping process simpler because you know that any decision made is not final. Indeed, today's customers don't expect to be held accountable for their purchase. Eager to build consumer trust in their brands, companies are willing to assume the extra risk inherent in a returnable purchase. The losses incurred by the cost of returned goods are outweighed by the gains in customer trust. That is the power of undo. So let's not forget that undo (and forgiveness in general) is much more than possibility to correct an error. It's much more than Ctrl-Z.

The true value of undo lies not only in the ability to correct mistakes but also in encouraging exploration and learning which affects confidence in work. It is especially important that Web interfaces be forgiving and allow the users to get confidence since they mostly don't have it.

Although this topic was discussed earlier, a recent debate with colleagues lead me to once again, briefly, point out the importance of undo feature. Back in 2007, A List Apart published Never Use a Warning When you Mean Undo, and we are still not there yet. It is a shame that in 2010 this feature is almost ignored on the Web. The problem is that designers overlook the possibility to undo things on Web. Except for a few examples, all you can have are confirmation dialogs. Forgiving, but not enough.  Users make easy decisions and perform fast actions when they know they are correctable. They are confident in using such systems. For instance, they easily add a product to shopping cart but they are not even closely confident when placing the order. In his book The Laws of Simplicity, John Maeda writes about undoable purchases: Knowing that a purchase is correctable later makes the shopping process simpler because you know that any decision made is not final. Indeed, today's customers don't expect to be held accountable for their purchase. Eager to build consumer trust in their brands, companies are willing to assume the extra risk inherent in a returnable purchase. The losses incurred by the cost of returned goods are outweighed by the gains in customer trust. That is the power of undo. So let's not forget that undo (and forgiveness in general) is much more than possibility to correct an error. It's much more than Ctrl-Z.

Many agree that tables are a phenomenon in user interface design: they are very important parts of user interfaces but often overlooked. Tables show structured data and their purpose is to make that data readable, scannable and easily comparable. The thing is that in many cases tabular data is obscured. This is why tables have bad reputation and many find them boring. The truth is that the are everything but boring. For people who need tables in everyday work they are hated element that makes them scream. And it shouldn't be this way. Here are some of the patterns that can help in creating less evil tables. Alternating rows styling Ok, this one is pretty obvious. But is it? Take a look at the web applications (and websites) today and you will see that many don't apply it. So it is not obvious and that's why it's first in the list here. By styling alternating rows differently you increase the ability of users to distinguish between overcrowded data in multiple rows and columns. You can use background color or background image. If background color is used it should be just slightly lighter/darker than a page background. For background images you should choose subtle gradients that match your color scheme. You can also combine background colors/images with table borders. Table header and footer should be easily recognizable and to achieve that you can use darker (or lighter) colors than table row colors.

BlinkCampaign uses subtle green color for alternate rows while keeping the header a bit darker. Full row selection If there is a single action that can be performed on a specific row, you can make the entire row clickable. This expands clickable area and declutters an interface. This can be used if, for instance, the only action you can perform on each row is view details. Each row should have hover state styled differently. There are several ways to achieve this effect, among which I would recommend you RowSelect jQuery plugin.

CrazyEgg uses full row selection to expand the details of the current selection (we'll talk about this pattern a bit later). Row which is being hovered is slightly lighter. I really like how they designed this area (as well as the rest of the application). Table sections When you need to group related rows you can consider using table sections (or table grouping). A section is a part of the table that groups related data. All groups shares same set of columns. For example, in a table that shows list of countries, regions are natural way to group rows. Each section should be styled differently and can be collapsible/expandable. Under each section you can show summarized data, if needed.

PulseApp uses table sections to show income and expenses details, but also to group data in subsections that will show even more details. Each section and subsection is expandable. Sorting Sorting is used for cases when users have difficulties in finding a row they want in a very large set of data but they don't know any keyword that can be searched by. Users also sort tables by columns when they want to compare adjacent information. The common practice for enabling sorting on tables is to make header labels clickable. A column by which the table is sorted should be marked. This is usually done by placing an arrow next to column name, indicating in which order the column is sorted (ascending or descending). Clicking on a column that is already sorted should just reverse the order. There has to be a clear difference between sortable columns and the others that aren't. It is a good practice to sort table by default by one of the key columns. Quite usable plugin is TableSorter which is very simple to use. It sorts many known data types and you can define your own as well. It also supports multi-column sorting, but I a not big fan of it anyway.

OneHub application clearly marks the sorted column and sorting order. What I like about this design is that it uses realism even in such small details. Filtering Filtering is very useful when you deal with large amount of data. Use dropdowns, radio buttons or checkboxes to make filter selection. In the example below, builditwith.me uses dropdowns to filter the list of people by profession, interest and availability. However, you can perform filtering only by predefined set of values. For instance, you can filter a list of jobs by it's type: full-time/freelance or by type: design/development. This means you can't filter by First/Last name because there is infinite number of variations. In this case you can use live filter which uses keywords to filter data. For live filter you use input field where users can type any keyword and list is filtered by keywords found in any column.

Builditwith.me has several filter options above the list and live filtering below it. Pagination When dealing with large amount of data it is a good practice to split them in pages. Pagination is commonly used pattern but in many cases it is ineffective. This works for search engines but that doesn't mean it will work in all cases.

Product Planner implements pagination in a common way - with page numbers and prev and next links. But can you tell what is on page 2? Page 3? Sure you can't. But standard pagination can be improved. Take EveryBlock example shown below. Since it is a large addressbook, they used numbers and letters to define pages. Although in their case all pages are shown this would work well with hiding pages as well. You can use the similar approach for other criteria by which tables are sorted. If table is sorted by date, you can show date ranges instead of page numbers (Page 1 can be shown as Feb 10 - Feb 12, and so on). If pagination links become too wide, you can use common page numbers (as seen in previous example) and show additional information while hovering over links.

Continiuos scrolling As a contrast to pagination, continuous scrolling reveals new sets of data while you scroll down the list. There is no option to go to a specific set of data as it is the case with paging. Instead, new set of data is being added to a list. During the load time a progress indicator should be shown. In the example below, a progress indicator on dzone.com is showing how many items are loaded.

There are certain usability and accessibility issues with this pattern so you should test if this work with your users. You can read more about this pattern on UI Patterns. There is a variation of this pattern (or actually another pattern) that doesn't have such issues. Instead of revealing new set of data while scrolling, users can get the next set of data by clicking on more button, positioned at the end of the list. A good example of this can be seen on Twitter.

Fixed table header This is a nice simple trick you can use to keep table header always visible. You can use it on fairly large and complex data sets to help users distinguish between many columns. I don't have any live example so if you know one, please share! FixedHeaderTable plugin can be a good example.

Headerless table If data in a table if self-explanatory there is no need for table header. A table that shows emails can be a good example - email subject, sender and date sent are self-explanatory and distinctive data which doesn't require table header. However, there are cases when you won't be able to remove table header. If there are ambiguous data, such as two dates, you would need a header description for these columns.

Rivalmap dashboard is a good example of headerless table. The information in the table is obvious and formatted in such way that no table header is needed. Expandable rows I already wrote about this pattern and created a small jQuery plugin that you can easily implement. The key point of this pattern is to enable adding additional information or functionality to tables. BuySellAds, for example, uses this pattern to show advertising details about each publisher, while keeping the most important information always visible in master rows.

Row actions Tables are often much more than a plain placeholder for endless data. They also can be interactive elements that can perform specific actions. Actions are usually performed on a single row (they can be also performed on multiple rows, see next pattern). Actions can be shown inline, they can be revealed on hover or shown as a menu. Inline actions The simplest way to show actions is to place them in line with row data, at the beginning or the end of the row. In the example below, Mixx shows voting action at the end of each row which makes voting quite easy.

Hover actions This is variation of the previous pattern that can be used in cases when you have multiple actions. By hiding them and revealing them on hover you declutter interface and make more space for data. Project Estimator by Astuteo shows edit and delete action on hovering each row.

Menu actions If there are a lot of actions you can perform on each row, you can show them as a many that can be revealed on hover or click. DropBox utilizes this pattern very effectively. Since there are a lot of actions you can perform on each file, they show them as a context menu.

Actions on multiple rows A good approach in many cases is to enable users to perform actions on multiple rows. Users can select rows by clicking on a checkbox, usually placed at the beginning of each row, and perform group action by pressing one of the available group action links or buttons. I will use DropBox in example also. Users can select multiple files and perform one of the group actions available from menu. It is also a good practice to enable select all/deselect all functionality which instantly select or deselect all visible rows.

Final thoughts The article covered the basics of the most common table patterns and some live examples. If I missed something please let me know! I also recommend you reading two more articles about tables: Big Table issue that tries to find an solution for tables that are so big they no longer fit in the viewport, and 15 Tips for Designing Terrific Tables that shows many different contexts in which tables can be used.

Many agree that tables are a phenomenon in user interface design: they are very important parts of user interfaces but often overlooked. Tables show structured data and their purpose is to make that data readable, scannable and easily comparable. The thing is that in many cases tabular data is obscured. This is why tables have bad reputation and many find them boring. The truth is that the are everything but boring. For people who need tables in everyday work they are hated element that makes them scream. And it shouldn't be this way. Here are some of the patterns that can help in creating less evil tables. Alternating rows styling Ok, this one is pretty obvious. But is it? Take a look at the web applications (and websites) today and you will see that many don't apply it. So it is not obvious and that's why it's first in the list here. By styling alternating rows differently you increase the ability of users to distinguish between overcrowded data in multiple rows and columns. You can use background color or background image. If background color is used it should be just slightly lighter/darker than a page background. For background images you should choose subtle gradients that match your color scheme. You can also combine background colors/images with table borders. Table header and footer should be easily recognizable and to achieve that you can use darker (or lighter) colors than table row colors.

BlinkCampaign uses subtle green color for alternate rows while keeping the header a bit darker. Full row selection If there is a single action that can be performed on a specific row, you can make the entire row clickable. This expands clickable area and declutters an interface. This can be used if, for instance, the only action you can perform on each row is view details. Each row should have hover state styled differently. There are several ways to achieve this effect, among which I would recommend you RowSelect jQuery plugin.

CrazyEgg uses full row selection to expand the details of the current selection (we'll talk about this pattern a bit later). Row which is being hovered is slightly lighter. I really like how they designed this area (as well as the rest of the application). Table sections When you need to group related rows you can consider using table sections (or table grouping). A section is a part of the table that groups related data. All groups shares same set of columns. For example, in a table that shows list of countries, regions are natural way to group rows. Each section should be styled differently and can be collapsible/expandable. Under each section you can show summarized data, if needed.

PulseApp uses table sections to show income and expenses details, but also to group data in subsections that will show even more details. Each section and subsection is expandable. Sorting Sorting is used for cases when users have difficulties in finding a row they want in a very large set of data but they don't know any keyword that can be searched by. Users also sort tables by columns when they want to compare adjacent information. The common practice for enabling sorting on tables is to make header labels clickable. A column by which the table is sorted should be marked. This is usually done by placing an arrow next to column name, indicating in which order the column is sorted (ascending or descending). Clicking on a column that is already sorted should just reverse the order. There has to be a clear difference between sortable columns and the others that aren't. It is a good practice to sort table by default by one of the key columns. Quite usable plugin is TableSorter which is very simple to use. It sorts many known data types and you can define your own as well. It also supports multi-column sorting, but I a not big fan of it anyway.

OneHub application clearly marks the sorted column and sorting order. What I like about this design is that it uses realism even in such small details. Filtering Filtering is very useful when you deal with large amount of data. Use dropdowns, radio buttons or checkboxes to make filter selection. In the example below, builditwith.me uses dropdowns to filter the list of people by profession, interest and availability. However, you can perform filtering only by predefined set of values. For instance, you can filter a list of jobs by it's type: full-time/freelance or by type: design/development. This means you can't filter by First/Last name because there is infinite number of variations. In this case you can use live filter which uses keywords to filter data. For live filter you use input field where users can type any keyword and list is filtered by keywords found in any column.

Builditwith.me has several filter options above the list and live filtering below it. Pagination When dealing with large amount of data it is a good practice to split them in pages. Pagination is commonly used pattern but in many cases it is ineffective. This works for search engines but that doesn't mean it will work in all cases.

Product Planner implements pagination in a common way - with page numbers and prev and next links. But can you tell what is on page 2? Page 3? Sure you can't. But standard pagination can be improved. Take EveryBlock example shown below. Since it is a large addressbook, they used numbers and letters to define pages. Although in their case all pages are shown this would work well with hiding pages as well. You can use the similar approach for other criteria by which tables are sorted. If table is sorted by date, you can show date ranges instead of page numbers (Page 1 can be shown as Feb 10 - Feb 12, and so on). If pagination links become too wide, you can use common page numbers (as seen in previous example) and show additional information while hovering over links.

Continiuos scrolling As a contrast to pagination, continuous scrolling reveals new sets of data while you scroll down the list. There is no option to go to a specific set of data as it is the case with paging. Instead, new set of data is being added to a list. During the load time a progress indicator should be shown. In the example below, a progress indicator on dzone.com is showing how many items are loaded.

There are certain usability and accessibility issues with this pattern so you should test if this work with your users. You can read more about this pattern on UI Patterns. There is a variation of this pattern (or actually another pattern) that doesn't have such issues. Instead of revealing new set of data while scrolling, users can get the next set of data by clicking on more button, positioned at the end of the list. A good example of this can be seen on Twitter.

Fixed table header This is a nice simple trick you can use to keep table header always visible. You can use it on fairly large and complex data sets to help users distinguish between many columns. I don't have any live example so if you know one, please share! FixedHeaderTable plugin can be a good example.

Headerless table If data in a table if self-explanatory there is no need for table header. A table that shows emails can be a good example - email subject, sender and date sent are self-explanatory and distinctive data which doesn't require table header. However, there are cases when you won't be able to remove table header. If there are ambiguous data, such as two dates, you would need a header description for these columns.

Rivalmap dashboard is a good example of headerless table. The information in the table is obvious and formatted in such way that no table header is needed. Expandable rows I already wrote about this pattern and created a small jQuery plugin that you can easily implement. The key point of this pattern is to enable adding additional information or functionality to tables. BuySellAds, for example, uses this pattern to show advertising details about each publisher, while keeping the most important information always visible in master rows.

Row actions Tables are often much more than a plain placeholder for endless data. They also can be interactive elements that can perform specific actions. Actions are usually performed on a single row (they can be also performed on multiple rows, see next pattern). Actions can be shown inline, they can be revealed on hover or shown as a menu. Inline actions The simplest way to show actions is to place them in line with row data, at the beginning or the end of the row. In the example below, Mixx shows voting action at the end of each row which makes voting quite easy.

Hover actions This is variation of the previous pattern that can be used in cases when you have multiple actions. By hiding them and revealing them on hover you declutter interface and make more space for data. Project Estimator by Astuteo shows edit and delete action on hovering each row.

Menu actions If there are a lot of actions you can perform on each row, you can show them as a many that can be revealed on hover or click. DropBox utilizes this pattern very effectively. Since there are a lot of actions you can perform on each file, they show them as a context menu.

Actions on multiple rows A good approach in many cases is to enable users to perform actions on multiple rows. Users can select rows by clicking on a checkbox, usually placed at the beginning of each row, and perform group action by pressing one of the available group action links or buttons. I will use DropBox in example also. Users can select multiple files and perform one of the group actions available from menu. It is also a good practice to enable select all/deselect all functionality which instantly select or deselect all visible rows.

Final thoughts The article covered the basics of the most common table patterns and some live examples. If I missed something please let me know! I also recommend you reading two more articles about tables: Big Table issue that tries to find an solution for tables that are so big they no longer fit in the viewport, and 15 Tips for Designing Terrific Tables that shows many different contexts in which tables can be used. Thanks to Theresa Neil, one of the authors of Designing Web Interfaces, you can read about three more patterns that she documented: Inline Editing, Super Wide Tables and In-column Filtering.

When you visit a website of a business do you ever wonder who is behind that business? Being transparent online and in business has a plethora of benefits. Users gain trust and have the ability to see the human side of the business. The effects are incredible, from increasing sales to finding like minded clients.Showing that your business is human can easily make you a stronger company. The benefits go two ways though. Not only is it great for your company but it is also beneficial for the user in may ways. In this post I will detail many examples of transparency around the web. As we go through each example I will explain why it is positive, how they have done it, and what it creates to benefit the user experience.Build InternetSam and Zach of Build Internet lay it on the line. As soon as you open Build Internet’s homepage you see the two fellows behind the website greeting you. Click on their photo and be taken to the about page. This page has a larger version of their photo and ways to contact them on a personal level through twitter. This creates a personal connection between the viewer and the owners of the website. Comcast CaresTalk about a marketing and customer service visionary. Comcast’s early adoption of twitter has been followed by many corporations. The difference that is still clear? Having a human face attached. Twitter is a personal social marketing tool. Therefore, when a company hops on board, why should they not also be personal? Freelance FolderFreelance Folder has found an awesome use for their footer. Down there at the bottom of the page they give the bio of the four main authors of the blog. This puts us in touch with the voices of what readers see day in and day out in a new way. Twitter Blog VimeoVimeo brings us a very fun and creative About page. It actually inspires me to take a fun photo with the UXB crew and update our own about page. However, the fun photo of the staff brings a level of fun that people may not perceive when thinking of Vimeo. This presentation gives us a feeling that Vimeo folks enjoy what they do and have a life outside of their product. Smashing MagazineThe new Smashing Magazine design is hot… but I digress. I included SM here because of the addition of their illustration in the footer. These folks are the mysterious men and women behind SM. When clicking on the footer cartoon we are taken to the about page which educates us on who these folks are and what they do. This brings a level of transparency that the previous design did not have. This is Aarons LifeOh, hi there Aaron! In TIAL’s footer we meet Aaron face to face. This could almost be described as a face to face meeting but presented online. Neat idea for any freelancer or blogger looking to create a strong personal brand that has their face attached to business. Mutant LabsMutant Labs is similar in Vimeo in their approach. Instead of a group shot doing something fun they also took on a degree of silliness. Great to get people inspired to take on Mutant Labs as their web developer. It shows a since of creativity right from the start. This in turn can easily increase sales. Level 9 DesignSo, I can’t quite tell if Stan is really an employee of the business or not. If he is, more power to him! Regardless, Level 9 Design brings a great personal sense of humor to their front page. This can be risky but for perspective clients with like minds it could draw in those who can’t quite decide. Bringing in like minded customers can make the process smoother and more successful. Maurivan LuizLanding on Maurivan Luiz I want to hire him. This User Experience Designer has taken personal exposure to a new level. Showcasing himself with a cut out smile can be taken to a deeper level when considering the philosophy behind user experience. HashrocketHashrocket showcases it’s employees on the home page. This introduces you as a prospective client to some folks that may be working with you on your next project. Following the employees is a link to all of the rocketeers. But Hashrocket goes deeper than this, providing a Flickr feed, broadcasting their book club meetups online, and even sharing their company via a vimeo account. You can virtually become a part of their team without them ever knowing. Ok, enough with the creepy stuff. Really, the transparency in this business makes it feel personal and easy to trust. JaredigitalJared’s creativity flows from the page the moment you open it. But wait… Vince from Shamwow? This is an awesome example of using popular culture to connect a visitor to you instantly. ClearleftClearleft has a great about page. It starts with a story of who formed it and when. Then as your eyes move across the page you meet the staff. One of my favorite examples of an about page. CarsonifiedCarsonified’s bio pages for the team members are fun and helpful. Not only do we get a taste of the personal side of the employees but we are also able to easily contact them through email or twitter. Trends & YouNow that you’ve seen some great examples of transparency on blogs, twitter, and business’ websites we get an idea of where we could perfect our own transparency. For starters, personal freelancer’s thrive on self promotion. It makes sense for these websites to showcase a photo of themselves. Additionally, there are benefits from being open with your audience about yourself in bios, on blogs, and on your company profile page.In closing I’d like to leave you with a few questions. What transparency practices did you enjoy most? What other examples do you have? How do you see your transparency changing after this?Further ReadingBuilding Trust with Transparency5 Ways to Make Your Business More TransparentTransparency Is The Future Of Business47 Simple Ways to Build Trust in Your Website or Blog

Websites are social creatures. Or rather, their users are. In turn, the websites you visit are tempered by the users that interact with them. Your experience with a website, say facebook.com, is directly linked to the people with which you interact on that website. But this introduces an interesting challenge for a user experience designer: do you design for the intial experience or the resulting experience?The answer, of course, is both.User experience isn’t only about the first few times a user uses your application. Nor is it about their day-to-day use of your application. Rather, a user’s experience of your application is based upon a user’s full-spectrum relationship with the application itself. Do they trust the application? Does it align with their goals? and finally, the topic of this article: does the application and its community it engage them?Well, what does it mean to engage users? It means giving them cause for involvement. To that end, an engaged user involves themselves with a product, service, or community not because of their own wants or desires, but because of what that product, service, or community stands for. They use the product because they believe in it and its cause. But making people believe in you is difficult work.So UX, how do you do the voodoo that you do?If the long-tail goal of your user experience is about making people believe, then we should take a cue from the masters of “suspending belief”: magicians. To quote Jamy Ian Swiss, a professional magician:“Magic only happens in a spectator’s mind. Everything else is a distraction… Methods for their own sake are a distraction. You cannot cross over into the world of magic until you put everything else aside and behind you – including your own desires and needs – and focus on bringing an experience to the audience. This is magic. Nothing else.Jamy Ian SwissIn every project, an experience happens behind the scenes, in the user’s mind. When many separate factors work together to engage your users, something magical happens. The delivery of this, however, is far from straightforward.Good user experience isn’t something that can’t be “bolted on” after a website or application has been built. It needs to live within the application’s development process, and breathe in every interaction a user has thereafter.What this means is that even if your application has an award-winning design, that alone doesn’t determine it’s overall experience. Just because an application is easy to use doesn’t mean that your users won’t grow tired of it. As I alluded to in my last article ( Focusing Interaction Design with Design Strategy, ed.), for an application to be a huge success it not only has to meet the immediate and short-term goals of the user, it has to appeal to a user’s life goals.And that’s the point of long-tail user experience: users will go on (and encourage others) to support your website if it aligns with their life goals. For example: do your user’s run a successful consultancy? and does your software make their business easier? Then they’re very likely to encourage other professional consultants to consider it. It’s common sense, but the implications are profound.Although the idea is simple, it’s a thorny issue for a website to tackle. Even if a website aligns with some of it’s user’s goals, that doesn’t mean that the user’s themselves won’t cause their own undoing. To explain this, let’s consider the case of myspace.MySpace, we (don’t) miss youLaunched in August 2003, Myspace was the preeminent social network of its day, when web 2.0 really hit it big. And although it garnered much well-deserved attention, many people complained that the site was a cultural wasteland.Why was myspace so abrasive to these people? Well, for one thing, myspace allowed users to customize their profile. Although this by itself doesn’t seem like a bad idea, it was their own downfall; when Myspace allowed everyone unbridled access to their own profiles, their website’s experience was delegated to the lowest common denominator. In the end, bad User Experience was commonplace.In an effort to address this phenomenon, one Myspace templating site, myspaceplease.com, offered 5 tips to design a bad myspace layout, including such gems as: “Use Glitter Text Everywhere,” “Use lots of Movies,” and “Capitalize every other letter.” (Certainly the humor of this article is lost by myspace’s worst perpetrators.)Although its funny in retrospect, the problem in and of itself should be of serious concern to user experience designers. Giving your users the tools to bring down others—let alone their own— experiences is tantamount to a kind of malpractice. It’s analogous to giving car keys to a 7-year-old. If they can get in the car and reach the pedal, you can kiss your car goodbye. A typical myspace profile pageSo should Myspace have removed a user’s ability to customize their own profile? Of course not. The ability for a user to personalize their experience empowers them to incorporate our website into their lifestyle, thereby improving their experience. To continue with our allegory: giving users this privilege to drive doesn’t mean that you can’t define the rules of the road. In fact, that may be the key to your website’s success.Ruling out bad User ExperiencePersonally, it’s hard to imagine a more competitive marketplace than that of online social networks. If a user has already created a profile and connected with her friends on one network, why should she switch? After all, isn’t she’s only interested in the “social” aspect of the network.Despite this, Facebook launched to the public in February 2004. And as of the date this article is being written, Facebook is the most popular online social network.So what accounts for the marked success of Facebook in the face (no pun intended) of such adversaries as Myspace? Well, a lot, really. No amount of research or polling will ever conclude that Facebook trumped Myspace due to it’s superior user experience; although I would assume that it played a part— I know it did for me.Facebook has always pursued a minimalist interface, and the evolution of that interface only hammers this point home. So while Myspace allowed users to stream video, play audio, and write with glitter text, Facebook presented useful information about its users in a compact form. In terms of aligning with their user’s goals: which site was better? The evolution of the facebook.com profile page.Well, better is a relative term. But in terms of connecting real people with other real people, Facebook trumped Myspace, easily. Not only did Facebook protect against spam users more strictly than Myspace, they focused their user’s experience on the people behind the profiles. The effect of this being: even though I might have less friends on Facebook than Myspace, I could be assured that I had more real friends on Facebook; and so, Facebook served its audience to a greater degree than Myspace ever could.In sum, while we design experiences for users, we must take into account the degree with which they can customize the experiences that other users of the site will have.LinkedIn, tooInitially, this article was written in response to a conversation I had with a colleague about LinkedIn—yet another social network; this one with the pretense that activity conducted on its website is strictly business-related.The idea has its merits: far too often, people would use their public profiles on other social networks as if they were their only means of communicating with the world. Because of this, many profiles contained photos, videos, and music that may not be indicative of their owners. While these networks succeeded in allowing people to express themselves, they fell short of being useful tools for potential employees and employers.And so, LinkedIn was born, and I created an account. Immediately after signing up, I was prompted to enter information about the companies I had worked with; as well as prior job descriptions and responsibilities. Then, after this process was complete, LinkedIn presented me with a neat little online resume.That’s nice, I thought. I can use this when I want to impress people. Or, if I’m lazy, I won’t need to put together a nicely-formatted resume; just as long as I keep it all up to date here. Potential employers can see what I’m up to and my former colleagues can give me praise and recommend me. Everyone wins. I’ll just sign out and only sign back in if I need to reconnect with a colleague or search for a new job.Or so I thought. This would have been the end to my LinkedIn story. Indeed, I would consider that interaction blissfull compared to the way I presently interact with the service. Today, with a consistency that is far regular, I’m approached by recruiters who use LinkedIn to “get in touch” with me about what I can offer their business; even though my profile definitely says I’m working full time at a consultancy, this doesn’t deter my would-be employers.So why the rant? Because LinkedIn comes to mind as an example of long-tail User Experience gone bad. LinkedIn took a good idea (connecting a business-savvy audience) and then botched it as they tried to “bolt on” a business model. Today, using Linked in, I can’t even contact other users of the site; I have to pay a fee. The website simply assumes that I’m a recruiter looking to use the site for monetary gain.And that’s what gets me. LinkedIn took away my ability to communicate with others on their website. Their social network is now nothing more than a fancy job-board. Yes, while the market for online job boards isn’t too thoroughly saturated, this is the part where I take my chips and leave. Thanks but no thanks, LinkedIn.I mean to say: I no longer sign in to LinkedIn because doesn’t jive with my life goals. The “social” part of their network is lost on me.Closing ThoughtsDesigning User Experiences isn’t simply about designing a beautiful, usable product; although that’s certainly a huge part of it. Rather, User Experience design is holistic. It’s about creating a platform and then facilitating a function. Done correctly, your website can engage it’s audience towards a higher goal. Seth Godin calls these groups of engaged people Tribes. To quote from his book by the same name:Senator Bill Bradley defines a movement as having three elements:A narrative that tells a story about who we are and the future we’re trying to build.A connection between and among the leader and the tribe.Something to do – the fewer limits the better.Too often organizations fail to do anything but the third.Seth Godin, TribesNot only are User Experience designers responsible for creating the platform, they’re responsible for honing the messages that the site (and its community) sends.Therefore, in forming the blueprint of your next website, make sure that you take into account how users will actually use your website. After your work is done making the website attractive, easy to use, and functional, ask yourself: what will this community do? How will I engage this community once I have it?Creating a tribe is by far one of the most difficult, and yet most rewarding things you can do. And that’s what long-tail User Experience is all about.

It’s interesting to see the latest developments in the phone market. Everyone is scrambling to match the iPhone in form and function in order to hold on to their market share. Sure, the iPhone is a high end phone, so not everyone is going for it, but it at is also a very very successful phone that gets a lot of things right, and the competition knows it. Which is why we’re seeing all those Storms, Pres and Droids on the market lately. They come close, but always seem to fall short. It’s not the features — these phones usually have more features and better specs than Apple’s offering — it’s something else. To me, it all boils down to just 3 things. If any phone manufacturer gets these 3 things right, they’ll beat the iPhone at its own game: 1. Flow 2. Responsiveness 3. Polish 1. Flow Usable devices are all about flow. What’s flow? For every task that people perform on their device there is a sequence of actions they go through. Sometimes it’s just one action — you click a button and whatever you wanted to happen, happens: e.g. pushing the Home button to get back to the main screen. For other tasks you may go through dozens of actions before you reach your desired end. Good flow means the designers have anticipated common tasks, reduced the number of actions required to accomplish them, and ensured the next actions are always there in front of the user so they don’t even have to think about what to push next. Here’s a great presentation by Ryan Singer from 37signals talking about usability — Ryan talks about flow at about 38 minutes in with some great examples. 2. Responsiveness Responsiveness here is all about speed. Stuff should happen when you press buttons or slide your finger across the screen. That’s obvious, right? Yet most phones on the market aren’t very responsive. You slide your finger, and half a second later the screen begins to move in a choppy manner. The device is laggy and slow — it’s not responsive. All of the lag, the waiting between screens, the waiting for applications to launch and for the screen to scroll creates serious friction with the user. When you want to do something you have to wait for the device to catch up. That’s frustrating. 3. Polish Polish is craftsmanship. When you’re finalising the user interface, make it look good. This doesn’t mean adding gradients, shiny gloss, reflections, shadows or a plethora of other visual effects — most of that stuff is superfluous — it means tasteful typesetting, choice of palette and contrast calibration. The important things should pop out at you, while the secondary and tertiary elements should fade into the background. There should be enough whitespace to make things easy to read and scan. That’s all you really need, yet we’re still seeing a lot of blunders in this department. Just look at the settings panels of a Blackberry — there isn’t even any left padding on the text there, which means its touching the left edge of the screen. A little bit of polish will go a long way. Get those 3 things right and you’ll beat the iPhone, or will at least match it. Why? Because the phone is a different device to say, a PC. The phone is always there with you, and its used primary for quick, almost mechanical, tasks. Calling people, checking SMS, checking the time, checking the map, snapping a quick picture. There are many different things you can do with a phone, but all of them are quick actions. This means the phone should aim to be closer to how a mechanical device works. Think about a toaster. You put in the bread, you push the lever, and that’s it. Your action is done, and now you just wait for the bread to toast. The interface is dead simple and its instantly responsive. That’s because it’s mechanical. There’s not a lot to get between you and what you want to achieve. In electronic devices though, there is a lot of “interface” in your way, which tends to also be very laggy and confusing. What you want to do though is get closer to the mechanical toaster and do the users’ actions easily and quickly. That’s why the iPhone is so effective. It’s fast and responsive. It’s also very polished, which raises it even higher. Apple doesn’t care about features because it knows that that stuff just doesn’t matter. What people want is a device that doesn’t get in your way. Other phone manufacturers are too focused on the hardware. Most of them produce really great hardware. But the problem is that hardware is only half the problem — the OS is just as, if not more, important than the hardware it runs on. The OS is the interface — it’s what lets people do the stuff they want to do with their phones. The OS is also the thing that my 3 points above are governed by. Forget features, forget specs, forget comparison charts. A comparison chart will never tell you about user experience and usability, and in the end, that’s what matters most in a pocket device.

If we look at interfaces in operating systems, we’ll see that there is usually a set of unified interface elements that’s shared not only by the operating system’s own tools, but also by third party programs running on that operating system. For example, Apple’s OS X had a UI called “Aqua” for quite a few years now that gave the buttons and other interface elements a certain look a feel — a liquid look for the buttons and a more metallic/plastic look for the texture of the windows themselves. They’re now moving towards a more aluminum look that will bring it closer to the look and feel of their hardware products. Until OS X Leopard, there were actually several ‘branches’ of the UI spread around Aqua. There were the plastic windows, the brushes metal windows and the darker aluminum windows. Buttons looked different in each one of these ’styles’. Leopard, the latest release of OS X, has unified the look across the board.

The interface in OS X looks the same on (almost) every app Companies making apps for OS X don’t reinvent the wheel and go with the toolset given to them by Apple, so the UI in their apps looks and feels like that of OS X. The same thing on Windows — Windows XP may look different to Vista and 7, but the apps running on each system tend to use the interface elements provided by the OS, so they fit in and feel ‘native’ to the system. Well… most apps do — some don’t, and choose to fashion their interface with a completely unique look. Why’s a unified interface important? The main argument is that people learn what each interface element looks like — what a button looks like, what a tab looks like, what a scrollbar looks like, and so on. With a unified interface you only need to learn this element once. If every other tool or third party app on the system then re-uses the same graphics and styles, the user can easily recall the function of that element. It also just looks good to have a consistent style across the board. It’s clear and orderly. That’s the situation on the desktop OS at least — it’s mostly unified, with a few exceptions. On the web though, it’s a different story. CSS allows us to style interface elements displayed inside a browser — things like form input fields, buttons and navigation menus. Without any styling, these elements take on the look of the operating system the browser is running under — or even that of the custom styles provided by the browser itself. A lot of web applications style their elements with CSS. A lot of others just leave them as they are. Using the same, un-styled, application then on different computers and on different browsers will give you a different experience. UI elements will look different each time. You might even get different fonts, depending on what fonts you have installed on that particular computer or device. Using styled applications is another story. The interface remains consistent across different computers (more or less). Each styled application looks different from other styled applications though because the developers create their look themselves from scratch every time. There is no consistency — you have to learn the interface when you begin using the app. This leads me to the question of the post: should there be a unified set of styles for web interfaces? Just as Apple has consolidated their shattered OS look and feel in Tiger with their unified interface in Leopard, it’s possible to unify the look of interfaces of the web with CSS. Not just a framework — but a set of carefully crafted and good looking styles for forms, menus and windows that would remain consistent across devices and browsers. Such a stylesheet will give developers a strong foundation on which to design their app, and will provide a consistent experience for all the users of the apps sharing these styles. Why now and how? The reason why I bring up this topic is because an adoption of a certain technology is beginning to grow. That technology is CSS3. While CSS3 is still not fully supported by the browsers, all of the modern browsers support some of the common elements of it. These advanced styling properties allow for things like rounded corners, box shadows and text shadows, allowing the designer to create beautiful interface elements without resulting to many images (or indeed, any images). More important, these advanced properties do away with useless markup bloat which was essential for things like rounded corners. With CSS3 you can style HTML elements without additional markup — just target each element directly and apply the advanced properties. Here’s an example of two inputs, a text input and a submit input, that I’ve styled earlier. The markup for both elements is pure — no wrapping divs or custom classes — the CSS targets each by type — e.g. input[type=text]. This will look the same in all modern browsers across different operating systems (the font may differ slightly as it falls back to the next available one):

Text field and a submit button styled with CSS3 Now.. Internet Explorer 6 doesn’t support these kinds of type selectors — or any other advanced CSS3 properties for that matter. Newer Explorers support type selectors but won’t give you the fancy stuff like rounded corners or shadows (although this stuff should degrade gracefully because after all, sharp corners aren’t the end of the world as long as everything else functions properly). The other modern browsers support enough right now to start styling buttons and other interface elements without additional markup though. So it’s possible to make a comprehensive CSS that will provide attractive, and more importantly, unified styles to form elements and menubars (which will need minimal markup and classes, specified by the stylesheet) — but is this a good idea?  This is a project I’d like to do but I’m wondering whether it’s worth it. I’d love to read your comments.