Monthly Archives: January 2008

Usability in web applications (Part 3)

This blog post is the third part in a series on web application usability. As stated in the first post, users will get frustrated and stop using an application if it is not easy to use. In this series of blog posts some examples are given on improving the usability of web applications. These examples also hold for ‘normal’ websites, but are specifically important for web applications. In this specific blog post the topic is the back button.back-button.png

Back button
The back button is the second-most used navigation feature on the web (the most-frequently used is following hypertext links). Users know that they can try any link on a webpage with the certainty to get back to familiar terrain by one or two clicks on the back button. The back button therefore enables a website visitor to ‘explore’ the website. In traditional software applications the ‘undo’ command serves this purpose. It has been a strict design guideline to include an ‘undo’ functionality in software applications. So it is important that the functionality of the back button works in web applications.

back-button2.pngThe two screenshots on the right give a good example of how the function of the back button is broken in a (flash) web application. In the first screenshot the starting point is displayed. In the second screenshot the color of the shirt is changed. Unfortunately it is not possible to undo the color change (note that the back button is not clickable). On the upper right in the application there is a reset button but that resets everything. In the present tool it is not possible to undo the latest change. It would be possible to build in an undo button within the application, but since it is a web application users expect the back button to have that function.

Next up in the series ‘Usability in web applications’ is standard usability guidelines.

Tagged , ,

Usability in web applications (Part 2)

This blog post is the second part in a series on web application usability. As stated in the previous post, users will get frustrated and stop using an application if it is not easy to use. In this series of blog posts some examples are given on improving the usability of web applications. These examples also hold for ‘normal’ websites, but are specifically important for web applications. In this specific blog post the topic is nonstandard scrollbars.

scrollbars.pngNonstandard scrollbars
According to Jacob Nielsen in several applications, users missed many of the options because of nonstandard scrollbars. A scrolling control is a standard user interface element in application design, and (as always with usability) it should be designed in accordance with users’ expectations. As stated by Nielsen, users often overlook nonstandard scrolling controls, and thus never get to scroll the lists to see the hidden options. So only use scrollbars that actually look like scrollbars. Horizontal scrolling is another point to avoid. On the web, users only expect vertical scrolling and no horizontal scrolling. And like stated before, all standard design elements should meet user expectations.

According to Nielsen there are five essential usability guidelines for scrolling and scrollbars:

  • Offer a scrollbar if an area has scrolling content. Don’t rely on auto-scrolling or on dragging, which people might not notice.
  • Hide scrollbars if all content is visible. If people see a scrollbar, they assume there’s additional content and will be frustrated if they can’t scroll.
  • Comply with GUI standards and use scrollbars that look like scrollbars.
  • Avoid horizontal scrolling on Web pages and minimize it elsewhere.
  • Display all important information above the fold. Users often decide whether to stay or leave based on what they can see without scrolling.

Next up in the series ‘Usability in web applications’ is the back button.

Tagged , ,

Usability in web applications (Part 1)

Usability is a quality attribute for ease of use. Research has shown that usability is a very important factor for websites. It actually is a limiting condition. If a site is not easy to use, a lot of visitors will navigate to other websites to find what they are looking for. That is the cruel thing about the web: competition is just one click away. Usability is also a key factor for web applications. If an application is not easy to use, users will get frustrated and stop using the application. This blog post is the first part, written by Jurjan Huisman, in a series on web application usability. In these blog posts some examples are given on improving the usability of web applications. These examples also hold for ‘normal’ websites, but are specifically important for web applications.

electronic-form.pngElectronic forms
In electronic forms the required fields should be marked to actually show that these fields are required. When a user fills out the form and presses the submit button, all the required fields that have not been filled out should show an error message. This error message should not be displayed in a pop-up, but right next to the relevant input field. To take this even one step further, ajax-technology can be used to display error messages on the fly. For example, ajax can be used to notify the user of a wrongly spelled e-mailadress.electronic-form2.png

As an addition to the error messages other aspects of electronic forms are important as well: the cursor should automatically be positioned in the first data entry field and pressing the Tab-key must lead the user through the input fields in a logical reading order. Obviously, it is a big plus when information that can be filled out automatically is done so. For example, when someone fills out his or her postal code and house number, the streetname and city fields are automatically filled out. Next to that, when you hit the back button of the browser, all the previously filled in data of an electronic form must not be lost.

Next up in the series ‘Usability in web applications’ is nonstandard scrollbars.

Tagged , ,

