DESIGNING A GRAPHICAL USER INTERFACE FOR AN AUSTRALIAN DATABASE PRODUCT: BACKGROUND TO THE DEVELOPMENT OF DBQ WINDOWS Paper for the Australian Computer Society Canberra Branch Conference - 18 March 1994 Tom Worthington Defence Project Manager - DBQ Windows Project Senior Policy Adviser, Data Administration Standards HQ Australian Defence Force February 21, 1994 ABSTRACT Development of the Graphical User Interface (GUI) for the DBQ Windows product, under the Australian Government National Procurement Development Project (NPDP), is described. This is used as an example of a successful joint government - industry research and development project. The process by which design choices were made with the assistance of the Government partners is described. INTRODUCTION Much has been written about how to encourage Australian companies to produce world competitive information technology products. This paper describes how it has actually been done successfully for one project. The product is "DBQ Windows" from Information Technology International (ITI). It provides a graphical user interface for ITI's DBQ data base product. This background records some of the events which lead to DBQ Windows. DBQ Windows was previewed November 1993 and had an initial release at the end of 1993. The product has had several sales, including the Commonwealth and Telecommunications Ombudsman offices. DBQ Windows has a number of features which makes it different from other GUI database products. The differences are in part due to the process by which it was conceived and developed, by a partnership between an Australian company and government agencies. THE GREAT GUI DEBATE By early 1991 it had become evident to many of us in the Communications and Information Systems Branch, Department of Defence, that the Graphical User Interface (GUI) would have advantages for standardisation for Defence users (lower cost of development, training and support). However there were a number of problems with GUIs: differing standards, poor performance, LAN centric implementations and lack of products. There was an intense internal debate in Defence as to if, which and when, GUIs would be used. While there were GUI products becoming available for office automation, the position with data base products was less clear. There were multiple GUI standards, with some operating systems even having a choice of several GUIs. The GUI imposed a large load on the system, both processing capacity and the network. Most of the GUI products were designed for LANs and may not have operated successfully across wide area networks. While GUI products were being used in a limited way in small work groups, there was concern that they would not scale up to a large corporate database application with thousands of users. Each time there was a product demonstration I asked "what about a GUI version?". The replies were mixed. Some vendors claimed GUIs were not required for database products (some still do). Some demonstrated non-standard GUI products and claimed them to be standard. Some demonstrated software which only appeared to run adequately on high performance equipment. The trend away from "mainframe" type computers to "client server" LANS may have gone slightly wrong. The personal computer had started out as a simple device. The LAN and LAN server had been added to provide multi-user access. However now the LAN server was becoming as complex as the mini and mainframe computers it was supposed to replace. Many assumed to have a GUI, you had to run the application on a PC-type computer. In the April 1991 edition of the ACS Canberra Branch Newsletter my paper entitled "The Client Server Model Applied to the User Interface" was published. This suggested that just the user interface part of the application could be run on the client machine.It could be connected by a network to the application processor. At around this time there was an ITI product presentation on their DBQ data base product. ITIs response to the, by now standard, "what about GUIs?" question, was "why would you want one?". APPROACH FROM ITI FOR A NATIONAL PROCUREMENT DEVELOPMENT PROJECT (NPDP) Mike Reid, ITI's Canberra Branch Manager at the time, took the GUI question seriously. As a result the Defence Organisation was approached by ITI to assist with development of GUI software to complement their Relational Database Management System product DBQ. Mike Reid suggested Defence could sponsor a grant under the National Procurement Development Program, administered by the Department of Industry Technology and Commerce. Defence assistance was based on the concern that there might be difficulty in finding good GUI products and particularly Australian GUI products in the future. They considered that the NPDP grant would provide useful impetus to this and might set an example to other Australian companies to start work on GUIs. At this point I proposed the code name "DBQ Windows" for the project. The name has been retained for the commercial product. Under the proposal Defence's sponsorship of the grant was limited to having a staff member attend meetings and provide advice. There was no proposal for Defence to supply any finance, nor other resources. It was not proposed to have Defence test or trial the product. At about this time ITI became concerned that formal approval for Defence involvement would not come in time. They therefore asked one of their more progressive Canberra government DBQ customers, the Insurance and Superannuation Commission (ISC), to be joint partners in the project. After some confusion, due to the need for ITI (based in Brisbane), Insurance and Superannuation Commission and Defence (both in Canberra) to sign the one large application form, it was duly submitted. Both Defence and the Insurance and Superannuation Commission became the government partners in the project. Defence was under no obligation to buy the resulting product. The ISC also undertook their joint partnership of the same understanding, but with the option of providing beta test facilities if their resources and work schedules allowed. WHAT SHOULD A GUI PRODUCT DO? With the application submitted, thoughts turned to what the product might actually do. It is usually very frustrating for a customer to make suggestions for what should be in a product. Companies are reluctant to reveal research directions well enough in advance for them to be changed in response to customer comments. Also "that's a good idea but who will pay for its development?" is a common comment. Here was a case where we would have access to the companies' development plans and where we represented the people providing a significant proportion of the development money. This time they could not ignore the customer. In late May, Defence was asked by the Australian Defence Force Academy (ADFA) to suggest project topics for final year IT students. One was submitted on "Windows DBMS", asking for students to assist with advice on what the DBQ Windows product should look like and do. The NPDP grant was still under consideration, so the company name was not mentioned in the student project proposal. The NPDP grant application was approved on 5 July 1991 and announced publicly by ITI in August. Officer Cadet Namoi Armburst and Midshipman Peter Thompson, third year information science students from ADFA, selected the project (with supervisor Don Munro) to advise on GUI features. All of the GUI standards documents I had collected were shipped over to the students. The students delivered a seminar, with demonstration of a GUI prototype and their final report "Recommendations for a GUI for a DBMS" in November 1991. ITI attended the seminar and were provided with a copy of the report. The students involvement in the project was timely, as it allowed myself and those at ITI, to question the assumptions on which the project was based. DESIRABLE GUI FEATURES By January 1992, the students' report, and my first formal advice were sent to ITI, on what DBQ Windows should look like. This must have been a little daunting for ITI as it was about 13 pages of technical detail. It represented most of the Defence contribution to the content of the resulting software. Some points were: Distinction between ordinary and advanced users: Advanced users (including IT professionals) would benefit less from GUIs than ordinary users. However IT professionals were more likely to be involved in selecting IT products. This had implications for developing and marketing of the GUI product. The use of GUIs would imply at least the ability to store and display bit-map graphics. This was a feature DBQ didn't have in the existing product. Support for bit map graphics were added to the product as a result. The priority order for GUI implementation for the government market was suggested as: Microsoft Windows 3.0, Apple Mac, OSF Motif, Open Look and IBM/Microsoft Presentation Manager. However I hedged this by suggesting starting with both OSF Motif and Microsoft Windows 3. The initial DBQ Windows release supports OSF Motif (under X-Window) and MS-Windows version 3. There appears to be little market demand for support of the other operating systems. Default minimum GUI mode It would be an advantage to have a "default" mode where the minimum of GUI features will be used and would be mainly implemented by the development tool automatically. This would minimise the resistance to the GUI product by new GUI users. With the minimum GUI mode most of the screen features from the text system would be translated into GUI equivalents. Most information would be displayed as text (apart from bit-map graphics). Command input would be by pull-down menus, click boxes and the like. These are the equivalent of character command input from a non-GUI system. All the "point and click" commands would have keyboard equivalents, so the system could be used without a mouse. There would be no display or manipulation of data through images. One example would be to display data as a may or schematic and allow values to be changed by dragging objects on the map. While impressive for demonstrations, such advanced features may be of limited value in routine applications. Also experienced keyboard users can find "cute" GUI interfaces distracting. In practice ITI implemented a limited form of this by allowing "active" areas on bit map graphics. Clicking on a section of the graphic can activate a predefined function. With this technique, manual layout of GUI elements and designer expertise in this would not be required. Data dictionary definitions would be used to build default screens, using an existing DBQ feature for character screens. For GUI screens this would be enhanced with rules for selecting where various GUI elements, such as such as radio buttons and combo boxes were most appropriate. This would not only save application developer's time, but also educate them as to the appropriate way to build good GUI screens. Screens which did not make extensive use of graphical features were suggested for aiding the transition from a character mode interface. Many of the demonstration applications from GUI tool suppliers (and first applications by new GUI application developers) make extensive use of images, mouse operations and colour. The use of these was cautioned against, as they tend to confuse and alienate users more accustomed to character applications and in practice may not be particularly useable. Simple default for generating applications, were suggested, to make the product more acceptable. The automated GUI support was not completely achieved with the first release of the product. DBQ Windows supports a limited auto generation of GUI screens, but with essentially the same look as character screens. Developers must manually insert and position additional GUI features. Size and complexity A trade-off had to be made between having a single complex product and a simple base product with optional modules. Overall a single product would be better for the user (but perhaps not good marketing). Having a large number of different manuals and separate product interfaces simply increases the overall complexity. ITI accepted the recommendation to implement a single product. Reliance on the client server model It was strongly suggested that DBQ Windows provide other options in addition to client-server LAN based computing. This was an expansion of the idea of the GUI client from the April 1991 paper. One major problem with existing GUI products was that the application client (front end) runs entirely within the work-station (which might be an IBM PC or Unix computer). The server (back end) provides DBMS services only. Therefore the computing power available to the user is limited to that in their one work-station. The ability to split the application load between the client and server is fixed by the design of the database interface. The user may have several hundred work-stations available, but can only use the processing power of one at a time. The client - server model assumes a fast communication link between the client and server. This makes applications requiring large amounts of data, or which use low speed links difficult to implement. An application which processes a large number of data base records, such as a monthly report, will be limited by the speed of the LAN connection to the server. This limitation can be overcome by running the application remotely, in the server (or on a processor with a higher speed connection to the server). The low cost multi-processor systems now becoming available made this option particularly attractive. A work-station connected over a low speed, wide area network (WAN) connection would be severely limited in its ability to support a client-server application. WAN connections are an order of magnitude slower than LAN connections. This could be a major problem for large organisations, with an infrastructure designed for mainframe - terminal applications. Installing a GUI interface may require installing a new communications network. It may also require new work-stations with sufficient capacity to run the application. In addition to technical constraints the cost of the required network may not be justified. X-Terminals Using X-Window terminals with an application does add some flexibility by providing terminal access. The client application can be on a multi-user computer connected to the x-windows terminal by a LAN. However the high bandwidth requirements of x-window may make it impractical to run over a WAN designed for character terminals. It was likely then, that X-Window software (then V11.4), might in later versions contain enhancements to increase the efficiency of the system. These enhancements might have made X-Window practical (and affordable) for general office automation use. This would have allowed ITI to produce one X-Window version of DBQ Windows and use X-Window emulation to support Apple Mac, Microsoft Windows 3, OS/2 PM and other GUI platforms. X-Window terminals have become cheaper and emulations more efficient. However this has been overshadowed by the success of MS-Windows 3.x in the market. ITI initially implemented for X-Window, however the portable design allowed them to quickly port to MS-Windows 3.x, as that came to dominate the market. GUI Model A three tiered model was suggested, splitting the "client" into a "presentation server" to run in the work-station and a "application server" which can run in another processor. ITI chose to initially implement a two tiered model with the application server and the database engine both running on the one server processor and the "presentation server" on the user's workstation. This retained most of the benefits of the three tiered model while fitting better with the architecture of the existing DBQ database product. There was no standard protocol for the interface between the presentation server and the application server. As a result ITI had to write their own protocol. This is essentially an enhancement of the previous character terminal protocol. Low speed links The goal was suggested, of allowing the protocol between the presentation and application servers to be suitable for use with existing low speed WAN connections, of down to 9600 bps. This could only be done where extensive bit mapped graphics were not used, or were loaded from a local disk. This would allow for remote users on low speed links. ITI claim to have achieved this performance. This was successful and DBQ Windows should support simple dial-up modem lines, SNA, X.25, TCP/IP and GOSIP compliant communications with no change to the applications software. GUI Guidelines ITI had only limited experience with GUI development. The development team was provided with dozens of references to GUI style manuals and standards. IT technical people tend to consider "look and feel" of products less important than functionality. They tend to produce overly complex and inelegant GUI designs. One of my tasks was to act as an advocate for a clean elegant appearance for DBQ Windows, which matched the "lean" underlying technical features. I had been researching possible GUI standards for Defence, this included providing advice on the user interface for new military air traffic control radars and command support systems. Also I had completed introductory tertiary courses in graphic design and video production, to be able to understand the new challenges of GUI interfaces. Incorporating good layout, typographic and colour guidelines into DBQ Windows documentation and product was suggested. In some cases this could decrease the cost of development of the product, by eliminating complex and inelegant features. Some suggestions were for: the automatic layout of screens based on a grid, limiting typefaces used to a balanced set and limiting colours to defined pallets based on colour theory. The GUI style suggestions met with limited acceptance. The automatic layout feature was implemented in part. The initial release will support IBM CUA style guidelines. However the automatic typeface and colour selections have not been implemented. ITI have a professional software engineering staff. However those staff had limited experience with GUIs. It was very difficult to get software engineers to worry about questions of aesthetics and colour balance. In one case I was shown a demonstration screen with light blue text on a lime green background. This looked awful, but the engineers response was: "the colours are fully user configured, you can select any colour combination". Helping the user select pleasing colours was not part of the training of software engineers until recently. PROTOTYPES PRODUCED During 1992 the government (with myself representing Defence and Gary Jobson representing the ISC), NPDP and ITI representatives met regularly to review progress on the project. Several increasingly sophisticated prototypes were demonstrated. It was a curious sensation to look on something which had only been conceived a few months before, but was now real. However there was still much work to be done by the staff of ITI to produce a mature product. INGRES SELECTED BY DEFENCE During the DBQ Windows project Defence decided to select a data base product for mid-range systems. The Mid-range RDBMS evaluation was performed with the assistance of a professional technical consultant. Due to my involvement with DBQ I requested to not take part in the selection and was excluded from all further deliberations. One requirement was for a GUI interface and DBQ Windows was not ready. Ingres was chosen by the evaluation team, partly because it supported the MS-Windows and X-Window GUIs in a client server environment. DBQ Windows was released in late 1994. By a curious coincidence the first production implementation of DBQ Windows was at the Office of the Commonwealth Ombudsman. It was while working at the Ombudsman's Office, as IT manager, that I wrote the paper which lead to my involvement in the DBQ Windows project. The application which I had maintained, while writing the paper became the first application to be implemented with DBQ Windows. Bibliography "The Client Server Model Applied to the User Interface", Tom Worthington, ACS Canberra Branch Newsletter, Australian Computer Society, April 1991. "Recommendations for a Graphical User Interface (GUI) for a Database Management System", OFFCDT N Armbrust and MIDN P Thompson, Australian Defence Force Academy 1991 (available from ADFA) "Graphic Design for Electronic Documents and User Interfaces", Aaron Marcus, ACM Press, 1992. "The Art of Human-Computer Interface Design", Brenda Laurel, Addison-Wesley Publishing Company Inc., 1990. Open Look Graphical User Interface Application Style Guidelines, Sun Microsystems Inc, Addison-Wesley Publishing Company Inc. 1990 Apple Human Interface Guidelines: The Apple Desktop Interface, Apple Computer Inc, Addison-Wesley Publishing Company Inc. 1986 SAA Common User Access Basic Interface Design Guide SC26-4583, IBM 1989 SAA Common User Access Advanced Interface Design Guide SC26-4582, IBM 1989 OSF/Motif Style Guide, Open Software Foundation, 1990