Effectiveness and efficiency: the need for tailorable user interfaces on the Web

Wolfgang Appelt, Elke Hinrichs and Gerd Woetzel

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

This paper discusses the need for tailorable user interfaces, in particular for Web-based systems. We argue that user interfaces need to be configurable by the end users to match their skills and work requirements. We then describe what configurability has been induced by user feed-back and how tailorability for various degrees of user skills was integrated and implemented in the BSCW Shared Workspace System, a Web-based groupware tool.

User interface; Tailorability; Groupware; Multilinguality

1. The problem

User interface designers in general face the following problem: the amount of information and the number of system features tend to explode during the lifetime of a system while the user interface design possibilities of today's desktop environments remain limited. This is even more so for designers of interactive systems on the Web who have to cope with the limited features of HTML and HTTP: HTML is not rich enough for a flexible user interface design (and was not meant to be) and HTTP is not well enough suited for interactive systems. While the more prominent pitfalls of Web user interface design are by now a more or less universally acknowledged truth ([Nielsen 1997] gives a check-list of deadly sins to be avoided in an interface for the Web), the necessity to interact with a multitude of structurally and functionally complex data still puts the interface designer in some sort of a dilemma.

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.

2. Some solutions: state of the art in interface tailorability

The interface of a computer system is called tailorable when users can adapt the interface (and the system behind the interface) to their particular situation and their particular needs. The most well-known computer systems that demonstrate user tailorability are the EMACS editor [Stallman 1981], the HyperCard programming system for the Macintosh [Williams & Gregg 1987], and spreadsheet applications in general. User interface tailorability (configurability, adaptability, and customizability are used synonymously) has been a prominent topic of HCI (Human-Computer-Interaction) research in the 1980s and early 1990s. This research has produced a number of interesting research prototypes, some categorizations of tailorability and of the types of users that would (or could) use the tailorability tools offered, and some guide-lines for the design of systems that are meant to incorporate some degree of tailorability.

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.

3. BSCW — Basic Support for Cooperative Work

3.1. The system and its user interface

The BSCW system is a Web-based groupware system around the shared workspace metaphor. Shared workspaces are established by groups of people to organize and coordinate their work. A BSCW server (a standard Web server extended by the BSCW functionality through the Common Gateway Interface) manages a number of shared workspaces — repositories for shared information, accessible to the members of a group via any normal Web browser using the user name/password authentication scheme. In general, a BSCW server manages workspaces for different groups, and users may be members of several workspaces (e.g., one workspace corresponding to each project a user is involved in).

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.

Fig. 1. User view into a BSCW Shared Workspace.

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].

3.2. User feed-back

The BSCW system has been publicly available at http://bscw.gmd.de/ since October 1995. People are invited to register and create their workspaces on the BSCW server free of charge. The server code (and more) is available and offered free of charge for non-commercial use. As of November 1997, about 6000 users have registered on GMD's public BSCW server and the server software for local installation has been downloaded over 3000 times. We estimate that the active BSCW user community comprises some ten thousand people. While doubtlessly some of them just playfully explore the system, a considerable number of users with diverse backgrounds — including computer scientists, researchers and managers with various degrees of computer literacy, teachers and students — use BSCW for real work. We have been receiving massive feed-back via e-mail (more than 4000 messages until now) and via direct user observation in field tests carried out in the CoopWWW project which was funded by the European Commission.

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).

4. Tailorability of the BSCW user interface

Tailorability of the BSCW user interface has been  part of the BSCW design goals from the very beginning although it started with only rudimentary configurability.  As the system functionality increased, more and more features had been made tailorable, mostly due to user requirements. In this section, we will outline some of these tailorable items as they have been implemented. They are meant for people with different skill levels which have been categorized by [MacLean et al. 1990] as programmers, tinkerers and workers, cf. Section 2.

4.1. Tailorability for programmers

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.

4.2. Tailorability for tinkerers

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.

4.3. Tailorability for workers

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:

  1. Visibility of the different object types of the system (i.e., which types of objects are presented to users and accessible for possible interaction);
  2. Visibility of the actions that can be performed (i.e., which operations on objects are offered to users);
  3. Layout of the user interface (i.e., how are the objects arranged at the user interface).
We felt that a and b were the most important issues for our users. If they could prevent some object types and actions from appearing at the interface, they would immediately receive a simpler interface that would be more easily comprehended. In principle, support for customization of the general layout would also be feasible, but it would mean the provision of a sophisticated HTML template editor. It is questionable if the development of such a tool would be worth the effort since most users would probably not have (or be prepared to acquire) the expertise to use it successfully.

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.

5. Implementation and user interface

This section briefly describes how the user specific interface as described in Section 4.3 has been implemented. It does not address the features described in Sections 4.1 and 4.2. For more details, see the system developers' documentation.

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 views basically correspond to the HTML template pages mentioned  in Section 4.1. For example, when a user requests to see a listing of a folder, the BSCW servers creates a HTML page which is derived from a HTML template page for a folder listing. The content of template pages is filtered through the specifications in the interface configuration file. If actions are removed from particular user interface action lists in the configuration file, these actions also get removed from the corresponding HTML response pages and therefore the respective buttons will not appear in the actual interface as presented by the user's browser.

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.

Fig. 3. Modification of the user interface.

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.

6. Outlook and future plans

Workspace-wide tailorability
We considered to allow tailorability not only system-wide or end-user-related, but also workspace-related or even object-related. This opens up interesting possibilities: in one workspace one could invite novice users and present them with an simple interface, another workspace could serve the sole purpose of exchanging informal notes (article in threaded discussions) and thus would filter out the other operations, and many other examples. Workspaces that could be tailored to their internal use would be much easier and more efficient to use. However, conflicts with interface decisions made by individual users inevitably arise: what if a user chose a full-fledged user interface to himself, and then becomes a member of one of the above workspaces?
In BSCW, workspaces within workspaces are part of the concept. While one group of workspace members chose a particular interface, the other workspace user group decides on a different user interface for their workspace; a conflict arises which cannot be solved satisfactorily without involving the end users again.

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].

8. Conclusion

We have discussed the need for user specific interfaces in general and for Web sites in particular and have described how this is implemented in the BSCW Shared Workspace System. We believe that the general approach we have presented here is not limited to the BSCW system but can also be applied to other Web applications, in particular to those where users have to identify themselves. In these cases, a Web site could establish — with assistance from and controlled by the individual users — user preference profiles similar to the one we use in BSCW and use these profiles to provide customized information, e.g.,  to "filter out" information that the users do not want.


Bentley, R., Appelt, W., Busbach. U., Hinrichs, E., Kerr, D., Sikkel, S., Trevor, J. and Woetzel, G., Basic support for cooperative work on the World Wide Web, in: International Journal of Human-Computer Studies 46(6): 827–846, 1997 (Special Issue on Innovative Applications of the World Wide Web),

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,

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://www.python.org Python Home Page

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.