Home > Press > Revelate at HCII 2009 San Diego
Revelate at HCII 2009, San Diego
Revelate has been invited to present a paper on it's groundbreaking work on automatic interface generation at the International Conference on Human-Computer Interaction in San Diego, California.
Below is an abstract of the paper presented. Visit our product pages for more infomation on Revelate's work on automatic software generation and it's application.
Using activity descriptions to generate user interfaces for ERP software
Introduction
Our company, Revelate, delivers tailor-made 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.
Creating user interfaces and printed reports using traditional RAD tools typically involves manual positioning and styling of user interface controls. Though this approach can produce results that are well matched to the users’ needs it is time-consuming and maintaining consistent design throughout an application can be challenging.
On the other hand user interfaces generated purely from a description of the data structures – typically the raw database tables -- tend to be unwieldy. Suitable for system administration tasks they rarely meet reasonable usability requirements and as such are uncompetitive with manually crafted user interfaces.
A generator approach using domain specific languages to describe use cases is examined.
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.
Methods
A variety of existing applications renowned for their user interfaces were analyzed, their user interaction design patterns 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 we were looking for.
A thorough ex-nihilo design of a complete ERP module containing most ERP screen types was executed and the design decisions were identified. This design was achieved with user interaction best practices including personas, storyboarding, paper prototyping and an interactive prototype. Both failure and success of various solutions were documented, completing our key characteristics research.
Two domain specific languages were created; the first describes the general organization of an activity into sections and controls, using a vocabulary representative of the user’s intentions in terms of data manipulation. The second describes the controls themselves, it is capable of representing a wide array of control types such as a list, a Gantt chart or a calendar by defining them as a projection of data structures onto the screen space.
These two domain specific languages were then subjected to a battery of real-life problems and evolved accordingly.
Results & Discussion
The first versions of both domain specific languages have been integrated into our ERP application in used successfully in client projects. The current version uses dynamic html (“AJAX”) to render the user interfaces and is capable of producing printed reports in html, pdf and Excel formats.
As both domain specific languages can be stored as xml they are currently combined in a single file (a *.ract file) that thus contains the full description of an activity. Currently this file is edited using a fairly low level editor (itself described in a *.ract file). A higher level editor enabling a user to create his own activities is in the works.
Conclusion
These results support the theory that elaborate user interfaces for ERP software can be generated by combining a simple domain specific language with data and data structure analysis. They also demonstrate that the same description can generate UIs for different technologies.
The current implementation relies heavily on the fact that ERPs typically use a different screen for each activity, whereas typical desktop productivity software such as Office or Photoshop enables a large number of activities on a single screen. Further work is required to handle this scenario, but it doesn’t seem conceptually orthogonal.
Further research is also needed to render an activity on different devices.
We also expect that both of our domain specific languages can be merged into a single DSL. Work on this is in progress.