Web application 2.0 features

Show a success message at the top of the page after the user has successfully made a permanent change to some data. Use a green tick icon, and be specific about what changed.

This is an improvement on the standard behaviour, which should be to show a page that includes the updated data, because this makes it more explicit which data changed. It also supports the case when there is no new version of the data to see, such as when you delete something. This may also be helpful in making the user realise that they have made a permanent change when they did not think they had.

For example, LinkedIn shows this success message after you send an invitation to someone.

Allow users to enter incomplete data, so that missing data does not break the system. Remind the user that the data is incomplete; ask nicely for the rest.

You may want users to enter certain information, but you probably cannot force them to. People are likely to be cleverer than your software, and if users just type 'unknown' into required fields, you have gained nothing other than annoyed users. Besides, some users will always be able to avoid entering data in your software by simply not using it.

Instead, let your users input incomplete information, so they can go to lunch without finishing a data-entry task, and make sure your software can handle this case.

Handle typos by validating input data; show a validation error for user-entered data that could not possibly be correct. Be careful not to be too strict.

It is usually a good idea not to be over-zealous with input validation. It is a good idea to reject obviously wrong values, because there are some mistakes that you can spot. For example, if some enters '197' as their year of birth (or their age) then you can be sure that this was not intentional.

On the other hand, there is probably always someone with an address or name format that you did not expect, and they are likely to be annoyed if you reject their input. For example, 37signals staff were not impressed by the error "Your Employer Name cannot contain any numbers":

Draconian validation may seem justified in the name of data quality, but even if it does achieve that it will probably do so at the price of having far less data in the first place.

When displaying data, warn the user about likely problems or gaps in the data.

If you allow incomplete data, then you may need to warn the user about the consequences. For example, an Amazon wish-list without a delivery address shows the warning 'Please enter a delivery address so that items on this list can be bought by others and sent to you.' This is helpful for the list of presents that friends and family can buy me, but I do not want my fans to buy me computer books that my employer will pay for so it would be annoying if an address were required.

Data warnings can also add more explanation to how your software works. Instead of a missing value, you can explain that 'Shipping costs cannot be calculated until you enter a delivery address'.

Finally, you can warn the user about inconsistent data, when you do not know which value is wrong. For example, if the user enters a price of €100 and VAT (sales tax) of €2000 then one of the amounts has to be wrong, but it could be either one.

Implement the OpenSearch API so that other software can perform queries and display the results, including search interfaces.

For example, Firefox 2 and Internet Explorer 7 can add OpenSearch providers to their search interface, so you can search the browser’s search field. Alternatively, other web applications could use this and other APIs in your software to mash-up your data with data from other applications.

If your application’s data is date-related, then make the data available in iCalendar format, to allow people to view the data in calendaring software. For example, a time sheet application could display time spent on a calendar, as illustrated in iCalendar feeds using iCal4J.

This is an example of letting people use dedicated desktop applications to view data in a dedicated user-interface, instead of recreating that user-interface in your web application.

For example, iCal, which can subscribe to an iCalendar feed, has a better calendar user-interface than the average on-line calendar. Google Calendar, meanwhile, provides a public or private 'calendar address' that allows you to view calendars in an iCalendar client such as iCal.

In the same way that iCal has a better calendar user-interface, Google Earth has a better geographical user-interface. If you have geographic data, generate dynamic KML documents that people can use to view the data in Google Earth or on a map.

For example, a Tagzania category has a KML icon that provides the same data via KML.

If your data is not a good fit for an XML format for which there are dedicated applications, such as RSS, OpenSearch and KML, then invent your own XML mark-up and export your data in that format. You probably need to do this anyway, to be able to include all of your application’s data.

This makes all sorts of applications possible, not least because you can transform this XML into any other kind using XSLT. This is also the sort of feature that gives people a warm fuzzy feeling because it protects them from data lock-in and allows them to make their own back-ups.

Once you have functionality to export your data to a file, allow the user to Restore database from back-up by uploading a previously-exported file.

This makes it easy to move data between accounts or servers, and makes the XML back-up files more useful.

Allow logged-in users to post comments on pages that display the application’s key data. Comments do not need to be threaded, but should include the user’s name and the date and time posted. Allow the author of a comment to delete it. Optionally, make comments editable for their authors, and for advanced users, support rich-text mark-up such as one of the many wiki syntaxes. You do not need comments on every kind of data, just the most significant entity. For example, in Amazon you can comment on books and other products, but not on authors or publishers.

Comments are simple to implement, but can quickly deliver value in more than one way. Initially, comments are a useful way to let users annotate application data with unstructured data that would otherwise be lost, or not made available for other users. Beyond that, comments allow conversations about the data that are displayed in context. These conversations can be much more valuable and accessible when centred around the data like this, with ad-hoc participants, rather than centred around a particular group of people.

A series of comments about a software bug in a bug tracker like JIRA is always in the context of a particular bug, unlike conversation in a discussion forum. Even worse is e-mail, where people who arrive late to the conversation miss the beginning. For examples, comments in Lunatech’s JIRA on a bug that would be fixed by an upgrade - the bug is the context:

