GMD, German National Research Center for Information Technology
Schloß Birlinghoven, D-53754 Sankt Augustin, Germany
appelt@gmd.de, hinrichs@gmd.de and woetzel@gmd.de
In general, the more complicated or complex the information, the more objects in the data repository, the more operations and options a system containes — i.e., the more functionality a system provides: the more buttons, menues, icons, text fields, etc. have to be presented in the user interface. An effective interface that has the system functionality and data only "one mouse-click away" tends to have a rather cluttered look. For experienced users this may not be a problem but the most efficient way to invoke functionality. For other users, however, reducing functionality (e.g., eliminating those features which are of no relevance to them) means achieving a simpler interface and thus may eventually improve their efficiency in using the system. In other words: effectivity may be efficient for some user groups while it may not be efficient for others.
This is of particular relevance on the Web with its variety of users world-wide and their different needs and skills. Users access the Web via slow or fast Internet connections and machines, they use different screen sizes, and they increasingly demand multi-lingual user interfaces which can be changed at run-time.
The authors and their fellow researchers at GMD's Institute for Applied Information Technology have implemented a Web-based groupware system, BSCW, which has been extensively used by a large number of people world-wide. The feed-back of our users during the last years revealed the aforementioned interface designer's dilemma: to design both effective and efficient user interfaces for different user groups and varying user needs. In this paper we describe how we tried to solve this dilemma by providing a tailorable user interface.
The research prototypes either exhibit relatively simple tailorability features (e.g., button and command key shortcuts to frequently used functionality), or require considerable programming skills of the tailoring user (e.g., the specification of production rules, or object classes). Applications range from generic desktops [MacLean et al. 1990] and e-mail clients [Terveen & Murray 1996] to knowledge-based design systems [Fischer & Girgensohn 1990] and toolkits for the specification and adaptation of complete co-operative applications [Malone et al. 1992]. Most prototypes were not exposed to real use, but were only evaluated in a lab setting.
The observation that the tailoring of a user interface is some sort of a programming task which requires certain programming skills of the tailoring user, gave rise to a classification of users, like the one into workers, tinkerers, and programmers of [MacLean et al. 1990]. While a programmer would be expected to be able to specify, for example, production rules, the tailorability features offered to (and used by) a worker would include only more simple adaptations of the user interface (cf. also [Page et al. 1996] for a recent user study of word processor tailoring). Thus the above classification of users also led to a useful classification of the tailorability features offered in a system.
When tailoring is some sort of "programming", it is immediately clear that more tailorability not only requires more user skills, but also more user efforts. What is sometimes neglected is the fact that more tailorability also requires considerably more system development efforts from the start. An example is the consequent separation of system functionality and system interface — a design principle which sounds trivial, but is rarely observed. Also, not all wishes for tailorability can be foreseen by system designers, but emerge with real users using the system. Therefore, system designers and programmers must be prepared to respond to user wishes, and the system must be easily extensible.
The increased cost of the development of tailorable systems may be the reason why so little tailorability made it into products. Here, we find mostly tailorability on the worker level regarding interface appearance and simple accelerators like colours, fonts, menus, command keys, button and tool bars. A notable exception on the programmer level is the tailoring of a Lotus Notes application; concerning the full "tailoring" of a Notes application, however, the meaning of the concept programmer must be taken more literally.
To conclude, we may remark that the problems connected with user interface tailorability are well understood, but that the solutions are either very simple or require skilled programmers; and tailorability of Web-based user interfaces in particular is relatively poor.
A workspace may contain different kinds of information, represented as information objects arranged in a hierarchical order. The objects may be of various types such as folders, URL links to Web pages, documents, graphics, spreadsheets, discussion forums or user specific waste baskets, address books and calendars. The system allows numerous operations — usually depending on the object type — that can be applied to objects, e.g., objects may be renamed, deleted and undeleted, documents may be put under version control, or users may add a comment to a discussion forum. Operations that have been carried out result in events, which are reported to the users by means of event icons so that they are aware of each other's activities in a workspace.
Being entirely based on Web technology, the user interface of the BSCW system is essentially a set of HTML pages. The BSCW server generates a HTML response page "on the fly" whenever users send a request from their Web browsers to the server, e.g., the request to list the contents of a folder. The response pages reflect the state of a workspace as seen from the viewpoint of an individual user and thus may vary from user to user.
Figure 1 shows a sample listing of the objects in a folder of a BSCW workspace. It also shows that the user interface of BSCW can be quite complex and may be difficult to understand for a novice user.
The folder in Fig. 1 contains a number of different objects below which are listed the operations (actions) such as "Modify", "Replace", "Edit" or "Convert" that can be applied to them. More operations applicable to the folder or to a selection of objects therein can be triggered by clicking on action buttons such as "Add Member", "Add Document", "Search", "Copy", "Delete" or "Archive".
Although the interface as shown in Fig. 1 looks quite complex, it should be noted that an experienced BSCW user usually has no difficulties with using the interface as field studies with the system have shown. In fact, users who need access to the full functionality of the system generally consider this complex interface quite efficient.
The BSCW system shall not be described here in more detail; an in-depth description of the system can be found in [Bentley et al. 1997].
When the first version of the BSCW system was publicly released, there was much less system functionality than today and therefore the user interface was still rather simple. When BSCW Version 2 — which increased the functionality significantly — was released in June 1996, we received comments from a number of users that they had encountered some problems in getting used to the system: for a novice user the interface was cluttered with "too many buttons", "too many kinds of objects" and "too many features". The number of such comments increased and became more urgent with the release of Version 3 in May 1997 when we again had added a number of new features. It should be noted that all features that have been built into the system in the meantime were inspired from feedback from our users who asked for such extensions. While some users felt that the user interface had become too complicated and cluttered, other users even enhanced the system by adding new features themselves (by extending the source code through CGI scripts).
A BSCW server basically is a set of Python CGI scripts. Thanks to the good support that Python provides for code modularization, we were able to strictly separate our software into object class implementations, operation handlers, user interface code modules and user interface templates. The user interface templates — a set of HTML template files — specify to a large extent the visual interface of the system for the users, i.e., by using this concept of user interface templates the actual user interface already is largely independent from the BSCW code kernel.
By replacing not only user interface template files, but also the user interface implementation modules, a programmer can — without a profound knowledge of the system — exchange the user interface. Furthermore, for moderately skilled Python programmers it is comparatively easy to modify or extend system functionality. This includes the modification (and possibly creation) of object classes, operation handlers and the user interface behaviour. We have, in fact, received feedback from users who had made quite significant modifications of the functionality and the user interface through extensions in the Python source code.
When installing a BSCW server, system administrators may customize the system by editing a set of central configuration files. This includes the definition of default access rights, the specification of the default system language, the selection of external applications like synchronous awareness tools or archiving and conversion toolkits, or the specification of naming conventions, e.g., for MIME types.
Administrators may also exchange icons (stored in a separate icons directory) and HTML template files mentioned in Section 4.1. Extension to other languages is straightforward and does not require any system or programming knowledge; in fact, all translations (currently French, Italian, Catalan and German) have been done by users of the system rather than by the BSCW project team. All user interface messages are stored as plain HTML and text template files in a language directory. Adding support for a different language requires creating a new language directory with translated versions of these HTML files.
Through modifications during the installation of a BSCW server, system administrators can modify the look and feel of the system to some extent to better fit their users' working culture. For all of these changes virtually no programming skills are needed. Since Python is an interpreted rather than a compiled language, most of these modifications can be also carried out by the administrator after a BSCW server has been set up. It is usually not necessary to shutdown and restart the BSCW server or its underlying Web server for the modifications to become effective.
It should be mentioned that — similar to modifications in the source code as described in the previous section — all of these settings affect the entire BSCW system and cannot be overwritten by individual end users.
Already the first BSCW version contained the concept of a preference profile for each user. Since users interact with a BSCW server with their normal Web browsers, the primary purpose of these preference profiles was initially to deal with the different functionality of Web browsers. For instance, users would like to specify whether or not they wanted to use Javascript enhancements or ActiveX enhancements in the HTML pages delivered by the BSCW server, or in what form (HTML or plain text) they want to receive system email messages. The user preference profiles were extended in later versions of the BSCW system. For example, when different language interfaces became available, users could select their preferred interface language at run-time. Furthermore, users could download the icons that are used in the BSCW interface to their local disk and then specify in their preferences that all icons were available locally and need not to be transferred from a BSCW server. For users connecting to a BSCW server via a slow connection, this may considerably improve the performance.
However, when the complaints about "too many buttons", "too many kinds of objects" and "too many features" increased with newer versions of the system (see Section 3.2), it became evident that we needed to provide facilities to make the user interface more configurable: simpler and "cleaner" for some users and with more functionality for others. In principle, tailorability as described in Sections 4.1 and 4.2 already serves these purposes. However, it is mainly directed to tinkerers and programmers and — a grave disadvantage — merely allows to tailor system-wide.
We first investigated the idea of providing pre-configured "novice", "advanced" and "expert" interfaces where users would initially use the "novice" interface, then switch to the "advanced" interface when they had gained some experience with the system, and eventually select the "expert" interface if they needed access to the full BSCW functionality. However, the selection of the respective features for a novice, advanced or expert user was not at all obvious. In fact, after discussions with several user groups and some investigation in their use of the BSCW system we concluded that such a selection was probably impossible. What was considered very basic functionality within one group of users was considered by others a rather rarely used feature which might only be needed by experts.
For example, the BSCW system provides a discussion feature similar to the discussion forums of the Internet newsgroups (except that discussions are subject to access control and to membership of BSCW workspaces). Some user groups almost never used this feature and classified it as an expert mode function, if required at all. Other user groups, however, considered the discussion feature most important in some particular work contexts. The latter user groups come from the SaN (Schulen ans Netz) initiatives which were established by the German Federal and State Governments to provide Internet and WWW access for all high schools in Germany. The SaN initiatives also plan to provide collaboration services to teachers and students, e.g., for the preparation of teaching material by teachers who may be dispersed throughout a state.
Several of the SaN initiatives have meanwhile decided to base their communication and collaboration services on BSCW. One particular application is a sort of bulletin board where students would be allowed to use BSCW's discussion feature anonymously (i.e., by-passing BSCW's normal authentication scheme). This should be the only feature that could be used by anonymous users, whereas registered users (usually teachers) would have access to a broader set of features but with a rather simple interface, at least for beginning users.
It should be noted that the requirements from this particular application address two different issues. The first issue, the need to provide only a very limited functionality for anonymous users (to prevent misbehaviour by possibly malicious students) is an issue of access rights. (Note: Since objects and actions to which a particular user does not have access are "filtered" from the user interface, as a side effect a user with very limited rights is automatically presented with a very simple interface.) We implemented a powerful and flexible access rights concept into the BSCW system which addresses these matters and many more. With these access rights features, BSCW is now better suited for more open work environments where a friendly and co-operative attitude among group members is not a prerequisite. The second issue, a simple interface for teachers new to the BSCW system, cannot be solved by restricting their access rights, but is a user interface issue solely. Eventually, the teachers may want access the full functionality but they need the opportunity to get used to it gradually.
We decided that tailorability of the interface should be possible on an individual basis and directly by the user, i.e., each user should be able to specify his or her own interface. User feed-back indicated essentially three areas of tailorability:
Our approach to provide the kind of configurability addressed in a and b is through an extension of the user preferences profile: users may specify which types of objects they would like to create and which operations shall appear at the interface in the various "places" they can visit in a BSCW workspace; more details on the implementation are given in the next section. When a new user registers with a BSCW server, he receives a default preferences profile as specified by the BSCW system administrator — this allows for a simple user interface for beginners.
In the BSCW source code, there is a file, config_ui.py, which basically contains a set of lists. Each list specifies for a "view" (e.g., Home, Folder, Waste, Bag or Address Book) and for the objects which might appear in this view (e.g., Document or URL) the operations which shall be accessible to the user (e.g., Get Info, Add Folder, Delete Object, Edit, Replace or Add Version), in short, which buttons should appear at the user interface. A (slightly simplified) excerpt from this file is shown in Fig. 2.
The strategy for implementing user specific interfaces basically consists of an extension to these lists in the interface configuration file: instead of having only a single set of lists which is valid for an entire BSCW server, there is a set of action lists for each user of the server. This set of lists is added to each user's preferences profile, with the initial (default) set of lists defined by the system administrator. Whenever a user requests a HTML page from the server, the actual content of the page is "filtered" against these settings in the user's preferences profile, similar to the filtering described in the previous paragraph. (It should be noted that the actual interface that a particular users perceives at a specific view also depends on the access rights which apply to the objects concerned).
Of course, users may modify these lists stored in their preferences profile. This is done in a HTML form which is shown in Fig. 3.
In the example of Fig. 3, the user chose a very simple interface: restricting the action buttons that are to appear in a folder's listing to merely six buttons and the action buttons in his Address Book, a personal set of links to other users, to a mere two buttons. The Preview button helps the user to get a sneak preview of what the button rows will actually look like at the user interface. After storing the preference profile, the user will get a quite different interface from that shown in Fig. 1.
Layout editor for end-users
A true tailorable use interface should also include end-user control
of the user interface layout. In our case, this would mean a HTML layout
editor for end users, cf. Section 4.3. Syntactically incorrect HTML templates
might result in malfunction of the system so that extensive consistency
checking would be needed; such a feature might also be too demanding for
most users. Still, this is an interesting field which we will keep in mind.
User-machine tailorable interface
One of the most appealing features of the WWW is its ubiquitousness
and its platform independence. BSCW as a Web add-on service both benefits
and suffers from this strength at the same time: when users access their
workspaces from WWW-Browsers on various machines, they may need to adjust
their user preferences to the actual machine they are working at (network
performance, screen size, colour or black and white screens etc., browser particularities).
We plan to support tailorabity for pairs of (user, machine). This depends,
of course, on the information that Web browsers convey to the server.
Adaptable event notification
In BSCW, user actions are kept as event objects by the system.
A notification mechanism indicates these events to the end-user via event
icons and state messages at the user interface. Currently, event icons
are unfiltered for users and objects. This approach results in (too) many
event icons which obscure the event information an end-user is really interested
in (e.g., "Who has read the new version of my paper?", "Are there any new
documents in a particular folder?", but: "I don't care what goes on in
that workspace, leave me alone."). In future, we plan to let end-users
filter event information on an object basis. In our Event Notification
Manager, a separate tool for PCs, this is already implemented [Horstmann & Bentley 1997].
Fischer, G., and Girgensohn, A., End-user modifiability in design environments, in: J.C. Chew and J. Whiteside (Eds.), CHI '90 Conference Proceedings, ACM, New York NY, 1990, pp. 183–192.
Horstmann, Th. and Bentley, R., Distributed
authoring on the Web with the BSCW Shared Workspace System, in: ACM
Standards View, 5(1), March 1997, ACM Press,
http://bscw.gmd.de/Papers/ACM-StandardsView/Author.html
MacLean, A., Carter, C., Lövstrand, L., and Moran, T., User-tailorable systems: Pressing the issues with buttons, in: J.C. Chew and J. Whiteside (Eds.), CHI '90 Conference Proceedings, ACM, New York NY, 1990, pp. 175–182.
Malone, Th., Lai, K.-Y., Fry, Ch., Experiments with Oval: A radically tailorable tool for cooperative work, in: J. Turner and R. Kraut (Eds.), CSCW '92 Conference Proceedings, Toronto, Canada, 1992, pp. 289–297.
Nielsen, J., User interface design for the WWW, in: S. Pemberton (Ed.), CHI '97 Electronic Proceedings: Tutorials, ACM, New York, NY, 1997, http://www.acm.org:82/sigs/sigchi/chi97/proceedings/tutorial/jn.htm
Page, S.R., Johnsgard, T.J., Albert, U., and Allen, C.P., User customization of a word processor, in: R. Bilger, S. Guest and M.J. Tauber (Eds.), CHI '96 Electronic Proceedings: Papers, ACM, New York, NY, 1997, http://www.acm.org:82/sigs/sigchi/chi96/proceedings/papers/Page/srp_txt.htm
Stallman, R., EMACS, the extensible, customizable,
self-documenting display editor, in: Proc. ACM SIGPLAN SIGOA Symposium
on Text Manipulation, Portland OR, 1981.
Terveen, L.G., and Murray, L.T., Helping users
program their personal agents, in: R. Bilger, S. Guest and M. J. Tauber (Eds.),
CHI '96 Electronic Proceedings: Papers, ACM, New York, NY, 1997,
http://www.acm.org:82/sigs/sigchi/chi96/proceedings/papers/Terveen/lgt_txt.htm
Williams, G., HyperCard: HyperCard extends the Macintosh user interface and makes everybody a programmer, Byte, 12: 109–117, Dec. 1987.
http://bscw.gmd.de/ BSCW Home Page
http://bscw.gmd.de/bscw/bscw.cgi/d420702/BSCW-Design.ps BSCW System Documentation
Wolfgang Appelt holds a Master's degree and a Ph.D. in mathematics, both from the University of Bonn. He has been working for GMD since 1971, initially in the area of numerical analysis. He later focussed on research in computer graphics and afterwards in document processing systems. Since 1995 he is the manager of the BSCW project.
Elke Hinrichs is a Research Staff Member at GMD. She received a Master's degree in mathematics from the University of Bonn in 1984. After working for IT industry in Germany and the USA for four years, she joined GMD's Institute for Applied Information Technology; she participated in several European projects in the area of Computer-Supported Cooperative Work. Since 1995 she is a member of the BSCW project team, where she focusses on user interface design and implementation.
Gerd Woetzel is a Senior Scientist at GMD's Institute for Applied Information Technology. Working for GMD since 1974, he received a Master's degree in computer science from the University of Bonn in 1977. Until 1980, his main interests were graphical data processing and pattern recognition. Afterwards, he worked on several German and European projects in the area of Computer-Supported Cooperative Work. Since 1995 he is a member of the BSCW project team, where he is responsible for the design and implementation of the BSCW kernel architecture.