Reengineering of a user interface for a drafting plotter - HP's DraftMaster Plus drafting plotter - Technical

An existing user interface has been successfully reengineered and plotter usability enhanced by selecting, combining, and adapting software prototype techniques and standard software development methodologies.

HP's large-format pen plotter family has been evolving for the last ten years, mainly by introducing new models that enhanced the functionality and performance of previous products. While adding more features and providing better performance, new models have usually required more complex and less intuitive user interaction. To facilitate the use of the new functionality of the HP DraftMaster Plus plotter, it was decided to redesign the plotter's user interface.

The reengineering of the user interface was successfully accomplished by applying and adapting a combination of software development methodologies and prototype techniques. The key steps in the evaluation, design, and development of the new user interface were:

* Development of a user interface software prototype for early evaluation and usability enhancement

* Detailed specification, both graphical and textual, of the user interface menu options, dialogues, and messages

* Design of the user interface for easy localization (translation) of all displayed text

* Use of best practices for design and development: structured analysis, structured design, system testing, design walkthroughs, and code inspections.

User Requirements

Improvement of the HP DraftMaster user interface was identified as a priority as a result of focus groups and customer surveys. The major customer complaint was the readability of the LCD display, especially from different angles. The readability was worst under light conditions that created reflections and shadows. Another area for improvement was the basic user interaction required for menu navigation, function selection, and option set,up. Another major limitation was the number of characters allocated to describe each menu option, especially for some languages, such as German and Spanish.

The readability problem was easily addressed by replacing the LCD display with a light-emitting display technology to provide good readability even in poor light conditions. Among the several different display technologies considered, the best combination of cost and features was offered by a vacuum fluorescent display (VFD). To eliminate reflections, the display is covered by dark plastic. The display window has been enlarged to facilitate readability from different angles and greater distances.

To enhance the usability of the front panel, a broader understanding of how users interact with a peripheral was required. Aspects of front-panel design that had to be considered included the layout, type of keys, number of keys, labeling of keys, localization, and aesthetics. Usability aspects included menu selection, option setup, operation feedback, and others.

Our approach to investigating and defining the most appropriate user interface was to use a software prototype tool to build and test different types of front panels.

Rapid Prototyping

The study began with the definition of numerous and highly diverse types of user interfaces. Key people from various disciplines were involved in the definition process: R&D, marketing, quality, product support, and industrial design.

Software prototypes of the different front-panel layouts were generated easily and rapidly using an HP software tool called LogicArchitect. The prototypes allowed people to try different options in a very efficient manner. Very soon the range of options under consideration was narrowed to a small number.

The use of software front-panel prototypes proved to be a very useful and powerful tool with multiple advantages. First, it was useful as a communication tool to describe a particular front-panel alternative. Software prototypes were easily and rapidly sent back and forth between the U.S.A. and Spain through a computer link. Second, as a testing tool, software prototyping allowed the quality department to evaluate concepts early in the investigation phase. This made it possible to design the user interface test suite sooner. The prototype also served as a reference for checking the correctness of the user interface implementation. Third, consensus about which user interface to choose was achieved much sooner with software prototyping, since the advantages and disadvantages of each option were easy to demonstrate. Fourth, the prototype allowed the manual writer to start writing much earlier and helped make the manual more accurate because the writer was able to interact with the prototype. Fifth, the prototype speeded development because the software engineers were able to reuse some of the data structures and texts from the software prototype. Finally, the main advantage was that it was easy to demonstrate the usability of the chosen front-panel option before development.

Fig. 1 shows the old HP DraftMaster front panel, two of the software prototype options tested, and the final front panel.

Risk Assessment

The initial plan was to develop the new user interface in the following pen plotter project. The early consensus on the type of user interface to develop encouraged us to consider advancing its development.

Before committing to the development of the new user interface an estimation of the risk of adding new functionality late in the project was required. This risk assessment was based on estimates of the precision of the current project schedule and the defect removal effort for the project. The conclusion was that the project could be done on schedule, but there would be little margin for error. Therefore, the user interface development had to be done in one cycle with very lit. tie time for rework.

The methods used to evaluate the precision of the schedule and the defect removal effort were the keys to a good risk assessment and are explained in more detail in the following sections.

Precision of the Project Schedule. The precision of the project schedule is a measure that can be derived from the project delay over time: the greater the project delay the less accurate the project schedule.