Allow users to add simple tags to data in your application, and delete them again. Then add tag-based data browsing - click a tag to view other items with the same tag. To keep tags manageable, add functionality to globally rename or merge tags. Optionally, implement social features: who added a tag to an item, who else uses a tag, what each person has tagged.

Tags are the poster child of Web 2.0 and, ironically, the least flashy and most useful of many of these features. Useful and not-flashy especially applies to del.icio.us which is the best source of ideas for how to use tags. For example, tags on a photo in Flickr:

However, tags are actually more interesting when you start tagging structured data, rather than just web pages via del.icio.us. By tagging structured data you are adding semi-structured meta-data to the structured data. For example, if your application’s database does not have a status field with 'obsolete' as an allowed value, you could simply tags items with an 'obsolete' tag. This would let you browse a list of obsolete items, in a way that would not be possible if you had merely added a comment that 'this item is obsolete'.

If the application knows the current user’s e-mail address, then give the user a simple way to 'watch' a particular page or data item, and notify the user of changes to that data by e-mail.

This is a good example of a useful feature that has a very simple user-interface - an icon with two states - and does not make the application more complex to use. Of course, this can require a lot of effort to implement, but that is another story.

The value of this feature is that in some applications, knowing when data changes is as useful as being able to find the current data. This also allows the application itself to become the focus of collaboration, because people can use the application to tell each other that data has changed, rather than make the change in some database and manually send an e-mail. (Or, more likely, just send an e-mail and not update the database.)

For example, if you use a wiki for reference information, you probably need to know when there is a new version. Each page in Confluence shows this envelope icon in the corner. When you click the inactive version (left), you start watching the page, the icon changes to the active version (right) and whenever anyone edits the page you get notified by e-mail.

In a multi-user application, show a list of recent activity for all users on the home page. For a content-based web application this means new and updated pages, and comments; for a catalogue system, show updates to catalogue items.

Initially, the recent changes list appears to just mimic the Recent Documents list in desktop applications, in order to provide a short cut to data that you were recently working on. However, in a collaboration application - where multiple users work on the same data - changes made by other people turn out to be more interesting.

The key benefit of this functionality is that it provides a simple and immediate answer to questions about how much activity there is, who is working on what, what has changed recently, and which topics are currently hot. To show who is doing what, the list entries must indicate who made the update. To show how much activity there is, and how recently (e.g. today), entries must indicate their age; ages like '2 hours ago' or '13 days ago' are more useful than dates and times here. To expose current topics, show a category for each entry.

For example, the Codehaus Confluence shows recent updates like this on its dashboard:

One special case is a wiki: if you cannot customise the home page the way you can with Confluence’s dashboard, then use the wiki’s Recent Updates page as your home page. By extension, on a company intranet, which should be a wiki, make a list recent changes half of its home page.

Make the application home page, for logged in users, an overview of the currently most-interesting data. This can be context-sensitive, by being dependent on the current user and the current date. Consider data aggregation and high-level statistics, recent changes and the results of key searches. Optionally, implement a Portlet interface that allows the user to customise the dashboard by choosing Portlets, also know as widgets these days.

The idea of a dashboard is that instead of presenting a single view (or report) on the application’s data, it presents many concise summaries of the data, each addressing a different question. Ideally, these are task related, so that the dashboard effectively incorporates a to-do list of application-related tasks. This is related to the kind of content the front page of a web site has. Interestingly, management dashboards often have a 'dumbed down toy' image among software developers, which may explain why they are not more popular in web applications.

For example, JIRA has a sophisticated dashboard that lets you mix and match different Portlets for different views on your projects. The task-list aspect is that you can view overviews of outstanding issues of software development projects, such as a the 'number of unresolved bugs per project', or a list of 'issues assigned to me'.

Similarly, discussion forum software often has a dashboard that shows lists of most read, recent and unanswered posts.

In an application where you need to repeatedly return to particular items that are difficult to find, allow users to add an item/page to their 'Favourites', and make these items easily accessible from the home page.

This makes sense in applications where there is a small collection of 'things I am currently working on', while finding those items is inconvenient or difficult. This may be because the total number of items is large, because they do not have memorable names or locations to search for, or because you use the application too infrequently to remember what they were.

It is usually a bad idea to duplicate standard web browser functionality in a web application. Provided that your web application has bookmarkable URLs, you could simply use the browser’s bookmarks functionality instead. However, web browser bookmarks support remains primitive: it does not let you easily browse just bookmarks in the current site/application, or sort them with recent additions first. Another advantage of listing favourites in the application is that the application can annotate each one with more information, as for the Recent Changes described above, such as each favourite’s category.

Note that favourites can be combined with watching for changes, so that you get notified of changes to your favourites without a separate user-interface for turning on notifications.

Make some data editable using an Ajax click-to-edit control, such as the Dojo Inline Edit Box, rather than using a separate edit page.

This can make it more convenient to make edits to simple data that does not need a complex interface, such as a short piece of text like a title. This is not the case, however, when the editing task involves several attributes at the same time, in which case a separate edit mode is better. An intermediate possibility, of course, is a group of fields that all become editable when you click any of them.

For example, when you are logged in to Flickr, you can edit a photo’s description simply by clicking it: