Desired Design Features, continued
Users with Disabilities
We also tried to design our web-based program to accommodate users with different physical and intellectual abilities. The software user experience is ultimately a subjective one. However, students with differing physical abilities were often at a significant disadvantage because making materials accessible — even software — could be cost prohibitive. “Retrofitting” software can be difficult, especially when working with poorly commented or documented code.
For this reason, we tried to design software that could meet the needs of different users. For example, each overview is equipped with sound files that reproduce the text. There is a “play” button students can click to hear the paragraphs in the section read aloud. And because it is delivered within a web browser, the user can adjust the size of the text font to suit. We also wanted a color background, not a black-text-on-white-background. Students with visual processing difficulties may find it easier to read with colored lenses, filters, or on a lightly colored background, although there is currently little scientific evidence of the effectiveness of this approach for dyslexia (while background color may make dyslexia more difficult to cope with it is not the cause of dyslexia, which is a language-based disorder). Another element that should make it easier for students with screen reading software is that there is alternative text for all images — titles of all pictures are also available on mouseover, as well as when you mouseover on the “Credit” link.
Microsoft PowerPoint® was used to “storyboard” and then animate how we wanted the product to look and act. In the example below, a case study widget is open in the title Civics: An Interactive Approach. The mockup instructions also included a description of the page’s behavior.
For example, the image in the top left corner and the page title both indicate the chapter that is currently in use, while “Civics: Chapters” indicates the program and filter in use. When the widget is open, students should still be able to navigate to other resources within the chapter from the left side of the screen, indicated by the resource type icon. There should be a status button, shown as an oval at the bottom left of the question widget. It should have three states: clear (before anything has been typed), mixed (typing has begun), and full (student has clicked it). There should be a mouseover on the status button, saying “click here if you are finished with this case study” (or whatever activity it is). The panes in the widgets should be moveable to maximize space for reading or writing (whichever task is at hand). The resources on the left hand side should all be related to the chapter. If there isn’t a particular type of resource available in the chapter, the resource’s icon should be grayed out. The widgets should open “soft” tabs within the “hard” tab of the browser. Selecting from an icon on the left (via pull-down menu) should open a soft tab. All other filters and parts of the program are accessible at the bottom of the page. For example, clicking on “Search” should create a soft popup.
From there, we wrote the technical specifications that the programmers needed. This covered the platform it would be delivered on; the main navigational structures, panes, and widgets; as well as the internal filing system for the content.