Planned project progress can be measured as the number of planned test cases. A test case is a set of tests done to validate a certain unit of functionality. Actual project progress can be defined as the number of test cases completed up to a given time. The assumption is that a test case is performed as soon as the associated functionality is available for testing. By observing the planned test cases and the actually completed test cases over time one can quantify the project delay and the precision of the project schedule. If a test case finds the functionality under test to be invalid, that test case is considered open until the defects are fixed. Open test cases are not counted as completed. This is because extra time is required to fiX the defects, resulting in an extra delay in the project schedule.

The number of planned test cases, the number of test cases actually performed, and the number of completed test cases (actual minus open) can be plotted as functions of time as shown in Fig. 2. Project delay can then be estimated as the difference in time between the date a certain percentage of the test cases are actually completed and the planned completion date. The projection of this difference over time for the DraftMaster Plus project resulted in an estimated delay of 6 weeks.

Rework Effort Estimation. The defect removal effort at the point when we were about to undertake the development of the new user interface was estimated as:

Rework effort = (Number of defects) x (Average time to fix a defect).

The average time to fix a defect varies from person to person. It is also related to the laboratory's software development environment. An estimate can be based on the laboratory's defect history by computing the average time it has taken to fix a defect in the past. However, the defect tracking records in the short history of our lab were not sufficient to give an accurate average, so we took the approach of doing our best team estimation. This resulted in an estimate of 2.5 hours per defect, not including test time.

Several statistical techniques are available for forecasting the number of defects. The one that worked best for this project is based on the defect density per test case in each of the system regression tests. The same metric has been used as a project progress measure and as a software stabilization measure. The key benefit of this technique is that it gives a good estimate of the number of defects early in the project.

At the time we assessed the number of defects there were parts of the code that were undergoing the third regression, while others were still in the first. We found that the number of defects per test case and per regression was very close to a straight line, except for the first regression, where the straight-line pattern appeared after 20% of the test cases were executed (Fig. 3). Therefore, we established three conditions for estimating the number of defects:

* At least 20% of the first regression is executed.

* At least 10% of the second regression is executed.

* At least 5 regressions are estimated to be required, based on past project experience.

To evaluate the total number of defects we extrapolated the defects to be found in the first regression at 100% completion, and the same for the second. The the ratio of the numbers of defects in the first and second regressions was calculated. Values for the third, fourth, and fifth regressions could then be determined. The result was that at 20% execution of the first regression, we estimated 96 defects. The actual value at the end of the project was 110 defects for the entire project.

On the basis of the estimated 96 defects and 2.5 hours to fix each defect, the required rework effort was estimated to be 1.5 engineer-months.

Using these techniques we were able also to forecast the number of defects that would be found in the next month. To do this we used our regression test plan and the straight-line relationship between test cases, regressions, and the number of defects. The results are shown in Fig. 4.

Graphical and Textual Specification As a software good practice, we decided to do as much formal specification as possible of all new software functionality before the design and code development phases. The challenge was to describe the general operation of the user interface formally. To achieve this objective a special graphical syntax, combined with text, was designed as an easy and intuitive way to describe a generic menu-driven user interface. The main objective was to have a working document, the DraftMaster Plus User Interface Internal Reference Specification (IRS), which would be easy to review and update for all the different functional areas involved in the user interface development: marketing, quality, R&D, product support, industrial design, and manual writing. The user interface IRS document had to describe the static aspects of the user interface (menu hierarchy, list of options, buttons, etc.) as well as the dynamic and interactive aspects (dialogues, event sequences, option setups).

The user interface physical display is one of the basic objects used to describe the user interface. It is represented graphically as a rectangle with shadowed edges. A front-panel button is represented by drawing an outline of its real shape with an icon on top of it for identification. Another element used in the user interface description is the screen, defined as the text being displayed at a particular instant in the user interface display. A screen is described graphically by a rectangular display symbol with the particular text in it. Particular menu options, messages, and option setup screens are graphically represented as screen elements.

The description of a series of user interactions is captured as a dialogue. A dialogue is a sequence of events mainly driven by the user--for example, the setup of an option such as baud rate or the number of copies. To set up a particular menu option, the user goes through a sequence of screens, making selections, setting values, and pressing buttons. Dialogues are described graphically as screens connected by arrows that define a time sequence. In a dialogue, the transition from one screen to another can be triggered by the user's pressing a particular key. This is captured graphically as two screens connected by arrows, with the button graph in between. An example of such a description from the user interface IRS is shown in Fig. 5.

