Our quality assurance goals are:
(1) To ensure the behaviour of Star is in agreement with our specification for interface interpreters;
(2) To ascertain thatStarworks as expected on apps.
In order to achieve the first goal, we reviewed the Star GUI Specification document and the Star Behaviour Specification document in conjunction with the Interface Interpreter Specification document for the purpose of detecting and correcting inconsistencies, ambiguities, and missing requirements. We took note of each statement in the two Starspecification documents that negates some requirement in the Interface Interpreter Specification document. In addition, we recorded each behavioural requirement ofStarthat is not captured in the Interface Interpreter Specification document, and vice-versa.
The review process described in the previous paragraph was conducted prior to the development of Star. The outcome of this review process revealed some issues, as documented in Table 4.1.
4.4. QualityAssurance onStar 65
Document with Issue Section with Issue Description of Issue
Interface Interpreter Specification Core Steps (Initialization Phase) There is no information concerning refreshing or initializing tables in this document. However, this information is available in the Star Behaviour Specification document.
Star GUI Specification 1 Wrong method found in point 6:
displayText. As stated in the
Interface Interpreter
Specification document, the correct method isshowText. Star GUI Specification 2 Clarification required in point
15(b): the definition of an incomplete stage is confusing or ambiguous.
Star GUI Specification 4 Incorrect parameter type found in point 1:stringused instead oftext.
Table 4.1: Outcome of reviewing Star Specification documents in conjunction with the Interface Interpreter Specification document
We fixed the first issue by including the missing information about the need for interface interpreters to initialize tables via GemSetting. We further corrected the wrong method and parameter type in the second and fourth issues respectively. For the third issue, we included additional sentences explaining (in clear terms) what constitutes an incomplete stage of a command. These additional and non-technical sentences help resolve the ambiguity that may have resulted in a faulty implementation if not addressed.
Finally, to achieve the second quality assurance goal, we performed a live test on three apps, two of which were presented in Section 4.3 above. The third is the Meal Planner app. With this app, a user can specify the food items to eat for breakfast, lunch, and dinner, as well as the date, start time, and duration of each meal. The user can save the meal information for future retrieval if necessary.
Other Interface Interpreters
In this chapter, we discuss four previous interface interpreters that were built on top of the 2009 version of Johar, as well as two interface interpreters (besides Star) which ride on the new version of Johar.
5.1
Previous Interface Interpreters
Prior to our quality assurance on Johar that led to its redesign, four interface interpreters -
Speak, Press, Senatus, and Show - were already in existence. The “Speak” interface interpreter was developed for blind users who rely on keyboard and sound as means of interacting with apps. Speak accepts input from users via the keyboard, and displays and speaks the output to users. The “Press” interface interpreter was developed for users with severe motor impairments. It elicits data by cyclically displaying and highlighting choices with a user-controllable timer delay between the choices, and allowing the user to make a selection by pressing a specific key when the intended choice has been highlighted. The “Senatus” interface interpreter presents a Unix-like command-line interface to the user. Users interact with apps through the command-line interface by entering commands that match their intended tasks. Finally, the “Show” interface interpreter presents a graphical user interface (GUI) through which users interact with apps.
However, despite the potential benefits derivable from these four interface interpreters, they are not without shortcomings. For instance,Speakdoes not work well with tables,Senatushas issue with parsing dates and times,Showdoes not display tables at launch time and also does not support multi-stage commands, and none of the four interface interpreters work well with questions. Moreover, their smooth operation was hindered by faults in the old version of Johar on which they were built.
Fortunately, our quality assurance on Johar, discussed in Chapter 3, has led to a new and
5.2. TheStarXInterfaceInterpreter 67
more reliable version of Johar which in turn facilitates the smooth operation of interface interpreters, as well as ensuring effective collaboration between interface interpreters and apps. We have already designed and implemented a classic WIMP GUI interface interpreter (called Star, presented in Chapter 4 of this thesis) which is based on this new version of Johar. We also designed two other interface interpreters - Grupo and StarX - which are discussed in the subsequent sections. The implementation of these two interface interpreters will be accomplished in the near future.
We believe that the implementation of StarX and Grupo, together with the quality assurance activities of this thesis, will make the more complex process of designing important interface interpreters for blind, low-vision and motor-impaired users easier.