This paper was presented at CUMREC '99, The College and University Information Services Conference. It is the intellectual property of the author(s). Permission to print out copies of this paper is granted provided that the copies are not made or distributed for commercial advantage and that the title and authors of the paper appear on the copies. To copy or disseminate otherwise, or to republish in any form, print or electronic, requires written permission from the authors.


The 21st Century User Interface Issues in interface design for student systems in the new millennium

Audrey Lindsay, Associate Registrar

Leo Fernig, Project Manager

University of British Columbia

The phenomenal emergence of HTML over the Internet has triggered a revolution in accessibility. A university�s admissions guides, calendars, course schedules and exam schedules are now routinely delivered electronically to the entire university community and beyond. Masses of information that were locked in mainframes have become widely accessible. Further, the emergence of applet technology has meant that the whole functionality of the Windows desktop can also be delivered over the Internet. A good indication of the fact that we are in the middle of a revolution in accessibility is that computer technology has become the focus of human rights legislation.

Rapid change is often accompanied by unforeseen and unintended consequences. The revolution in accessibility has made interface design a critical issue. Ten years ago developers installed systems for small groups of expert users. Any shortcomings in interface design could be overcome with sufficient training and user manuals. We still have to support a rich and complex Windows interface for expert users. But now we are also expected to support a number of other interfaces: lightweight Windows interfaces, HTML forms and also interfaces that are accessible to those with disabilities. While we may not be specialists in interface design and usability, we do have to develop a certain level of expertise regardless of whether we are evaluating software or developing our own. This paper examines current trends in different areas of interface design:

These different interfaces are examined in the context of the redevelopment of student systems at UBC. We have chosen Java as the platform for the redevelopment project so most of the examples in this paper are from the world of Java. Nevertheless, the issues are generic and so the arguments apply equally to the Microsoft platform. Lastly, and perhaps most importantly, the paper examines the overall design that is needed to integrate these different interfaces into one coherent architecture.

HTML

HTML (Hypertext Markup Language) is still the cornerstone of the revolution in accessibility. It was designed for delivering, presenting and cross-referencing documents over the Internet. That is still its main strength. And so using HTML for something like an Admissions Guide is an obvious choice. The form tag (introduced in HTML 2.0) extended the basic functionality of HTML by providing a very basic data entry capability. The HTML form works very well for a simple and discreet transaction like making a hotel reservation. If a transaction spans multiple forms then cookies (or tokens) can be used in order to create a pseudo-session. An HTML form basically supports three actions:

  1. Forward.
  2. Backward.
  3. Submit.

From a user perspective the constraints are simple and obvious. Because of these restrictions, the designer is automatically protected against obscurity and excessive complexity. Because HTML is primarily a vehicle for delivering content, the design of good HTML is really the responsibility of a graphic artist. If a development team is planning on using HTML forms then there is an obvious advantage in getting input from graphic design professionals.

Figure 1Figure 1
The HTML version of the UBC course schedule inquiry

In 1997 at UBC we delivered a number of student services over the Internet using HTML forms. An example of this was an HTML version of a course schedule inquiry (see Figure 1 above). It has the obvious virtue of simplicity. However, it also has some obvious weaknesses. It is predicated on the assumption that a student already knows the codes for courses (though this weakness could be overcome by a drop down list of courses). More seriously, it is not a very useful tool for browsing or exploring. If you do not find what you want the first time you have to go back and forth again and again until you do.

So what is the future of HTML as a user interface? The limitations inherent in this interface have triggered the emergence of two different technologies. In 1995 Sun Microsystems and Netscape started developing JavaScript. JavaScript is a scripting language that can be embedded in a web page so that the page exhibits some Windows-like intelligence. You can use it for immediate data-entry validation, interaction between user interface components and communicating with the underlying browser technology (for instance, finding out which browser the page is running in). JavaScript will probably continue to be a useful method of enhancing a web page as long as HTML remains the primary vehicle for delivering content over the Web. The other technology is an attempt to define a completely different markup language, XML (Extended Markup Language). XML, like HTML, is a subset of SGML (Standard Generalized Markup Language). It was developed by the XML Working Group formed under the auspices of the World Wide Web Consortium (W3C) in 1996. In HTML tags are static. For instance, <H1>�</H1> is the tag for a document heading. XML allows the developer to dynamically define tags. Nonetheless, it is still a markup language and so, like HTML, it is primarily a vehicle for delivering content across the Web.

