Using activity descriptions to generate user interfaces for ERP software

Size: px

Start display at page:

Download "Using activity descriptions to generate user interfaces for ERP software"

Theresa Curtis
5 years ago
Views:

1 Using activity descriptions to generate user interfaces for ERP software Timothy O Hear and Yassin Boudjenane Revelate SA, 38 ch. de Pré-Gentil, 1242 Satigny, Switzerland tohear@revelate.com, yboudje@revelate.com Abstract. Delivering tailor-made ERP software requires automation of screen and printed report creation to be cost effective. Screens generated directly from data structures tend to have poor usability. An approach is considered using a domain specific language to describe use cases. Paper-prototyping and usability testing results define the usability characteristics the DSL portrays. The DSL is capable of defining a variety of screen types and user interface elements including forms, lists, pivot tables, Gantt charts, calendars and graphs. This approach is currently used in production to generate an interactive AJAX web user interface as well as HTML, PDF and Excel reports from descriptions stored in XML files. We believe that further research could extend our results to include non-erp type software. Keywords: AJAX, domain specific language, DSL, ERP software, HTML, interaction design, paper-prototyping, usability, user interface. 1 Introduction Our company, Revelate, delivers tailor-made business management solutions (often called Enterprise Resource Planning, or ERP, solutions) to customers of all sizes involved in a wide range of industries. Each project requires a large number of custom designed screens and printed reports. This paper documents our quest for semiautomatic generation of the latter. 1.1 Dropping manual layout Our software previously used a windows client. Custom screens were laid out in Microsoft Visual Studio and custom reports were designed using Crystal Reports. Though both of these tools are extremely versatile, production of screens and reports was rather time consuming. The manual positioning of user interface elements was fiddly, and adding a field in the middle of a report would generally require shuffling other fields around to make room. Furthermore each developer had his own idea of a

2 2 Yassin Boudjenane good layout. Enforcing visual consistency and appropriate use of interaction patterns required a fair amount of oversight. 1.2 Removing dependence on specific rendering technology A few years into the life of our company we had to deal with a rather traumatic event. The very first version of our application was developed with Visual Basic 6, a choice driven by a desire for maximum integration with the Windows platform. Well aware of VB6 s limitations we were betting on Microsoft s promise of a much improved version in a couple of years. When.Net was finally released the upgrade process took a sledgehammer to every one of our screens and required months of work to fix. We realized then just how risky it is to store customer specifications inside a closed format, mixed up with platform specific code. 1.3 Improving usability Though our windows client was generally liked by our clients, we felt that considerable improvements in both initial learning and everyday use were possible. We were particularly inspired by the work of Adam Cooper [1], Jakob Nielsen [2] and Don Norman [3]. Whatever new ideas we had would need to be prototyped and thoroughly user tested before making it into production. 1.4 Choosing a starting point When in 2006 we started to design the next version of Revelate it was clear that big changes were required for screen and report production. As a consequence of the above our brief included: Screen and report layout must be fully automatic. Screens and reports must be described independently from a specific rendering technology (e.g. Java s Swing,.Net s XAML, HTML or Flash). Usability of the windows client must be improved upon. Screen and report descriptions must be device independent; they can be rendered on anything from a mobile phone to a workstation. We simply couldn t find much existing work even less an existent screen or report description language that matched these criteria. On the other hand Model Driven Architecture approaches appeared too abstract and generally focused on business logic rather then screens and reports. See [4], [5], [6], [7] for examples of these approaches. There are a number of user interfaces generators such [8] available that rely purely on a description of the underlying data structures. Typically, they use raw database tables or the business object domain. Our analysis of such generators is that, while the screens they generate are suitable for system administration tasks, they rarely meet reasonable usability requirements, and as such are uncompetitive with manually crafted user interfaces. This is due to the underlying data model rarely matching the

