Web site usability testing: recommended procedures

Usability testing of web sites is a true test of how people actually use a
web site and it is an essential element of quality assurance.

A) When to test

• at the web site's conception (start by testing a printed mockup of the
  home page)


• before planning a redevelopment


• repeatedly during (re)development

B) What and why are you testing?

1) In a general test:

• whether the user gets the point of the page(s)


• whether the user understands the navigation system


• whether the user can guess where to find things.


• how do users interact with the web site you are testing?


• what is difficult for people to do?


• where do they get lost?


• what makes sense to them?


• what makes them feel distrustful or insecure?


• what do they like and what do they hate?

2) In a specific test

• can the user accomplish a key task?


• can the user find something specific?

C) How long is a usability test?

• 5 minutes (for a single page design) to 1 hour (for a general response to
  a whole site or new design).

D) Users should be outsiders

• not involved with the web site in any way


• completely new to the web site (so don't ask the same person twice)


• somewhat familiar with the Web in general.


• In a full-blown, traditional usability test, a usability consultant would
  select members of the web site's target audience. This requires great effort,
  and the rewards are comparatively small

E) Where to test

• run tests in the user's home or work place. Benefits:


• the user feels more relaxed


• the user doesn't need to learn new systems


• you get to see how the web site works on different computers, browsers and
  modems.

F) Prepare a script

• Introduce yourself


• purpose of test, confidentiality issues


• open-ended questions, 'what if?', 'tell me more'


• Allow users to try to accomplish the task in their own way


• End the test: say thank you, reply to previously unanswered questions,
  give payment or a gift if appropriate.

G) Plan how you will take notes

• a column for comments on your script?


• blank paper for a mindmap?


• printouts of key pages?

H) Test the script

• test your script with a colleague acting as the user

I) Now start the test

• note every occasion the user:


• hesitates, worries, or is forced to think


• misunderstands something


• gets frustrated or annoyed


• gives up.


• The whole point of the test is to see what users do alone, without you helping.

Ref: http://www.webpagecontent.com/arc_archive/124/5/

Website Checklist

1) Validation

1. Validate the HTML - This can be done with a validator such as the W3C valiator
   or WDG validator.


2. Validate the CSS - This can be down with W3C CSS validator.


3. Check for broken links - Obviously we don’t want broken links on our site.
   We can use Link Valet (which is convenient for checking a few pages) or Xenulink
   (convenient for checking a whole site).

2) Flexibility

1. Try varying window sizes - It is obviously easy to test window-sizes smaller
   than your own screen-size. Testing larger window-sizes might seem impossible,
   but you can do a rough simulation using the zoom facility of the Opera browser
   – zoom down to 50% and you get a screen twice the size. It may not be very
   readable, but any major layout errors should be obvious.


2. Try varying font sizes.

3) Speed

1. Access the site via a modem


2. Check image size specifications - check that at least the text of the page
   appears quickly. If it doesn’t (or if it dances all over the place while the
   page is loading) it is probably because you have forgotten to specify HEIGHT
   and WIDTH attributes on some of your images. Specifying these enables the
   browser to work out where the text needs to go, and to display it before the
   images have finished downloading.

4) Accessibility

1. Test accessibility - This is mainly important for handicapped users, but
   also relevant for e.g. people who use a text-only browser. It is well worth
   running a few pages through a checker such as Bobby or Accessibility Valet


2. View in text browser - Incidentally the Opera browser has a built-in text-browser
   emulator.

5) Browser independence

1. Try different browsers


2. Check printed pages - You should at least be able to read the text easily,
   and not have lines running off the right-hand side of the page. This can be
   done using the “@media print” or “@import print” CSS features.


3. Switch javascript off - The basic text and navigation should still work.
   Clearly if you use javascript to do something important. Avoid nearly-meaningless
   messages like “Javascript needed to view this site”. If you have something
   worth showing, tell the user what it is, e.g. “enable Javascript to see animation
   of solar system”.


4. Switch plug-ins off


5. Switch images off - This means, in particular, checking that sensible ALT
   texts have been provided for images.

6) Other checks

1. check non-reliance on maito - about 50% of readers cannot use mailto links.
   Many readers prefer a form. The best thing is to provide a contact page which
   has both a mailto link and a contact form


2. check no orphan pages - An orphan page is one that contains no links back
   up to its ancestors – i.e. to pages higher in the hierarchy of the site.


3. check sensible page titles

Ref: http://www.xs4all.nl/~sbpoley/webmatters/checklist.html