Irrespective of its limitations as an interface, HTML will continue to be very important. There are a couple of very obvious technical reasons for this. First, bandwidth is still a serious problem. If you are using a 28.8 modem then downloading a Java applet (or an Active-X control) can be extremely painful. By contrast, the duration involved in downloading an HTML page now seems quite reasonable. Secondly, there is a large gap between browser technology and applet technology. The first version of Netscape that was fully JDK 1.1 compliant (without having to install any special patches or special versions) was Netscape 4.07 which was released in October 1998. That is a full 18 months after JDK 1.1 was released. At this time (November 1998) it may be naïve to expect a rapid implementation of JDK 1.2. Unless there is some rapid and unforeseen change in both bandwidth and browser technology, it is likely that HTML will remain a standard interface well into the new millennium.

The Windows interface

The Windows interface is now the most common interface for delivering functionality. It is also called the "direct manipulation" interface because it allows the user to manipulate objects directly instead of issuing commands to the computer. The research undertaken by Xerox Corporation at their Palo Alto Research Center in the 1970�s has proved to be an incredibly rich vein that is still being mined by all the major software vendors. There is now an extensive academic literature on the subject. On a more practical level, Microsoft publishes a style sheet on Windows design which also includes some brief and very appropriate sections on design principles. It seems safe to assume that the Windows interface will continue to be the main vehicle for computer-human interaction well into the foreseeable future. The major software vendors are all basically enhancing and extending the same basic metaphor. The latest offering from Microsoft (Windows 98) merely refines certain details of the interface. Sun�s JDK 1.2 (which incorporates the so-called "pluggable look and feel") simply offers a certain level of abstraction and independence in implementing a Windows interface. And, of course, Apple, which did more than any other company to develop and market the Windows interface, continues to build on the same paradigm.

Nonetheless, the very richness of the interface holds certain pitfalls. Also, delivering a Windows interface over the Internet (either in Java or Active-X) presents a special set of engineering problems. So we need to be sure that there is a good business case for using a Windows interface. If the same functionality can be delivered at much less cost through HTML forms then why waste time and money solving complicated engineering problems. Take, for example, course registration. If course registration is taken in the narrow sense of entering a course number and pressing a button called "Register", then an HTML form is probably a better choice than a Java applet. However, from the student�s point of view this HTML form has only automated a very small part of the registration process. There is still the problem of consulting the course schedule. And the course schedule is merely one resource in the process of building multiple alternative timetables (the alternatives are needed just in case certain choices are full). Students also have to consult the calendar to ensure that the courses they have chosen meet their degree requirements. There is no simple linear relationship between these activities. It is in this context that the Windows interface is far more effective because it allows the user to organize the different tasks in a way that suits their needs.

One of the biggest difficulties in designing a Windows interface for mass consumption is providing an appropriate set of constraints. A constraint means making obvious to the user what the appropriate action(s) are in a given context. As we saw earlier, in the world of HTML forms this is not a problem because typically there are only three possible actions (backwards, forwards and submit). In a Windows interface there is no limit to the number of buttons (and hence, actions) the designer can paint on a screen. Further, the Windows interface supports a whole range of user interactions besides merely pushing a button:

If you are designing for a small group of expert users this very richness may not be a problem. If you are designing for thousands of inexperienced users then the constraints have to be made extremely clear.

Figure 2Figure 2

The UBC Course Schedule: A simple Java applet that builds on the Explorer metaphor

At UBC in June 1998 we delivered an applet version of the course schedule inquiry. It is built on the metaphor of the Windows Explorer. The first release was quite complex in that it included some advanced search features. When we conducted usability tests with students we realized that we needed a much simpler interface. The final result is a highly simplified Explorer (see Figure 2 above). The constraints are simple and obvious. The only thing you can do is click on a folder. Nonetheless, it is a much more powerful engine for searching than the HTML interface.