3 Using activity descriptions to generate user interfaces for ERP software 3 user s mental model of an application. Other generator approaches such [9],[10],[11] didn t quite match our needs. Our existent approach required us to describe each of our clients use cases as part of the specification document. Hence we decided to consider the use case (or activity) as a container of screens and/or reports. We could then define the use cases with a domain specific language containing sufficient information to generate the actual screens and reports. This approach is examined below. 2 Hypothesis Design decisions resulting in a well crafted user interface can be systematically reproduced by an automatic generator. This is achieved by identifying individual tasks or activities and defining their key characteristics. These characteristics will not be related to a specific graphical user interface toolset, nor indeed a specific screen size or input method. Furthermore, similar characteristics can be defined for printed reports. 3 Methods We first manually generated a user interface according to a set of rules and user tested this with a paper prototype. This was not particularly successful so we switched to the design of a complete application module without initially concerning ourselves with how it would be generated. We built an interactive prototype to test our design assumptions and achieved excellent results. Reverse engineering the tested design provided the foundation for the first DSL. Finally analysis of existing applications provided further ideas to enhance our DSL. 3.1 Paper-prototyping the first approach Our first approach was based on the idea that a use case or activity could be split into a multitude of small steps. Each step would have its own screen and a navigation system would be generated to link each step together. Such interfaces, we felt, could easily be generated. We created a paper prototype of the concept and organized user testing as described in [12] for a simple task: entering the information contained in a business card. We decided to model the business card as 2 contacts (the employer and the employee) with addresses and phone numbers that could belong to one or the other. We were aware that it would not necessarily match the users mental model of a business card, but felt that it was representative of typical complexity in an ERP package. Testing revealed that we underestimated the impact of the mental model, furthermore the considerable amount of navigation required to accomplish this task

4 4 Yassin Boudjenane rapidly led to loss of context. It became clear that preserving context had to be built into our user interface model. 3.2 Ex-nihilo design of a module and constructing an interactive prototype As the results of the paper prototype were not encouraging our interaction director, who had not been all that happy with the let s test screens we know how to generate approach, insisted on doing the opposite: a thorough ex-nihilo design of a complete project management module using the process described in About Face [1]. This design was built up using personas (Cooper s version of use cases and roles), storyboarding, paper prototyping (Fig. 1) and finally an interactive prototype. Fig. 1. A storyboard describing the planning module with complete lack of regard for the length of our developers work week. User testing was extremely successful thanks to the new design s use of context preserving mechanisms such as in-situ editing, progressive disclosure (Fig. 2) and pop-up windows. By in-situ we mean that anywhere you can read information you can edit, delete or add to it. By progressive disclosure we mean that for a given screen element additional screen elements may be displayed either automatically when the user focuses on the screen element or at the user s discretion. By pop-up window we mean both transient non-modal elements such as tooltips, contextual menus or warning messages as well as modal dialogs. Another strength of the new design was its use of advanced user interface elements such as calendars and pivot tables to manipulate data. We opted to reverse engineer the simpler screens first and look after the advanced elements later. This led to two separate DSLs. Note that paper prototyping of such a highly interactive design didn t work particularly well, hence the need to build an interactive prototype.

5 Using activity descriptions to generate user interfaces for ERP software 5 Fig. 2. Progressive disclosure used in a list. A panel containing a large comment field is displayed inside the currently selected line. Note also that fields appear editable only when selected. 3.3 Iterative evolution of the domain specific language in real world situations To kick start the process, we designed the first DSL by listing the information required to render a simple set of screens and finding out ways to deduce anything that would have dependent on the rendering technology or the screen size. As we added more complex screens and client requirements the DSL evolved. The second DSL built on the lessons learned from the first one and had a much longer design gestation. It is capable of representing all screen elements of the first DSL as well as trees, tree grids, pivot tables, Gantt charts and calendars. Both of the DSL have now been used in multiple projects and have evolved accordingly. 3.4 Analysis of existent applications To further increase the potential of our DSLs a variety of existing applications renowned for their user interfaces were analyzed, their user interaction design patterns and layout rules identified and their design decisions deduced. Often similar activities were represented using completely different approaches. Discovering the forces causing these differences provided a number of the key characteristics that we re currently integrating into the DSLs. We are also analyzing the numerous catalogues of user interaction patterns such as [13] in view of integrating this approach into the DSL. 4 Results Both domain specific languages are considered with the organization or layout of controls (sometimes called widgets) in screen space and the projection of data onto these controls. The first DSL focuses mainly on static screen layout, whereas the second DSL is able generate sophisticated data driven layouts.

