Help Design Goals

Experimental design objectives for the Help app and GNOME user help.

1. Goals and Principles

• Bring content to the front. Draw the user in.
• Allow browsing content by topic area.
  • There should be a clear and simple overarching structure, so users can orientate themselves and navigate easily.
  • Keep navigation paths shallow, so people don't get lost.
  • Overview pages shouldn't overwhelm - don't link to too many pages at once.
  • Organise help according to user goals. Conform to their world-view.
  • Don't require too much back and forward navigation - avoid pages with small amounts of content. The experience should flow, rather than being bitty.
• Problem solving is best solved by the web - integrate and push in that direction wherever possible.
• Be a guidebook rather than an encyclopedia:
  • Don't document everything.
  • Focus on what's interesting and important.
  • Advertising the functionality that will improve the user experience. Advertise features that empower and enable.
• Content should be quick and easy to digest - avoid lists of more than four steps and large blocks of text.
• Signpost to enable quick scanning and navigation within pages:
  • Each page should have a brief content summary at the top.
  • Headings should be frequent. Blocks of text should be small.
  • All pages should have a prominent structure (like a guidebook).
• Promote the experience while documenting it - reinforce a positive image of the product/system.
• Pages should have some visual interest and colour.
• Audience:
  • Pay special attention to new users, in order to help them get started.
  • Help users adjust to and make the most of changes to the software (particularly as part of the upgrade process).
  • Cater to a range of confidence and experience levels. Allow users to progress in their mastery of the system.
  • However, avoid highly technical knowledge or implementation details.
• Help documentation should integrate with downstream products:
  • Don't expose the word "GNOME", or refer to the system/product in a way that will interfere the identity of downstream products.
  • Allow the integration of downstream support services and sites.

  • Allow the incorporation of downstream docs? (See bug 690058.)

2. Non-goals

• Document every possible task/operation. Don't be an encyclopedia.
• Document generic knowledge that isn't specific to GNOME.

3. Constraints

• It is difficult to keep screenshots and graphic representations of UI up to date.
• It is difficult to keep a large body of documentation up to date.