In this lab, you’ll start the online help system for your project and meet with your stakeholders. This will all be team-based work so there’s nothing to submit individually.
Online help systems are built into your application and, thus, are always available to your users and are potentially context-sensitive. Here is an example text that illustrates an appropriate style for the on-line help for a non-existent program called UltraProgram (taken from Lewis/Rieman):
Section 3: Mail Merge
You can use the mail merge feature of UltraProgram to send identical or similar form letters to many addressees.
Imagine that you want to send a short letter to three customers, telling them that their account is overdue, by how many days. The detailed steps in this section show you how to:
1. create a file containing the basic letter,
2. create a file containing addresses and overdue information,
3. merge the two files to create the finished letters.
Notice that it is relatively simple text. The goals that the user is likely to have are explicitly addressed right up front and then the instructions are given in a clear and concise way, and these instructions can be placed in the app context where they are most needed.
Write instructions appropriate for an on-line help system that address various key user stories for your team project.
Run your text through a readability tool and ensure that it matches the appropriate Flesch-Kincaid reading level for your app.
There is nothing to turn in for this exercise. Use it to help you build out the contextual help for your final team deliverable (see below).
MS Word has a built-in readability analysis tool that includes the Flesch-Kincaid measure, or you can use any of the many online tools for this purpose, e.g., Readability-Score.com.
Using an on-line help system has its advantages (see the previous section), but on-line text can also be harder to read than paper-only help documents. Here are some key constraints that will make on-line help texts easier to read (taken from the British Standard BS 7830 for on-line technical documentation).
Start the process of designing and adding an on-line help mechanism to your team project. This is typically done using either a pop-up, modal dialog box for each screen or separate help screens, but you can adopt any approach that makes sense for your application.
There is nothing to turn in for this exercise. Use it to help you build out the contextual help for your final team deliverable (see below).
Normally, we’d meet again with your stakeholders, but you’ve recently met with them and also run usability tests on them.
Participate in your team’s sprint planning meeting.
Confirm that we’ve been using JSDoc format to include important, non-obvious internal documentation to the system code.