6 Yassin Boudjenane 4.1 The first DSL or Activity Structure The Activity Structure is based on a fairly static hierarchy of controls which are outlined in Fig. 3 and described in Fig. 4. An Activity contains one or more sections; each section contains one or more regions and each region contains one or more fields.

6 6 Yassin Boudjenane 4.1 The first DSL or Activity Structure The Activity Structure is based on a fairly static hierarchy of controls which are outlined in Fig. 3 and described in Fig. 4. An Activity contains one or more sections; each section contains one or more regions and each region contains one or more fields. Fig. 3. Our current application displaying a typical activity-section-region-field layout. Most of the action occurs at the Region and Field levels. Regions can be lists, forms or dashboards. Fields can be buttons, query fields or inputs (with a large variety of input types). Sections can be pages, drop-downs, sliding panels, tooltips and dialogs. The variety of section types enables us to create the level of interactivity that our tests demonstrated was required. Each of the controls has a number of characteristics (e.g. its importance or whether it is editable or read-only). None of these characteristics define information that is specific to screen size or rendering technology. The Activity Structure also describes object sets that are bound to regions and defines the portion of the object domain used in the activity. They are filled with objects either by default queries defined in the DSL or via user interaction. Object sets can sort and filter data. They can also be linked together to define parent-child relations between on screen objects such as invoice line items. The major limitation of the Activity Structure is that additional regions or input types need to be developed explicitly; the language is not capable of describing them directly. Also the object sets used are one-dimensional so they can not directly describe hierarchies or pivot tables.

7 Using activity descriptions to generate user interfaces for ERP software 7 Fig. 4. UML class diagram of the Activity Structure. 4.2 Motivation for the second DSL The second DSL s brief required the ability to describe trees, tree grids, pivot tables, Gantt charts, calendars and charts. In terms of our first DSL, the Activity Structure, it is a language for describing Regions or Fields. The underlying concept is that we are projecting an n-dimensional object space onto the x-y axis of screen space. Take for example work items produced by a given employee on a specific date, where the employee belongs to a department. There s a number of different ways we could project this information on to the screen, for instance: - A list of all the work items with 4 columns: employee, department, date, units. - A form displaying a single work item at a time with a set of arrows to move back and forward in the list. Four fields display employee, department, date, units. - A pivot table with months along the x axis and employees along the y axis, with the total units displayed in each cell - A tree with department nodes containing employee nodes, containing work item leaves. - A bar chart with departments along the y axis and total units along the x axis. Though these screens appear to be completely different underneath they are really more or less the same. 4.3 The second DSL or Control Structure An outline of the Control Structure is as follows: Object set o Dimension Sort order

8 Yassin Boudjenane Control o Object set [link to a set defined above, used for display data] o Display Controls Control o Axis [0,1,2] Binding function [discrete or continuous] Object set Dimension

8 8 Yassin Boudjenane Control o Object set [link to a set defined above, used for display data] o Display Controls Control o Axis [0,1,2] Binding function [discrete or continuous] Object set Dimension [optional] Coordinate object set [optional] Axis link Child axis Generally speaking the Control Structure lays out controls along a Cartesian referential defined by 0, 1 or 2 Axes. Objects are positioned on each axis using a binding function then displayed using the Display Controls. For example an input form has no Axis, and as many Display Controls as inputs fields. A list has a single Axis and as many Display Controls as columns. A pivot table typically has a single Display Control and 2 axes. A tree or multi-level pivot table are created using a parent-child Axis link. This can be defined as recursive as the number of levels in a tree isn t necessarily known before hand. Fig. 5. illustrates such trees used by our DSL editor, itself generated by a Control Structure description. Fig. 5. The Control Structure is used to define our in-house DSL editor. In the cases above, the Axes are discrete, in the sense that they position the Display Controls in specific cells. Axes can also be continuous to position Display Controls outside the confines of cells. So for instance a calendar in day view has 2 Axes; the vertical Axis uses a continuous binding function. A Gantt chart also has 2 Axes; in