The Windows environment allows the developer to create Windows and dialogs at will. With HTML you always tend to be working with one pane (though you can have multiple frames). Again, this is an area in which Windows designers need to exercise a certain amount of caution. Modal dialogs are an obvious choice for error messages. Search mechanisms can also be presented through modal dialogs. Multiple Windows present a more serious issue. Microsoft recommends an MDI frame if the Windows present documents of the same kind (e.g. Word documents). Interestingly, the MDI frame is not available in JDK 1.1. At UBC our experience has been that MDI frames are not particularly useful in the context of administrative systems and so we do what a lot of vendors of large-scale administrative systems do: put different panes on different tabs within a frame.

Feedback is another important design principle that can be problematical. Windows objects represent objects in the real world. The whole Windows environment is a metaphor for the visual and tactile world we inhabit. One of the reasons this metaphor is convincing is because of immediate feedback. When I pull on the tab of a folder I expect to see it open immediately. When I click a light switch I expect to see the light go on (or off). Likewise with the Windows interface:

All of this may seem obvious enough except that it requires some careful engineering when delivering applets over the Internet. It is important that all visual objects be packaged with the original applet so that there is no apparent time lag for the user. You do not want to wait for a dialog box to be transmitted over the Internet when you are waiting for an error message. Lists need to be populated before the user clicks on them. When you click on a drop down list of country names you do not expect a 10 second delay while database values are retrieved across the Internet. You expect the list to open immediately.

Accessibility

Accessibility has become a very topical issue for a number of reasons. Recent legislation in the United States has caused software vendors to think very carefully about accessibility. Although legislation in Canada is not as specific, the Canadian Charter of Rights and Freedoms and similar legislation in the provinces point in the same direction. The term disability covers a wide range of impairments that include:

All of this provides some very interesting user-interface design challenges. There is obviously no single strategy for dealing with all these issues. Rather, there is a range of strategies that you can adopt depending on how far you are committed to implementing accessibility.

  1. Follow design guidelines that promote accessibility.
  2. Use an accessibility aid that leverages off existing interface components.
  3. Create a speech application for people who are blind. This involves a whole set of special technical issues that are discussed in the next section. It is also, the most expensive solution as it involves creating a whole new set of interface objects instead of building on the existing interface components.

There are a number of simple design guidelines that promote accessibility. There should be keyboard access to all features (for instance, short cut keys for menu items) so that there is an alternative to using a mouse. Sound should not be used exclusively as a method of user notification. Likewise, colour should not be used exclusively to convey a message. Lastly, the application should support font and resolution changes.

Currently there two main kinds of accessibility aids: screen magnification software and screen readers. A screen magnifier acts like a magnifying glass for the portion of the screen that is under the pointer. A screen reader uses a voice synthesizer to translate the object under the pointer into human speech. If the pointer is over a hypertext link then the speech synthesizer will say something like "Link: ..".

Accessibility aids can only work if the underlying user interface objects are built according to certain specifications. Sun has developed the Java Accessibility API which consists of a number of interfaces that must be implemented if a standard accessibility aid is going to work with the user interface. There is, for instance, an interface called AccessibleText that must be implemented by all text objects that need to be made available to an accessibility aid. Microsoft provides similar functionality with the Active Accessibility Software Development Kit.


Figure 3
Accessibility interfaces make information about the Windows environment available to the accessibility aid.

Building an interface that is accessible to aids obviously requires extra work and design. It basically involves an extra layer between the Windows GUI and the accessibility aid. A solution that is somewhat less daunting is to deliver functionality through a browser that already has the accessibility interfaces built-in. This has the added advantage that HTML is more easily rendered into speech than a complex Windows interface. This is the direction we are exploring at UBC and the only real caveat that applies is that designers have to be careful of certain HTML tags (such as tables) as they can confuse the accessibility aid.

Speech interface

In theory the speech interface holds enormous possibilities. Academic studies claim that speech is the most efficient form of computer-human interaction. In practice, the situation is a little more complex. Although mass produced speech technology software is now available for the PC, its main use is to record dictation. Although we may not implement speech applications directly we do need to understand the structure and limitations of speech technology if we want to use accessibility aids effectively. We also need to understand it as an emerging technology as there is always a possibility that it may, at some point in the future, play a more pivotal role in the computer-human interface.

Speech technology consists of two parts: 1) Speech synthesis and 2) Speech recognition. Speech synthesis is the process of converting text to speech. Speech recognition is the process of converting speech to text. In the Java platform there is a speech API that provides a standard set of interfaces to an underlying speech engine (just as the Java Abstract Windows Toolkit, or AWT, provides a standard interface to a graphical user interface engine). An example of an implementation of this technology is IBMs Speech for Java that uses IBMs ViaVoice as the underlying engine.

