In the Proceedings of the 8th International Conference on Human−Computer Interaction, pp. 1167−1171, Lawrence Erlbaum Associates, August 22−27, 1999 Munich Park Hilton, Munich, Germany.
Legacy Interface Migration: A Task−Centered Approach Lanyan Kong (1), Eleni Stroulia (1) and Bruce Matichuk (2) (1) 615 General Services Building, Computing Science Department, University of Alberta, Edmonton, AB, T6G 2H1, Canada {lanyan,stroulia}@cs.ualberta.ca (2) (2) CEL Corporation, 9637−45 Avenue, Edmonton, AB, T6E 5Z8, Canada
[email protected]
1 Introduction Legacy systems constitute repositories of valuable corporate knowledge collected over a long time. However their unintuitive text−based interfaces make them difficult to learn and to use, and as a result the problem of migrating legacy interfaces to GUIs has emerged as one among the most interesting and challenging ones in the software industry (Moore 1996). The approach that we have been investigating in the CelLEST project to the problem of legacy interface migration involves understanding how the system is currently being used, that is how its users interact with it. In this approach, the interaction between the user and the system is recorded, while the user accomplishes her task. Then the recorded interaction trace is abstracted to a specification of the information exchanged between the system and the user. Finally, this specification gives rise to a specific task−oriented GUI design. This approach localizes the reverse−engineering process to these aspects of the legacy system relevant to a specific task, instead of having to deal with the whole body of the system code (Merlo et. al., 1995). Furthermore, it produces an understanding of the information and the logic of the organization’s current processes as they have actually evolved through the system’s lifetime. Finally, it enables the development of intuitive, user−friendly graphical interfaces
tailored to simplifying the interaction of the user with the system in service of a specific task (Wilson & Johnson 1995, Sanz & Gomez 1995).
2 The Framework Our work relies on the CelWare toolkit, developed by CEL corporation. CelWare enables (a) the modeling of the legacy system text interface in terms of its screens and the transitions among them, (b) the recording of the interaction between the user and the system, and (c) the control of the legacy system from a front−end graphical interface.
Figure 1: URGenT and CelWare: An illustration of the interdependencies among the CelWare toolkit components and URGenT. CelEngineer is a repository of meta−data, modeling the legacy system. In this model, an interface is viewed as a collection of uniquely identifiable Screens, each of which allows a set of possible Actions to transition from this screen to other screens. Each action consists of a sequence of ActionItems, i.e., primitive interactions between the user and the screen, such as function keys, and data entry. The Recorder is an enhanced terminal emulator that records the system−user interaction in terms of the CelEngineer model. Each recorded session consists of a sequence of the visited screens and the actions performed on them by the user in order to achieve a specific task. CelPilot is the runtime component of CelWare, which handles the communication between a desktop GUI application and the host legacy system. Once a system has been mapped in CelEngineer, CelPilot can be used by the front−end GUI to translate the user’s actions on the GUI to functionally equivalent actions applied to the legacy system’s original interface, and thus control the system to perform the desired task. URGenT (User interface ReGENeration Tool) interacts with the legacy system through the CelWare toolkit. It uses as input a small set of system− user interaction traces, recorded by the Recorder. The screens visited by the user in these traces are recognized in terms of the CelEngineer meta−data and annotated by their unique ID. URGenT’s task is to parse the recorded traces
into an abstract screen navigation and information exchange plan that the user carries out to accomplish her task. Then, based on this abstract task, it specifies a user interface that can properly convey all types of information that need to be exchanged between the user and the system in service of the task at hand. Finally, given a profile of the users that perform the task, it generates a front−end GUI appropriate for users’ requirements, based on standard interface design guidelines. At this point, the graphical interface generated by URGenT is integrated with CelPilot, so that the user’s interaction with the GUI is translated to an equivalent interaction with the underlying legacy interface.
3 The URGenT Process URGenT adopts an “information exchange” model for describing the user’s task. The user’s interaction with the system allows her to provide (obtain) some pieces(s) of information to (from) the system, and she accomplishes that by a sequence of elementary information−exchange actions on the system screens. There are three types of such elementary actions. Data−entry operations are tell actions: the user provides information to the system. Alternatively the user may obtain information from the system, which she indicates by highlighting the screen area where the interesting information appears. If the information in question always appears in the same area, then this is an ask−standard action; if the screen is dynamic and the information may appear in different positions in the screen, then this is an ask−select action. These three types of actions imply the need for different graphical objects in the front end GUI. URGenT classifies the different pieces of information exchanged, i.e., “asked” and “told” by the user, as System Constants, User Variables, Task Constants, and Problem Variables. System Constants are constant strings that must be entered in the host system screens every time they are visited, independent of the user’s task when visiting these screens. User Variables are data items associated with the user who performs the task, such as her login and password. Task Constants are constant strings that need to be entered on a screen when it is visited in service of a specific task. Problem Variables are data items that flow through the screens of a task session; they are either original user input or intermediate system output used as input in subsequent screens. The URGenT process for reverse−engineering the system−user information− exchange plan consists of three steps: Task Analysis, Abstract User Interface Specification and Graphical User Interface Generation. These steps will be explained in terms of a hypothetical task in an Insurance Information System. Consider a situation where the insurance company computerized its claims
department separately from their customer’s database, and therefore owns two separate subsystems, i.e., subsystem1 and subsystem2, containing their customer and claims information. Suppose further that in subsystem2, the user must enter the customer’s claim number in order to retrieve the data relevant to generating a report on the customer’s accident, but she only knows the name of the customer. So she has to first search for the claim number in the subsystem1 by entering the customer name, before she can go in subsystem2 to retrieve the report data. Task Analysis Task analysis occurs in three phases: the first examines a single trace of the task, the second phase examines multiple traces of the same task performed by the same user, and the third one examines multiple traces of the same task performed by different users. Table 2. Part of a Recorded Trace and its Analysis Screen Name
Data items
1st phase Single trace
2nd phase 3 rd phase Multiple traces Different users
Signon
“lanyan”@T “t65j”@E
Tell var2 Tell var3
Task−specific Task−specific
User variable User variable
Name search
“scott”@E
Tell var6
Problem−spec.
Problem variable
#Claim retrieval
mouse(3,12)to(3,17)
Ask var7
Task−specific
Ask standard
Menu
Tell var7 Problem−spec. Problem variable “7889”@T Tell var8 Task−specific Task Constant “a1”@E The first two columns of Table 2 describe a part of a recorded session, in terms of screens visited and data entered and obtained, for the above reporting task. The variables in quote mark are data items appearing on a screen or entered by the user, while the variables beginning with “@” are special keystrokes, e.g., “@9” is function key F9. “MouseTrack (x1,y1)to(x2,y2)” means that the user highlights an area with starting and ending coordinates (x1,y1) and (x2,y2) correspondingly. The last three columns on the right of the table show the results of the three phases of the task analysis process. At the end of this phase, URGenT has identified two user−specific variables (the user’s login and password), a task constant (“a1” is the string entered in “Menu” to get the desired information about the claim), and two problem variables (the customer’s name and the number of his claim). It has also identified that the claim number can be obtained form a standard position in the “#Claim retrieval” screen.
Abstract User Interface Specification After the analysis of a task, URGenT specifies an abstract GUI, which requires the user to input her data items (user variables and user input problem variables) only once, and buffers them appropriately to deliver them to all screens that use them. This GUI also retrieves from the legacy interface the asked data items” and feeds them to the appropriate screens. So in the above example, the user will enter her personal data and the customer name only. This interaction process is drastically simpler than the original one, where the user enters her personal data twice (to the two subsystems), writes down the claim number on paper and then enters this same number in three different screens to get different elements of the final report. At this point, for all data items to be manipulated, depending on their type, URGenT identifies a class of graphical interaction objects appropriate for the data−entry action at hand (Lewis & Rieman 1993). For example, for a tell action manipulating a date, appropriate graphical objects might be a calendar, a combination of three scrolling lists for year, month and day selection, a simple text entry box, etc. Graphical User Interface Generation The final step in the URGenT process is the actual generation of a GUI for implementing the user’s task. Having identified a class of graphical objects appropriate for each data item, URGenT proceeds to develop a dynamic HTML GUI with graphical objects appropriate for the users for which this GUI is intended. At this point, since we are dealing with report tasks, which are fairly small, this problem is simple in that only a single screen is needed with a few objects placed in a simple sequence according to the order of their use in the process. More complex tasks will require more elaborate approaches to the object layout problem.
4 Summary and Discussion In this paper, we discussed a process for the migration of a legacy system’s interface to a GUI. This process is based on the understanding of the user’s information−processing task, as extracted from traces of the user’s interaction with the system, and results in the design of task− and user− specific GUIs. We are currently working to extend this method from deterministic tasks, for which all traces of the same task consist of the same sequences of screens and actions, to more complex, non−deterministic tasks. Acknowledgements: This work has benefited from a lot of lively and in− depth discussions with the rest of the CelLest group, Paul Sorenson, Mohammad ElRamly and Roland Penner. It was supported by NSERC CRD 215451−98.
5 References 1. Lewis C. & Rieman, J. (1993) Task−Centered User Interface Design, http://www.acm.org/~perlman/uidesign.html. 2. Merlo E., Gagné P.Y., Girard J.F., Kontogiannis K., Hendren L.J., Panangaden P. & De Mori R. (1995) Reverse engineering and reengineering of user interfaces, IEEE Software, 12(1), 64−73. 3. Moore M. (1996) Representation Issues for Reengineering Interactive Systems, ACM Computing Surveys, 28(4), 199−es. 4. Sanz, M. & Gomez E.J. (1995) Task Model for Graphical User Interface Development, Grupo de Bioingenieriay Telemedicina, Universidad Politecnica de Madrid, Technical Report gbt−hf−95−1. 5. Vanniamparampil A., Shneiderman B., Plaisant C. & Rose A. (1995) User interface reengineering: A diagnostic approach, University of Maryland, Department of Computer Science, Technical Report CS−TR−767. 6. Wilson S., & Johnson P. (1995) Empowering Users in a Task−Based Approach to Design, Proceedings of DIS’95, Symposium on Designing Interactive Systems, Ann Arbor, Michigan, August 23−25, pp.25−31, ACM Press.