Using Enterprise 2.0 tools ‘in-the-flow’

Michael Idinopulos has made an interesting distinction between different uses of wikis. According to him wikis fall into two broad categories:

  • In-the-Flow wikis enable people to do their day-to-day work in the wiki itself. These wikis are typically replacing email, virtual team rooms, and project management systems.
  • Above-the-Flow wikis invite users to step out of the daily flow of work and reflect, codify, and share something about what they do. These wikis are typically replacing knowledge management systems (or creating knowledge management systems for the first time).

This is exactly why implementing a wiki for knowledge management purposes is not just a matter of merely implementing the wiki. People do not collaborate very much in above-the-flow ways without an incentive to do so. Therefore it is critical to realize that, as Idinopulos puts it, “the challenge of getting people to use above-the-flow wikis is an above-the-flow thing, not a wiki thing.”

Knowledge management contributions
A knowledge management system can be a very valuable asset for a company and the collaborative input of employees brings the system to an even higher level. Unfortunately contributions to these systems are from an above-the-flow type. Therefore Andrew McAfee proposes the idea to change job definitions to put these kind of contributions in-the-flow. He suggests that at least for some employees their job description could state something like “being helpful at the enterprise level using Enterprise 2.0 tools such as blogs, wikis, folksonomies, Q&A forums, comments, prediction markets, ratings, etc.” Because companies would truly like their people to spend some portion of the work week looking around, helping others, communicating and using their expertise, etc. Therefore McAfee suggests to put these IT-enabled activities in the flow.

Create support for Enterprise 2.0 tools
Next to this ‘top-down’ approach to stimulate the usage of these type of Enterprise 2.0 tools, it is also important to create fertile ground within the organization itself. To do this a pilot should be started with proponents of the tool. Start a wiki project for example with IT minded employees, since they have no technological barrier to start using the wiki. When the rest of the organization sees what the added value of the wiki is for day-to-day tasks, they will start working with it as well.

Create momentum
McAfee states that to date it has been hard for people to work above and beyond their ‘normal’ jobs. Because doing so typically involved physical displacement – hopping on a plane, going to a meeting, etc. – and so was time consuming, inconvenient, and often costly. A good point he makes is that Enterprise 2.0 technologies greatly lower these barriers to work above and beyond one’s ‘normal’ job. But unfortunately theory does not always equal the perception of the users. Therefore it is important to create momentum for the tool to support its usage. Like stated before this can not be done by simply implementing a tool. To create momentum, organizations could (among others) put participation in job descriptions and start a pilot with proponents of the tool.

Tagged ,

Davenport vs McAfee about Enterprise 2.0

Last friday Tom Davenport and Andrew McAfee had a discussion about enterprise 2.0 hosted by Jim McGee from the FastForward Blog.

The discussion did not hold very much substance. There was a discussion whether the name enterprise 2.0 was relevant or not, which to me is a completely irrelevant discussion. But the two sides (Davenport: contra enterprise 2.0, McAfee: pro enterprise 2.0) are a classic example of the hurdles you have to take when implementing enterprise 2.0 tools in your organisation. Davenport represents the traditional thinking (web 1.0) and McAfee represents the next web (web 2.0). According to Davenport it is a hype, technology has been around for decades and enterprise 2.0 is the wrong name. He agrees with the success of web 2.0 but does not seem to understand the possibilities of enterprise 2.0. He sees the tools that are clustered under the name enterprise 2.0 as tools that have to fight against Sharepoint and others. I do not think this has to be the case, since you can also use enterprise 2.0 tools like a wiki to function as an addition to the tools you already have. It does not always have to replace these systems. Because of the ease of use it is an addition.

Accepting tools from the enterprise 2.0 era is more a cultural issue than a technology acceptance issue. But you do need to have the right tools to facilitate this cultural change! The one depends on the other. Davenport says that they could have achieved the same effect years ago with tools like Sharepoint or Lotus Notes, but why did this never happen? Because these tools did not have the ease of use that the current web 2.0/enterprise 2.0 do have. According to Davenport the possibilities of web 2.0 have been around for about a decade. I think that only the theory of web 2.0 that has been around for a while, but the actual technology and actual working tools have not. This because usability is one of the key factors of the success of web 2.0.

After an hour of discussion I did not learn anything new, but the discussion subject is very current. I think anyone who is trying to implement a web 2.0 tool in their enterprise has encountered the issues Tom Davenport mentioned in this discussion.

To listen to the mp3 of the discussion, click here

Tagged , , ,