A true speech application tries to imitate the characteristics of human speech. Just as there are an important set of visual clues that add meaning to a Windows interface (for instance, the raised borders around a button tell us that it is a button) so pauses, intonation and other clues have the same function in conversation. As Suns speech interface guide suggests: "Generally, a successful speech application is designed with speech in mind. It is rarely effective to add speech to an existing application or to translate a graphical application directly into a speech only application". This is an inherent problem with screen readers that attempt to read a complex graphical environment. For this reason, a well-designed HTML interface is probably going to be rendered more effectively by a speech synthesis engine.

Shopping versus programming

Developers are not necessarily experts in interface design. In an ideal world there would be sufficient funds to include interface design experts as full-time members of development teams. This is usually not possible and so we have to look elsewhere for solutions. One partial solution is to raise the general level of awareness of interface/design issues within a development team. Another solution is to buy interface components rather than developing them from scratch. This may require a bit of a change in culture as developers enjoy the creative process of building new objects and so they often prefer building something from scratch to buying something. The Java component model, also known as Java Beans, lends itself extremely well to the process of buying and installing third party interface components (and, of course, the same applies to Microsoft Active-X controls).

The three stages in buying third party user interface components are: 1) searching, 2) evaluating and 3) installing. The web is the obvious vehicle for conducting a search. The two best known sites for Java components are www.jars.com and www.gamelan.com. The large corporations that are seriously involved in Java development (IBM, Oracle and Sun) also have some interesting offerings. As you shop around there are often good pictures of the objects that are for sale (and sometimes they are free!).


Figure 4
An example of a calendar component available at http://www.jars.com

The Internet makes evaluating a component extremely simple. You can usually download an evaluation copy from an ftp site. Once it has been unzipped it should be extremely easy to add it to the toolbar of any integrated Java development environment (Borlands Jbuilder, Symantecs VisualCafe, IBMs Visual Age). Normally all you have to do is right mouse click on the toolbar tab and complete some simple install wizard. The ease with which the component can be installed is one of the criteria that should be used in evaluating the component. If the component follows the Java Bean specification correctly it should be installed very easily.

Figure 5
An html browser component from a company in Norway installed on the toolbox of Borlands JBuilder

Evaluation and testing should not take more than a couple of hours. Size is a critical criterion. If you are deploying over the Internet then you must use lightweight components. At UBC we actually had to spend several days looking for a lightweight grid control that we could use in our applets. The component should also implement a standard model-view design. That means that the presentation layer should be very clearly separated from any underlying data objects. Ideally the component should also come with documentation and source code. And, of course, price is an important consideration. There is a whole range of components between $500 and $1500. These costs are very reasonable compared to the amount of in-house programming time that would be needed to create something comparable.

Architecture

Interfaces are just different ways of viewing the same underlying data and business rules. The human interface, business logic and data are the three different layers of a system. These layers must be carefully separated if we are going to support multiple interfaces. At UBC we chose the Java platform to implement a three-tier architecture. You can, of course, create a similar three-tier architecture using Microsoft technologies. Implementing a three-tier architecture that supports different interfaces is inherently complex and difficult, irrespective of the merits and weaknesses of the competing technologies.

Figure 6 below shows a simplified view of the architecture we have implemented at UBC. An Oracle database runs on its own server. A Java application server (Tengah from Weblogic) runs on a separate server. Java programs that encapsulate business rules and data objects run on the application server. They communicate with the database using JDBC (Java Database Connectivity). The functionality of the middle tier can be delivered to the client in a number of different ways.

Both the lightweight and the heavyweight clients use RMI (Javas Remote Method Invocation) to gain access to business rules and data objects on the middle tier.

Figure 6

Figure 6
An example of supporting multiple user interfaces.
Java three-tier architecture at UBC.