There is a limit on the amount of detail this graphic representation can describe effectively. Details and complementary information are better described as text.

This notation allowed an excellent review of the user interface requirements before the design phase, and facilitated a broad consensus among the different functional areas. The detailed specifications in the user interface IRS also proved to be very useful for system test development. All of the menus and options were grouped into 25 equivalence classes according to the number and kind of buttons to be pressed to reach them, and one menu or option of each class was chosen and fully tested. Status and error messages were tested in the same way, grouping them in classes according to priority, and testing all possible combinations of messages belonging to different classes.

Misunderstanding or incompleteness of an IRS results in software defects. As a result, code and tests have to be reworked. In this project, the detailed specifications minimized this effect and saved a significant amount of time.

Analysis and Design Methodology Working on a tight schedule, there is little time to redesign previous designs. Things have to be done right the first time to minimize the time to market. With this in mind, we decided to use structured analysis and design practices. The structured analysis, based on data flow diagrams, [1] allowed a team of software engineers to work efficiently. The goal was to minimize the interaction among the engineers while limiting the the analysis to a reasonable level of detail.

To get a high-level picture of the user interface we drew a context diagram and a data flow diagram. The context diagram (Fig. 6) shows the interaction of the user interface with the plotter system through events and with the outside world through sensors and buttons, the display, and an alarm beeper.

The plotter system is the plotter itself and includes many submodules that can interact with the user interface: I/O, plot management, graphics engine, media handler, vector manager, pen handler, and so on. These modules interact with the user interface manager to notify or warn the user through messages or alarms, show the status of the plotter, show current menu values, set new parameters, and execute user interface commands.

The data flow diagram of the user interface manager (Fig. 7) shows the main procedures in this module: user interface event manager, message handler, menu handler, and display manager. The user interface event manager takes care of all kinds of events, including plotter system, keyboard, and timing.

The menu handler navigates along the menu tree and executes the menus at the tree leaves. It receives the menu events, including keyboard events (a button pressed by the user), data supplied from the plotter, timer events (like an inactivity timeout), and special menus triggered by the plotter from the graphics engine. The menu tree is stored in the menus data structure. The root is the status menu, which shows plotter status, such as ready, busy, paused, paper out, and so on. From the status menu, six main menus are available, four of them directly available from buttons. These have several submenus. At the tree leaves are the menu dialogues-customized menus that can show, toggle, and set parameters or simply trigger with or without confirmation of user interface commands. The user interface allows the nesting over the menu tree of special menus triggered from the graphics engine, such as the digitize menu, and several direct menus for easy access to the cancel, select pen, pause, and other often-used menus. Fig. 1 shows the user interface key layout.

The message handler displays and removes messages. The messages come from the user interface event manager (from the plotter) or are internally generated by the menu handler (to notify or warn the user). The messages data structure holds all the messages, classified by class and priority. Messages of different classes and priorities can be nested. Each class has an associated menu behavior. Informative repetitive messages are displayed until any key is pressed, and are redisplayed after an inactivity timeout. Error messages from the graphics, I/O, and other submodules are displayed until any key is pressed. Informative timeout messages are shown for a few seconds to inform or warn the user. User action request messages require the user to press the Enter button to confirm. Progress status messages are shown while a critical action is being performed. Critical error messages indicate failures.

The display manager controls the vacuum fluorescent display. It manages the display queue and displays the menu choices. It also sets some of the display options, such as flashing, character set, and brightness.

Data Structures

The next step in the user interface design was the design of the data structures, which are mainly composed of menus, messages, and words. Static data structures were specially designed for easy localization to support the six targeted languages: English, French, German, Spanish, Italian, and Japanese. From experience, we clearly understood the need for an automated procedure to allow further refinement and correction of 311 the texts and their translations.

In each case, the English version was built first. Some parameters were specified, such as name, type (menu, message, word), menu linkage (for menus), and message class and priority (for messages). There was a field for the English text and another for adding the translation to a single language. This file was sent to the five translators, who had to fill in the translations field.

We created a tool called the data structure builder for automatically building all the data structures from the six files. The tool produces a C include file with all the menu and message structures. When changes had to be made, we just edited the six source files and reran the data structure builder again.