Writing for the Web - Guidelines to double the usability of your website.

1) Difference between paper and online presentation.

• Split each document into multiple hyperlinked pages since user are not willing
  to read long pages.


• User can enter a site at any page, so make every page independent and explain
  its topic without assumptions about previous page.


• Web content should be 50% the size of its paper equivalent. Users find it
  painful to read too much text on screens. Ready about 25 % more slowly.


• Limit scrolling


• Use simple sentence structure


• Avoid cute headlines and don't rely on users to scan and pick up the meaning
  of the text


• Update website content frequently.

2) Working with a designer - Some general web graphic guidelines can
improve readability:

• Limit the use of graphics, particulary don't use full page graphics.


• include flowcharts and process diagram and unique captions identifying
  them.


• use screen captures if they can help the user understand how a product
  works.

3) Scannability

• 79% web user scan pages, and not read word-by-word. Use highlighting


• use <STRONG> tag rather than the <EM> tag for keyword highlighting.
  Since Strong is usually rendered as boldface. The <EM> tag is usually
  rendered as italics and can be used to make figure captions or emphasized
  sentences or phrases stand out.


• Colored text and color backgrounds can also be used for highlighing, but
  don't use blue for words.


• Highlight only key information-carrying words, and not entire sentences.


• Highlight is for differentiate your page from other pages


• Use Bulleted and numbered lists


• Each paragraph should contain one main idea; use a second paragraph for
  a second idea

5) Writing to be read - Consistent use of textual elements

- Heads:

• Make the topmost head on the page in H1 tag


• Organize your text so that the hierarchy is no deeper than four levels.
  


• Lower-level heads are hard to distinguish and disorienting to online readers.

- Lists:

• Limit the number of items in a single list to no more than nine.


• Limit lists to no more than two levels: primary and secondary.

- Hyperlinks:

• Don't use a hypertext link if the information can be simplely presented
  on the current page


• Use a description link, or perhaps the link address


• Use hyperlinks to provide supplemental information like definitions of
  terms and abbreviations, reference information, and background reading.

6) Writing to be Found

• List the most important terms in a keywords meta-tag


• Include generic terms used by customers or competing companies to describe
  the topic of the page


• Do not include competitors' trademarks in the meta-tag


• Use a controlled vocabulary and create a list of common terms for your
  subject area and make sure that each of these terms is added to the keywords
  meta-tag for those related pages.


• Each page must have a <TITLE> tag.


• Create title text of a single line, typically no more than 60 characters.
  Make sure that the first 40 characters of the title describe the topic of
  the page


• Do not begin a title with a generic term ("Welcome to") or an
  article ("The")


• Titles must be written in mixed case.


• Each page should have a short summary in a description meta-tag and must
  be 150 characters or less.


• Do not fill meta descriptions with promotional language

7) Terms to Avoid

• Avoid to use some words "Click here", "follow this link,"
  and "this Web site"

Ref: http://www.sun.com/980713/webwriting/index.html

Web standards checklist

It is a general checklist for developers who are interested to build a website with web standard. This checklist divides several parts – Quality of code, degree of separation between content and presentation, accessibility for users, accessibility for devices, basic usability etc. Each of them contains some questions and these are the checklist during developing a website. Moreover, each question includes some hyperlinks to give additional information.

1 Quality of code

• Use correct doctype - It informs the validator which version of HTML or XHTML are used and doctype must be appeared in top of every web page.


• Declaring character set - Declaring character set is important, as some of the browser is unable to detect the character encoding and presented with unreadable text.


• Use valid (X)HTML - Valid code will be rendered faster than code with errors.


• Use valid CSS - Error and Mistakes in CSS may affect the appearance of the document.


• Remove unnecessary classes or ids in the tag.


• Check if the site have any broken links.


• Check if the site have javascript errors such as IE can turn on the debugger.

2. Degree of separation between content and presentation

• Use CSS for all presentation aspects (fonts, colour, padding, borders etc)


• Decorative images should be saved in the CSS and do not put in the (X)HTML.

3. Accessibility for users

• Provide a text description for every non-text element and set “alt" attributes used for all descriptive images


• Use relative units rather than absolute units for text size as your readers may want to resize text at some point


• Try a test on increasing the font size and check if it breaks the layout. It is dangerous for developers to assume that everyone browses using default font sizes.


• Group related links, identify the group and use meaningful menus.


• Use accessible tables - For data tables, identify row and column headers. For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. For example use THEAD, TFOOT, and TBODY to group rows,


