[ Home | Prototype | Table of Contents | Related Work | Members | Unresolved Issues] |
Note: Green writing is stuff that needs more work. Brown writing is papers that I read but didn't seem to be essential parts of this bibliography. Red writing is stuff done by other people that is either equivalent to stuff we want to do, or goes even a step farther (Ie, we should do it).
The three biggest differences between this system and our own:
This system is very similar to the above system, but accessible from any machine with a web browser, cross platform. Such systems are truly globally accessible. The migrating applications are displayed within the web browser. In terms of security, they point out that the packets containing bitmap changes to the interface (rectangles are sent as they change) might contain sensitive material. They propose an encryption system to get around this. If you log in to one machine, and then switch to another, the initial system is unposted. They also have integrated this with the badges, so some of that can be done automatically.
Need to check this out. It appears to allow users to move individual X apps instead of whole sessions.
Need to check this out. What issues do they address that might be relevant to us?
Allows users to run Windows applications remotely. Could this be useful to us? I'm downloading it to check out ...
Read it! I'm printing it out right now ...
Basically, what it supports is remote execution over the web, not teleporting. It turns out that they didn't actually implement anything. A summer student worked on some sample application that's pictured at the back of the paper, but they don't talk about it at all. I haven't been able to find out if they took it further or not.
Neither of the first two kiosk systems really go much beyond information delivery. In general, ours is much more functional. This is possible in part because we have a trusted group of users. visitors to FX Pal are unlikely to see more of the system than is available in any of the kiosks below. The third paper goes beyond this, however, by supporting public opinion polling and other interactive tasks. How does their polling compare to our suggestion boxes? One aspect of our system which deals mostly with information presentation: the directory. How does our directory system compare to standard kiosk directories? Two things stand out about our directory/map system:
The focus of this paper is on rapid interface developement system. The setting is the developement of a messaging kiosk system used at the 1984 Summer Olympics. The system supported 12 different languages, and provided three seperate interfaces (depending on which user group you were part of):
The system was audio-based, and required touchtone at the kiosks. The 2nd user group (above) needed nothing more than a telephone to access it. I'm trying to get my hands on a related paper which discusses the system in more depth: need to get Communications of the ACM 30, 9 (Sept 1987), pages 758-769
More depth about previous system. the 2,3 and 4 th pages are missing but oh well :(.
The problem they were trying to solve: 10,000 athletes, none of whom had personal telephone numbers in the Olympic Village. Lots of people (friends, family, & others) need/want to contact them. Most are novice computer users. Have to design it right before testing (Olympics only last four weeks...). So they designed a kiosk-based voice mail system. People not living in the olympic village would call an operator who would hook them up to the OMS system at the stage where all they had to do was leave a message.
For visibility purposes, large standing kiosks were placed throughout the Olympic Village. The kiosks contained a phone, a visual display with the names of Olympians who had new messages, signs in French and English, and user guides in 12 languages. In addition, it had a display showing a mime demonstrating how to use OMS, and an electronic bulletin board displaying news items of interest.
If Olympians had trouble using the system, they could press a help button and reach an operator who could enter commands into the system for the olympian with them both on the line. The system also tried to detect when an olympian was having a problem. Each prompt had a timeout, and if the olympian had not responded appropriately by then, it would play a help message.
For testing purposes, the designers built huge cardboard kiosks in the front entryway of their lab. They got lots of user comments this way. As they changed their design, they updated the public version. Should we be doing this kind of thing?
In general, this was a very interesting paper which highlighted the way in which a small number of people could develope a very successful system in a short amount of time.
Case study of kiosk design, testing, and results (via trace data). The kiosk was a multimedia browsing system containing information relevant to conference and surroundings (city). It functioned solely as an information provider, it could not perform tasks or accept input. It provided the following 4 information services:
Several things were learned from the user studies: always have a way home. In (2) it helps to provide shortcuts to each variety of search, as well as next/previous arrows. The interface shown first tends to be the one users stick with ("in more than half the cases, users made their selections from the screen they were shown first." (p. 455)). Also, they found trace data to be *very* useful.
Same system as is described in previous paper, with more detail about parts 2 & 3 (above). In order to capture user's point of view, there were no written specifications. Instead used sketches and mockups. The paper discusses stages in the design process.
This paper is about the design tool used for EXPO '92 's visitor information system. The kiosk system was built for short interactions, with no learning curve. It supported several different languages. This tool goes beyond the standard information delivery kiosk by providing "electronic messaging, automated restaurant reservations, public opinion polling, and locators for lost family members." Navigation was done through maps. Also, they have a finger painting system, but I'm not sure if it was used for messaging .... In addition, the kiosk supports several different languages. The paper says dissapointingly little about the kiosk, focussing instead on the interface issues (appropraite, since the paper is about an interface design tool). Unfortunately, since it was written before EXPO '92, it didn't have references to a paper focussing on the EXPO '92 system.
We really need to find such a paper in order to find out more about the public polling application? How does it compare to our suggestion boxes?
This is basically a how-to paper on kiosk design and implementation. It discusses types of kiosks, types of hardware available (eg touch screen variations, etc), what's important in the design process (eg user profile, location, operating systems, etc), manufacturers, and connectivity (among other subjects). Very useful for a first-time kiosk designer.
Talks about a call-up newspaper service which provides two newspapers per day to blind people. Used a reading program. Not very applicable ...
hypertext-based kiosks are defined by following characteristics (say the authors):
challenge:
study was done on CHI '89 info booth and use of attendee yearbook. They focus on search. They measured time taken to answer questions in a pre-planned study. Hierarchical searching worked best in their system. Conclusion: it worked best because it matched the search pattern best.
I looked into this area of UI design because our system clearly adapts to altering conditions in it's environment, and to the presence of a user. It would be interesting to explore adaptive systems furthur, but as there is only so much time available to me, I will leave it for now.
A taxonomy of Adaptive User Interfaces. "[Adaptive UIs] are designed to tailor a system's interactive behavior with consideration of both individual needs of human users and altering conditions within an application environment." Luckily for us, there is a beautiful gap here ... the taxonomy does not consider altering conditions outside the application environment (ie in the room where the computer sits) .... :-)
The authors discuss several stages in adaption: 1) initiative (decision to make a change) 2) proposal (what are the alternatives) 3) decision (choose one) 4) execution (do it). "Agents" performing these tasks might include system designer, administrator, local expert, user, or the system itself.
The taxonomy is used to classify existing systems and prototypes, but does not describe any of them in sufficient detail to understand which ones might be relevant.
not very informative, just your basic hci do evaluation and keep track of all the conflicting goals in adaptive interfaces type thing....
Our UI will be based on an office metaphor (specifically, the Directory part of the system), so we decided to look up some other papers about office (or room) metaphors that went beyond the desktop. Is the directory system similar to the rooms or office metaphors? I'm not sure how much the directory system differs from the following papers, but one big difference in our overall system is that we support mobile users, public terminals, and our hierarchy of rooms and other objects corresponds to real rooms and objects in a real office building.
The Office metaphor people really implemented almost everything we've talked about in once sense or another -- messaging, topical discussions, public information. Of course, it's all only accessible "virtually" through the desktop workstation, but still ...
This paper discusses a rooms metaphor for a computer interface. These people are trying to solve the problem that a computer monitor is so much smaller than a desk or other space where we normally spread out documents. The idea is to support multiple virtual workspaces using a rooms metapher. In order to keep people from getting lost, they provide an overview window. In addition, each room can have doors to other rooms. Also, there is always a "back door" to wherever you came from. Documents can be present in more than one room simultaneously. They've got some interesting UI ideas not specific to the metaphor such as:
Our directory system differs in several ways from the rooms system:
The office metaphor presented in this paper is used to facilitate group communication and collaboration (information being the main object of group commerce). In this system too, the concept of a room becomes central in the system. Each individual has his own room (private office) which is his normal working environment (p. 319). In addition there are public rooms, such a conference room, library, coffee room, and hallway. Each of these public rooms support different tasks that are relevant to the room. These rooms, btw, have no literal correspondance to the office in which the users are physically situated (unlike PALplates). This means, among other things, it can be reorganized by each individual user according to their needs.
Aside from the rooms described above, all other rooms are offices (which can be shared by groups, or private to individuals). One application common to most group offices is a "new link container" where any links added to any rooms the container knows about are also added to the container. (nice ... might this be of use to us?).
Messaging is supported both to people and conferences. This can be done from anywhere.
There is an overview map which displays rooms and the links between them. Mouse selection can move one between rooms directly. You can also click on a hallway and travel that path. The browser can also be used to get information about rooms, and some of that is depicted visualy (ie, whether or not the door is open).
The system is implemented as a collection of objects .... new instances are created using a class hierarchy browser, and properties are filled in using a special editor. (this is how they do tailoring, etc by users and administrators).
not implemented, but suggested (actually, it's not clear that any of the above was implemented either): Agents can be assigned to tasks dependant on object properties ... communication structures can be used to control the exchange of messages (eg used in a voting systemin COSMOS -- next paper).... shared whiteboard .... group workspace (like virtual workspace, but shared)
This system differs from ours mostly in it's purpose: they wish to support group and individual work, to use a metaphor for organizing objects. All of these things are accessed from personal workstations in private offices. There is no correspondance to real structures, and no public terminals.
Supports Communication, Cooperation, and Awareness both synchronously & asynchronously. Modelled after an office metaphor. Sticks to only rooms, people desks, and documents in it's object model. Can also make stick-on notes and attach them to objects in the virtual office. They use symbolic copies of documents ...
Map -based access to a database and communications services within a group of workers. They use icons on the map to represent virtual objects. Can control amount of information on the map, but can't zoom. Can annotate the map. Changes are immediatly seen by all users. Used manual effort to make the floor plan appropriately detailed. Database is connected to a real system ...
Ubiquitous computing & Mobile computing at the heart of what inspired us to build PALplates. Ubiquitous computing, the idea of having computers everywhere, helped spark the idea of having "computers where you need them". Mobile computing (including portable computers, and mobile applications) has developed into the idea of providing applications at the place at which (mobile) users need them -- "applications where you need them".
The papers below include an introduction to the area of ubiquitous computing, and some specific applications in mobile/ubiquitous computing which address the problem of location-relevant interfaces and information (eg, the PARCtab system).
Overview of ubiquitous computing. Computers everywhere. One major point: knowledge of location is essential and extremely useful. I didn't see anything in here about wall mounted displays ....
More of the same, but from a CS perspective... aiming for invisible technology. Very mobile computing. The "Responsive Environment" project actually hides computers in the walls. They customize temperature, etc to the people who are present.
"The PARCTab system integrates a palm-sized mobile computer into an office network." This paper talks about the hardware and UI design for PARCTab including problems specific to small computers. One design idea that would be useful to us: Have the buttons for different applications also present summary information if possible (eg a weather button might have a cloud or sun, a notes button might have a number indicating number of notes, etc. (p. 36).
Two of the most popular applications was the (location-based) file browser and email reader. Both of these provided on-the-fly anywhere access to personal user data. Although we hope to support such tasks in PALplates, they are not the focus of the system. It is unlikely that users will want to perform the same tasks at wall mounted, public displays, as they perform on their lap in a meeting or while drinking coffee.
ParcTAB supported voting, finding objects with properties in locations (at the low/system level) ... users could create votes at their workstations, and votes could be associated with locations. Much less casual/easy than our suggestion box ... ParcTAB also had a file browser keyed to location. In addition, at the systems level, it supported something very similar to what we're aiming out: finding objects sharing properties with the current location. (see the next bibliography entry).
Section 2.3 of this dissertation talks about the system structure for supporting context-aware computing. Supported tasks include
For example, location-related files could be browsed. Messages left at a location would be detected. Nearby devices that might be useful would be noticed. Objects could be searched for based on a set of constraints (such as their nearness to a specific location). Other applications are also mentioned.
The dissertation goes on to talk about different types of information that a system should keep track of, including environmental info and user preferences. This information is mostly stored as properties of objects. Notification of changes in object properties should be dispersed and cause the interface to adapt appropriately.
This mobile (computer moves with user) system reacts to the individual's changes in context. The PARCTab has knowledge of where you are, who you are with, and what other objects are nearby. It uses "proximate selection." The interface is reconfigured depending on context.
Both PARCTab and PALplate aim to customize the computing experience according to the user's identity, the location of interaction, and the surrounding environment. Mobile systems like PARCTab have a single user that is changing the location of interaction making it necessary for some way of determining the device's current location. Stationay systems like PALplate have a fixed, known location, but multiple users interact, making it necessary for some way of determining the user's identity (or just preferences). A question which we may be able to shed some light on is: what are the advantages and disadvantages of each type of system and why would you choose one over the other?
We might also want to look into how our system fits into the categorization presented in the paper (proximate selection, automatic contextual reconfiguration, contextual information and commands, and context-triggered actions). The first is clearly applicable to our system, the last probably not. As a group, are they a complete categorization, or does our system also fall outside their boundaries?
In terms of philosophy, PALplates differs in that the computer is no longer mobile. This gets around lots of connectivity problems, among other things.
Examples:
Scoreboards were public displays which changed to display information customized for people walking by. This was done by integrating wall-mounted ParcPADs with the active badge system. ParcPADs are currently mounted on the walls all over Xerox Parc, but there is no software to support them. In addition, their hardware is pretty flakey, they run XWindows, and they require pen input.
Muds are generally used for collaboration. They were originally games but are beginning to be used for serious applications in several places (see muds grow up) including sysadmining (collaboration within an office place) (see MUDDS as Systems Tools) and research (collaboratino within a distributed community) (see MediaMOO)
MUDs for sysadmining: fill useful communication space between email and newsgroups.
Epistemology and Learning group, MIT Media Lab. On the web. It's an overview of the MediaMOO project (a mud for a community of researchers interested in a common topic)
Describes a system for window-based user interfaces to objects in the mud. Only high-level events are propogated across the network. This allows shared access to tools (can multicast events). Jupiter can also send audio and video across the network.
One current system is Astro-VR (for astronomy research). Another is Jupier. None of these are very tied to the real physical structure of the building, although the paper does talk about ways of making this connection. Generally are meant to support long-distance collaboration from the desktop.
Only have one paper on this topic ... but maybe we should find more ... Anyway, it brings up some good points about office workers away from their desks.
They found that "work involved far more mobility than we had envisaged. Most of this was not long distance, but rather local mobility; simply walking between rooms or buildings at a local site." They quote one interviewee as saying "I make my way between here and the scanning station, the printer and the [model] shop for the most part." We have observed this kind of constant motion ourselves. In particular the identified two motivations for leaving the desk:
In particular, they observed that two subjects spent 13% and 10% of their time in the office, split up into smaller chunks (divided by time out of the office). They observed that "Time spent at the PC reading and sending email was minimal compared to the amount of time dedicated to building awareness of ongoing activities through face-to-face encounters." They also observed that "mobility propagates further mobility." (eg people looking for eachother).
They then talk about solutions which could support office workers without confining them to their desktops (in the context of CSCW -- long distance collaboration in mind). They mention Portable Devices, Distribudet Services (ie, "services which allow people to use existing machines while they move about" ... talk about an Apple screen saver which has some things in common with what we might be doing with PALplates but still displays conifined to *someones* desktop ... Then mention extending this software to portable devices (and I say, what about *public* devices?). They also talk about Computer Mediated Communication and Supporting Administrative and Coordination Roles (eg scheduling technology).