9 Using activity descriptions to generate user interfaces for ERP software 9 this case the horizontal axis uses a continuous binding function. A line chart has 2 axes both of which use continuous binding functions. 4.4 Rendering the Control Structure The rendering pipeline is composed of 2 blocks: - Abstract rendering: projects objects into a 2-dimensional off screen representation of the control structure. This involves laying out child controls and making screen size related decisions. - Concrete rendering: the 2-dimensional abstract rendering is mapped to a specific rendering technology. For example, if using HTML as the rendering technology the concrete renderer will decide where to use tables or lists. 5 Discussion The first versions of both domain specific languages have been integrated into our ERP application and used successfully in client projects. We use three different concrete renderers. One renderer uses dynamic html ( AJAX ) to generate user interfaces with a level of interactivity matching the best desktop applications. Another renderer produces nicely laid out pdf reports. The third renderer produces partially interactive Excel reports. As both domain specific languages are stored as xml, they are combined in a single file (a *.ract file) that thus contains the full description of an activity or use case. Fig. 6. An elaborate chart that would be a massive pain to recreate from scratch each time. The Control Structure DSL in particular is still evolving. For instance, we are working on producing the type of charts illustrated in Fig. 6. Though these can be

10 10 Yassin Boudjenane described using the Control Structure the result is too verbose. Therefore the next step is to define Control Structure templates to enable reuse of the more complex controls. 6 Conclusion These results support the theory that elaborate user interfaces for ERP software can be generated with a simple domain specific language. They also demonstrate that the same description can generate user interfaces for different technologies. The current implementation relies on the fact that our ERP uses a different screen for each activity, whereas typical desktop productivity software (e.g. Office or Photoshop) allow a large number of activities on a single screen. Further work is required to handle this scenario, but it doesn t seem conceptually orthogonal. Acknowledgments. The authors gratefully acknowledge and thank Ben O Hear for his interaction design work and Jean-François Burdet for the implementation of the first DSL and many helpful comments and suggestions. 7 References 1. Cooper, Alan: About Face 3: The Essentials of Interaction Design. Wiley, San Francisco (2007) 2. Nielsen, Jakob: Prioritizing Web Usability. New Riders Press, Indianapolis (2006) 3. Norman, Don: The Design of Everyday Things. Basic Books, New York (2002) 4. Abrams, M., Phanouriou, C., Batongbacal, A.L., Williams, S., Shuster, J., An Appliance- Independent XML User Interface Language, Proceeding of 8th International World-Wide Web Conference. 5. XUL tutorial, http :// 6. Puerta. A.R., Eisenstein, J., A Common Representation for Interaction Data. 7. Azevedo, P., Merrick, R., Roberts, D., OVID to AUIML - user-oriented interface modeling, Proceedings of 1st International Workshop "Towards a UML Profile for Interactive Systems Development" TUPIS'00, York, Metawidget, 9. P. Sukaviriya, J. Foley, T. Griffith, A Second Generation User Interface Design Environment, Bridges between Worlds, Proceedings InterCHI'93 (Amsterdam, April 1993), ACM Press, pp Vanderdonckt, J., Knowledge-Based Systems for Automated User Interface Generation : the TRIDENT Experience. 11. Elwert, T., SchlungBaum, E., Modeling and Generation of Graphical User Interfaces in the TADEUS Approach, Designing, Specification and Verification of Interactive Systems, Springer, 1995, pp Snyder, Carolyn: Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann, San Francisco (2003) 13. Tidwell, Jenifer: Designing Interfaces: Patterns for Effective Interaction Design. O Reilly Media Inc., Sebastopol (2005)

AADL Graphical Editor Design

AADL Graphical Editor Design Peter Feiler Software Engineering Institute phf@sei.cmu.edu Introduction An AADL specification is a set of component type and implementation declarations. They are organized