CHI 96 Workshop: HCI and the Web, Position Papers
For the last 1 1/2 years some colleagues and I at NYNEX Science & Technology have used the Web to develop and deliver applications supporting collaborative work, namely Design Intent [2] and NYNEX Portholes [3]. We found that the Web is well-suited as a platform for such applications for several reasons. We also found many limitations that made it difficult for us to support the users as much as we wanted.
I am very interested in participating in the process of influencing the Web infrastructure so that the Web can become more user-centered. My experiences in developing applications on the Web might help identify areas that could use change.
It is important to respond quickly to user feedbacks by being able to rapidly add new features (or modify old ones) and to quickly distribute the new version to all users. In using the Web, all application code resides on a server. Using an interpreted language such as Perl lessens the time between making a change and being able to execute the new application.
User identification is needed for the creation and access of customized information for each user. We also use the HTTP server authentication feature for access control. In NYNEX Portholes, we restrict access to those who have Portholes cameras (and whose images therefore appear on the system). We did this to prevent Portholes from being used as a surveillance system -- only users who are willing to provide images may use the NYNEX Portholes viewer.
Our approach for exploring the kind of collaborative applications needed to support group communication has been to work with real project teams to identify communication needs and to support those needs using collaborative applications. In this setting, we need a development environment in which we can quickly prototype, test, and evolve the applications so that they can have an impact on the work processes that we are attempting to improve.
User interfaces can sometimes be improved by providing immediate application-dependent feedback. Examples include rotating objects or using rubber band lines in two-dimensional draw programs as the user drags the mouse. The former requires access to a great deal of application state and is probably not possible in Web applications because of the current heterogeneity of Web network links -- some links are simply too slow to permit the transmission of a great deal of application state quickly enough to provide usable feedback. However, if widgets can provide simple feedback like the rubber band example, then no network traffic would be generated because there is no need to access the application state.
In HTML, form information is only sent to the server after the user presses the submit button. If menu choices and other changes to form widgets could cause submits, we could implement forms where the widgets change (and appear and disappear) depending on context (see our Dynamic Forms application [1]). Having submits triggered by menu or radio button selections would also allow better interfaces for Web pages that display one of several variants of a section (e.g., one of several views of a weather map) as the variant displayed would change immediately upon menu or radio button selection. Having submits triggered by keystrokes (perhaps the space bar or carriage return as triggering on every single character would incur excessive network overhead) would allow interactive spell checkers, editors with automatic command completion, and limited on-the-fly text formatting.
Only the client can initiate an interaction with the server. This causes problems if the client needs to view information that changes from time to time. It would be best if the client could register with the server and then receive updates if the information it is displaying changes. Unfortunately, the HTTP model does not support server-initiated document updates. Netscape Navigator supports periodic polls by the client and so that one can get around some of the situations where server-initiated updates are desired. However, it would be preferable if polling would be less costly so that the client could poll in relatively short intervals (maybe once every 30 seconds compared to the five minute Portholes interval). Polling is costly because the entire contents of the URL are fetched on each poll and redisplayed even though none or just a small part may have changed.
Interactions between client and server are stateless. This means that each request by a client will find the server in exactly the same state. Some applications require multi-step interactions which need to maintain different states between interactions. In the HTTP model, modal interactions are only possible if the client keeps track of the state (as part of the current document) and passes it to the server with every request.
HTML provides limited control over the layout of a document. This prevents the designer from arranging a form in a way suitable for an individual application. Widgets can only be placed in a text flow and geometric constraints provided by user interface toolkits can only be used to a very limited degree. HTML tables can be used to work around some of these limitations. Even the layout of text is much less flexible than standard word processors.
Web interactions are somewhat asymmetric. Users can download and view a rich set of media types but are restricted by the forms facility to responses where they pick one of several alternatives or enter text. Some of this asymmetry can be remedied by using clever application-specific textual description languages such as HTML for hypertext entry. However our experience has been that many users are unwilling to learn these languages. Our users want to use their favorite applications to create documents to be processed by our collaborative applications. For example, one of the Design Intent users preferred to use Microsoft Word to create meeting notes. Other people would like to upload images and Quicktime or MPEG videos without having to learn about FTP, about our server directory structure and about HTML.
1. A. Girgensohn, B. Zimmermann, A. Lee, B. Burns, and M. E. Atwood, Dynamic Forms: An Enhanced Interaction Abstraction Based on Forms. In Proceedings of INTERACT'95: Fifth IFIP Conference on Human-Computer Interaction, London: Chapman & Hall, pp. 362-367, 1995.
2. M. E. Atwood, B. Burns, D. Gairing, A. Girgensohn, A. Lee, T. Turner, S. Alteras-Webb, and B. Zimmermann, Facilitating Communication in Software Development. In Symposium on Designing Interactive Systems, New York: ACM, pp. 65-73, 1995.
3. A. Girgensohn, A. Lee, and K. Schlueter, Experiences in Developing Collaborative Applications Using the World Wide Web "Shell". In Hypertext'96 Proceedings, 1996 (in press).
CHI 96 Workshop: HCI and the Web, Position Papers