jim.shamlin.com

Optimizing the User Experience

1. Do not display unsolicited windows or graphics (5:3)

Users express an extreme level of annoyance with pop-up windows and layers that obstruct the page they were originally attempting to view.

EN: Note the words "unsolicited" and "obstruct" - this is not a sweeping statement that all window/graphics/layer techniques are bad.

2. Increase Web site credibility (4:3)

The guidance here is to "optimize the credibility of information-oriented Web sites", by including a FAQ, providing an archive of past content, getting links from other credible sites, ensuring the site is updated frequently, etc.

EN: Credibility is important, what with the vast number of sites that contain unreliable information, but I'm not sure that specific features such as those the editor suggests will be effective in establishing credibility. There are certainly factors that undermine creditability (poor visual design, no contact information, unknown publisher, etc.), but that doesn't necessarily mean that doing the opposite will win credibility.

3. Standardize Task Sequences (4:5)

The examples given focus more on data input techniques (asking for a date in the same format, each time you request it), but this would also apply to the sequence of actions needed to accomplish similar tasks.

4. Reduce the user's workload (4:3)

The guidance here is vague (which is getting to be a theme with this writer), but seems to imply leveraging the computational and storage capability of computers to save human effort.

5. Design for working memory limitations (4:5)

A designer should accommodate the limited amount of information a person can remember while working on a task.

EN: Specific information would be helpful, but is not provided.

6. Minimize page download time (4:4)

Minimize the number of bytes that must be downloaded to view an interface.

EN: Again, no specific information, and I would argue that "minimize" suggests an unnecessary extreme. The time a user is willing to wait for a page to load is relative to their context; the time it will take to load is relative to their connection speed; and there are techniques that can be used that will make the wait less onerous. It's also worth noting that most of the studies cited to support this advice are outdated (the days of modem hell).

7. Warn users about "time outs" (4:3)

The guideline seems to imply that pages are programmed to time out after a specific period, and users should be warned of this.

EN: A time-out does not occur with standard Web pages, but script-driven pages that maintain session information by particularly sloppy means may have a set period of time after which that data is released to conserve system resources. Better advice might be to use better software solutions or hire more competent programmers - but if neither of those are possible, a warning to users may be advisable. Something along the lines of "warning, this site is built by programmers who were dropped on their heads at birth" should suffice.

8. Provide information in a directly usable format (4:3)

This is meant in two senses:

First, "format" is meant in terms of the file format: HTML is preferred over other formats that are more difficult to use (require additional software, intended for print viewing, cannot parse the information)

Second, "format" refers to the way in which the data is presented: a graph or a table is more usable than a lengthy text description.

9. Format Information for Reading and Printing (4:3)

The guideline states that information "will either be read online or printed," and suggests that designers should consider this, suggesting that documents over five pages in length are usually printed out and read offline, so those items should be formatted for offline use.

10. Provide Feedback When Users Must Wait (4:4)

The user can be warned when a process (or a file download0 is expected to take a while. A thermometer bar is recommended for any processing that is expected to take longer than ten seconds.

11. Inform Users of Long Download Times (4:3)

Providing the size and download time of large files prepares users to the wait.

As a note, the example given shows download speeds for 28.8, 33.6. 55.6, and T1 connections - this is outdated. I also recall another source that suggests size only, as people may not know their connection speed and the actual time it takes to download a file varies, and si never at the theoretical speed of the connection.

12. Develop pages that will print properly (4:2)

This seems redundant to #9, but its main thrust is to avoid techniques that will make a page too wide to print on standard letter-sized paper.

EN: Current guidance is to provide a link to printer-friendly versions of Web pages, but the technology is still a bit clumsy, as the Web is meant for on-screen viewing. A CSS solution to enable developers to improve print-outs is coming ... someday.

13. Do not require users to multitask (3:4)

The author suggests you should not require users to perform "other tasks" while reading text, nor expect users to remember information from a previous screen unless that knowledge is implicit to the working memory involved in the performance of a specific task.

EN: I would extend this to indicate users should not be required to multitask at all - plan tasks in steps that are performed sequentially rather than concurrently.

14. Use users' terminology in help documents (3:3)

This is a roundabout way of saying "avoid jargon" - standard terms used by designers (navigation bar, breadcrumb links, etc.) are not familiar to users.

15. Provide printing options (3:2)

This echoes the editorial note for 12 (provide a link to a printer-friendly version), but also extends it by suggesting that a user should be provided a method for printing groups of related Web pages (if a book has several chapters in separate pages, provide a method to print them all).

A note is that users print pages because they expect to use them in the future and have concerns that the page may be removed from a site (or moved to an unfamiliar location) in the future.

16. Provide assistance to users (2:3)

The suggestion that designers should "provide assistance to users who need additional help" is vague. The examples suggest that a site designed for users with limited experience should provide them with basic information on how to navigate or use a search engine.

EN; The degree of help is highly debatable - some would have every site teach a user to use a mouse (what does "right-click" mean?). There ought to be a place where basic competencies are enumerated, so that the body of core knowledge an average visitor should have is known, and you can then determine whether other tasks fall outside this core and therefore may need explanation.