The last step in the design phase was a walkthrough to detect design defects. This walkthrough proved to be very useful. It showed some inconsistencies, but primarily it highlighted a major implementation issue: how to implement the menu dialogues. This issue is covered in the next section.

Implementation

When it came to implementation, there were some inherited constraints that made the reengineering of the user interface more difficult. Most of the code had been written more than ten years earlier when low-level languages were more the rule than the exception. The software system architecture was interrupt-driven and had no operating system for task scheduling and dispatching. The new user interface was constrained to exist in this environment. The plotter system runs as a background process and the user interface is triggered at an interrupt level by a periodic interrupt event. The user interface manager and the plotter system communicate through queues as shown in Fig. 10.

The plotter system was too hard to model, so we decided instead to have a clear, well-specified interface to the user interface queues and then surgically remove the old user interface references and add the new ones.

The user interface manager is scheduled through a periodic interrupt. It is basically a state machine with states, input events, and outputs. When activated, it checks for an event (button press, timing, or plotter) and handles the menus or messages depending on its state and the event.

Another limitation, because of the lack of an operating system, is that the dialogues (menu leaves) were designed as independent tasks. They are called upon entering a dialogue menu and they end when the user operation is completed. They are implemented in the user interface manager at the interrupt level. Therefore, we had to design a small operating system subset just to put the menu dialogues to sleep when waiting for events and wake them up at the next interrupt. We supplied a local stack so the user interface manager would be better isolated from the rest of the system and could more freely build its own display screens.

The last important issue was how to support the design team of three engineers so that they could work efficiently on the same set of modules and within the schedule constraints. We succeeded thanks to a well-established software management control system for supporting parallel development. This system is based on RCS and includes some scripts to better automate the generation of code releases. It also supported our intensive use of code merges. The data structure builder already mentioned made it easy to update the menus and messages.

Results

The HP DraftMaster Plus user interface reengineering project met its planned introduction date and its main project objectives. The number of software

defects was very low compared to previous projects in this lab.

The project took 6.5 months. One month was spent in selection of the best proposal. Three months were invested in the definition of the IRS and the system tests--a measure of the amount of specification effort. The final 2.5 months were spent on coding and testing.

The project complexity, measured by the amount of new C code written, was 15 KNCSS (thousands of noncomment source statements).

The number of defects related to the front panel found before introduction was 37. To determine the quality of the specification and coding activity, the defects were classified as specification defects (13%), coding and design defects (84%), or hardware defects (3%). The specification category includes such defects as misunderstandings between team members, side effects of specifications, incomplete specifications, and wrong specifications. The low percentage of these defects is a clear improvement over previous projects, indicating that the specifications were clear enough that every team member was able to understand the expected product behavior.

Defects found in new and old modified code were:

* New code: 38%

* Old code: 62%.

The quantity of code written in the old assembly language was much smaller than the quantity of new code, proving again that the modification of old patched code is much harder than writing brand new code. The prerelease defect density in the new C code was 2.5 defects/KNCSS. This is a significant improvement over previous experience in our lab. At introduction, there were no open defects in the user interface.

Acknowledgments

We would like to recognize the contributions of Juan Jose Gimenez in implementing and supporting rapid software prototypes of the different user interface concepts, Ken Larsen who contributed multiple comments and ideas on the design specification documentation, Herb Sam off and Josep Giralt for their significant role in turning the user interface project into a successful reality, and Carles Muntada for his contribution on the user interface project and the help he provided on the revision of this article. In addition, we appreciate the efforts of the engineers at the HP San Diego Technical Graphics Division who helped in the project. Special thanks to the whole project team that made the DraftMaster Plus a real product in the market.

References

1. T. DeMarco, Structured Analysis and System Specification, Yourdon Press, 1978.

Bibliography

1. D. Hatley and I. Pirbhai, Strategies for Real-Time System Specification, Dorset House Publishing, 1987.

2. M. Page-Jones, The Practical Guide to Structured Systems Design, Yourdon Press, 1980.

3. T. DeMarco, Controlling Software Projects, Yourdon Press, 1982.

4. M. Ould, Strategies for Software Engineering: The Management of Risk and Quality, John Wiley & Sons (UK), 1990.

5. D. Youll, Making Software Development Visible, John Wiley Series, 1990.

COPYRIGHT 1992 Hewlett Packard Company
COPYRIGHT 2004 Gale Group