Three tier architecture is complex for a number of reasons. First, in order to have truly reusable objects (shared by different interfaces) we need to have a good understanding of the boundaries of components. Often we only develop this understanding after we have actually experimented with using a component in different contexts with different interfaces. Secondly, the user interface itself encapsulates certain rules: "Every interactive application system has to contain knowledge about two domains, (1) the subject area of the application system, and (2) how to interact with the user". The interaction of two components on a graphical user interface (for instance, clicking on a folder in a tree control and the display of the contents of that folder in another pane) has to be captured in some program logic. Likewise, the relationship between two HTML forms (for instance, pressing a "Search" button on one form and then seeing the results on another form ) requires program logic in a servlet. So, however much you try to isolate business logic in the middle tier there is still an important element of "behavioral" logic that has to be located in the interface. And so maintaining multiple interfaces is going to be more costly. Lastly, there are simply far more components to develop and manage in a three tier architecture that supports multiple interfaces.

Conclusion

So what will the computer-human interface be like in the 21st Century? The exponential growth in hardware performance underlies the growing complexity of human-computer interfaces. In the last five years alone, visual interfaces and speech interfaces have become much more sophisticated. Computer-human interaction will, no doubt, increasingly resemble communication between humans in that it will be richer, more diverse and more complex.

These trends have several important practical consequences for those of us who are involved in developing and implementing systems. First, interface design is not a peripheral activity in the development cycle. It lies at the heart of what we are trying to achieve when we deliver services electronically. If we do not have the resources to hire interface design experts, then we must, at least, try to develop that expertise in-house. Secondly, a usability test team needs to be an integral part of a project. At UBC we have tried to address this issue by hiring a team of students to work alongside our developers. This has to be an on-going and iterative process because the more services we deliver over the Internet, the more we will learn about what works and what does not work. We also need to be aware of the continuously changing expectations and computer-literacy of the student community as that defines the levels of complexity that are acceptable. Lastly, we must be prepared to support multiple interfaces to meet the needs of different constituencies. As we have seen, the underlying architecture required to achieve this is considerably more complex than that of traditional systems. However, this complexity must be transparent as our services are judged primarily by the quality and usability of their interfaces.

Appendix A

Accessibility legislation in the United States and Canada

In the United States there is legislation that is quite specific about accessibility. On August 7, 1998, the President signed the Workforce Investment Act of 1998, which includes the Rehabilitation Act Amendments of 1998. The first part of Section 508 of the Rehabilitation Act states:

(A) Development, procurement, maintenance, or use of electronic and information technology: When developing, procuring, maintaining, or using electronic and information technology, each Federal department or agency, including the United States Postal Service, shall ensure, unless an undue burden would be imposed on the department or agency, that the electronic and information technology allows, regardless of the type of medium of the technology
(i) individuals with disabilities who are Federal employees to have access to and use of information and data that is comparable to the access to and use of the information and data by Federal employees who are not individuals with disabilities; and
    1. individuals with disabilities who are members of the public seeking information or services from a Federal department or agency to have access to and use of information and data that is comparable to the access to and use of the information and data by such members of the public who are not individuals with disabilities.

In Canada the issue falls more generally under the Canadian Charter of Rights and Freedoms. Section 15 (1) states:

Every individual is equal before and under the law and has the right to the equal protection and equal benefit of the law without discrimination based on race, national or ethnic origin, colour, religion, sex, age or mental or physical disability.

Section 15 (2) adds that

Subsection (1) does not preclude any law, program or activity that has as its object the amelioration of conditions of disadvantaged individuals or groups including those that are disadvantaged because of race, national or ethnic origin, colour, religion, sex, age or mental or physical disability.

Different provinces like British Columbia also have their own human rights codes.

Bibliography

Goodman, D. JavaScript Bible. IDG Books Worldwide, 1998.

Hancock P.A. & Chignell M.H. Intelligent Interfaces. Theory, Research and design. North-Holland, Amsterdam 1989.

Horstmann, C. & Cornell, G Core Java. Sun Microsystems, 1997.

Interactive Speech Technology: Human factors in the application of speech input/output to computers. Baber, C. & Noyes, J. M. (Ed). Taylor & Francis, London 1993

Norman, D. A. The Design of Everyday Things. Doubleday, New York 1998

Microsoft Press, The Windows Interface Guidelines for Software Design. Microsoft Press, Redmond, 1995.

Schmandt, Christopher. Voice Communication with Computers: Conversational Systems. Van Nostrand Reinhold, New York, 1994.

Shneiderman, Ben. Designing the User Interface. Strategies for Effective Human-Computer Interaction. Addison-Wesley, New York 1997.