• Ensure that foreground and background colour combinations provide sufficient contrast


• The dropdown menus may be hard to use if responsiveness is set too fast


• All links should be descriptive.

4. Accessibility for devices

• Before starting to build a CSS-based layout, we should decide which browsers to support and to what level you intend to support them


• Is the content accessible with CSS switched off, images switched off or both switched off such as check if the site works in text browsers.


• Check if we can simply style the document for printing.


• The site should use Metadata and they are machine understandable information for the web.


• Check if the site work well in different size of browser.

5. Basic Usability

• Heading element should be easy to distinguish.


• Each page on your site has a consistent style of presentation


• The site should include a sitemap page and contact page.


• Is there a link to the home page on every page in the site


• Colour and underline the link text,


• Are visited links should be clearly defined

Ref: http://www.maxdesign.com.au/presentation/checklist.htm

The accessibility of website - Better Search Ranking

This week, I read an article that is about how to get a better search rank of website. The writer of this article - Trenton Moss point out some important points and they are the general accessibility guidelines for increasing the search rank of a website.

1. Assign ALT Descriptions to Images

Many web users who are visually impaired uses screen readers to read the website content. The screen reader does not understand image. A search engine also doesn’t understand image but some of the search engine index ALT text. Therefore, alternative description needs to be assigned to image.

2. Display Text Through HTML, Not Images and Flash

Similar as point one, search engine does not understand the text that embedded in image. We should display text through HTML.

3. Use Descriptive Link Text

Many search engines assume that link text will be descriptive of its destination, so they examine the text of all the links that point to a given page. For example 'click here' is meaningless, we should try to use some meaning values that represent the link.

4. Website Functions with JavaScript Disabled

About 7% web users do not support javascript, because they may turn it off or the browser does not support javascript. Many search engine does not index any JavaScript-driven content. Therefore, we should try not place the content in javascript.

5. Site Map Provided

Most search engines can index the entire site once they arrival the page of site map. We can provide a short keyword besides the link and this can improve the potential search ranking.

6. Meaningful Page Title

Page title can describe the page content and it is the most important attributes on the page. We must set a meaningful page title.

7. Headings and Sub-Headings Used

Most search engines assume that the text contained in heading tags is important. We should make sure our headings are correctly marked up using the tag etc.

8. Use CSS

Search engines tend to rate CSS-based sites higher in search rankings because the code of the web page is cleaner. Moreover, important content can be placed at the top of the HTML document. Search engine can access the content.

Ref: http://www.sitepoint.com/article/accessible-search-friendly-site

Web design process and workflow

There are different web design processes and workflow. They are developed from project experiences. A web design processes can be divided in many phases and it depends on the project scope. Some of the common key factors and critical phases are listed as below:

A) Requirements Gathering

• Getting to know your audience and create user profile
• Doing survey, read customer e-mails and bulletin board comments etc.
• Collect requirement from the client, marketing department and clarify to everyone involved the purpose of the requirements
• Break down the requirement and prioritize them.
• Define objectives and goals.
• Get client confirmation and sign off.

B) Design

• Brain storm solutions after getting user requirement.
• Solutions need to become visible and discuss with client.
• They may presented in the following document:
  - Architectural diagram and site map representing web pages.
  - Informal hand-drawn drawings (Sketches) to brainstorm the layout of a web page.
  - Prototype either on paper or on screen with no interactivity.
  - Briefs documents the project, audience, goals, and objectives as well as describes how the design addresses these issues.
  - Mock-up pages showing how the Web site will look, offering several options (from color schemes to layout).
  - Process diagram showing the how the flow and connection of Web pages.

C) Testing

• Establish measurable testing objectives early on in the project.
• Mapping the Plan and Reporting Results.
• There are different testing:
  - Usability testing
  - Unit testing
  - Markup testing
  - Load testing
  - User acceptance testing
  - Security testing-

D) Launch and Maintenance

• Moving the site from the testing or pre-production environment to the production servers.
• Creating a style guide and training the user on maintaining the Web site
• Switching hands could involve documentation, training and a post-mortem meeting.
• Documentation includes all approvals, requirements, project plan, reports, budget reports, style guide and anything else having to do with the project
• Doing some promotional activities, such as submit the site to search engine and sending out press releases

E) Measure Success

• Studying the Traffic Report
• Do some post implemenatation review

Ref: http://www.informit.com/guides/content.asp?g=webdesign&seqNum=24&rl=1

Hihi ! !