# Presentation: 247770

## Issues in Personalizing Shared Ubiquitous Devices

- Jonathan Trevor
- David M. Hilbert
- Bill N. Schilit

- _[trevor@fxpal.com](mailto:trevor@fxpal.com)_
- _[hilbert@fxpal.com](mailto:hilbert@fxpal.com)__ _
- _[bill.schilit@intel.com](mailto:bill.schilit@intel.com)__ _

## Shared public devices everywhere

**Notes:**
Anonymous interfaces

## Personalization on the Web

- Apply similar techniques to *shared everyday devices*

**Notes:**
interest in applying known techniques to shared everyday devices

## The PIPs system

- Personal Interaction Points (PIPs)
- System for personalizing shared pervasive devices
- Starting point: integrate personal computer file access with a shared device’s functions
- Design to support our current work practice in our laboratory

**Notes:**
Could build and deploy a system...
but design decisions are made virtually every step of the way
How can we know what “might have been”?
Our first design decision:
Where is the best place for delivering such personalization?
Integrate with existing UI (embedded)
Remote UI carried by users (portable)

As we developed the underlying system functionality of providing a file history at shared devices, we began to consider how best to evaluate the resulting system. Although we wanted to add a useful personalization system to our workplace, we were also willing to learn from and then throw away the first system, so we could build a better second system. This led us to focus on better understanding the design alternatives as well as the deployment situations. These are described below.

We consciously tried to support and integrate the day-to-day work practices of our laboratory to increase the likelihood our system would actually be used 

## A Comparative Evaluation

- Evaluating ubiquitous systems is hard
- Basic mismatch between traditional evaluation techniques and the needs posed by ubiquitous systems
- systems need to be evaluated in a variety of complex real world environments
- Solutions include techniques adapted from the social sciences
- Anthropology, ethnomethodology ...
- We wanted to perform a comparative evaluation similar to laboratory experiments
- Want to observe the effects of our design decisions in relatively unconstrained, real world use

**Notes:**
that cannot be easily modeled, simulated, measured, or controlled

## Comparative evaluation process

- Design with alternatives
- Pick a design decision to vary and build prototypes
- Same basic underlying functionality
- Simple but compelling
- Vary deployment situations
- Deploy prototypes in varied situations
- Compare and contrast
- Collect data to populate a matrix of observations across design alternatives and varied situations
- Beyond designing for use  designing for evaluation

**Notes:**

Pick a design decision to vary and build prototypes to embody multiple design alternatives

See if observed effects generalize

See what causes observed effects

Variants should provide the same basic underlying functionality
Underlying functionality should be as simple as possible but remain compelling enough to produce real usage

So we adopted a 
1 (or configurations of an existing system)
3 Qualitative on quantitative
3a Try to determine whether observed effects vary depending on the design alternatives, the varied situations, or both.

## Video

**Notes:**
Before going into more detail regarding our evaluation, here’s a video to give you an idea of how the system works

## Design alternatives

**embedded versus portable interfaces**

## The embedded interface

- RFID card login (or browser authentication)
- UI tailored to device being controlled
- Shortcuts resolved from user’s desktop

## The portable interface

- Users pick PIP, browser authentication
- Laptop UI similar to embedded, palmtop UI smaller
- Kept UI as similar as possible to embedded

**Notes:**
Additional “remote control” interface

## Varied situations

**presentations, brainstorming, and printing**

## Design and Implementation

- Each PIP device runs a web server
- ASP scripts deliver personal documents to streamline use of device features
- No software installed on user’s PCs

## Deployment and Observations

- Released over a year ago
- 2 PIPs still in active use today
- Presentation PIP used for over 1⁄2 presentations
- Brainstorm PIP used for nearly all document access in Idea Room
- Printer PIP infrequently used
- Qualitative feedback from adopters and non-adopters
- Observational, solicited and unsolicited feedback, interviews
- Quantitative data from Web logs
- Comparative prototyping methodology illuminated five key issues in the design of personalized ubiquitous systems

**Notes:**
Staggered releases
Beta testers of embedded version (early adopters)
Main release (embedded)
Subsequent portable release (both)

## Usability

**Usability**

- Separation of UI from shared device caused user confusion

- Easier to pick links, less scrolling, less prone to errors

- Usability of portable UI reduced when task included editing

**Notes:**
Usability includes learnability, efficiency, memorability, error handling, and user satisfaction
Assumed that usability would decrease with portability

## Utility

- New mode of presentation, attracted new users

- Remote control less important due to small size of room

**Notes:**
Utility is functionality that users perceive to be useful
Methodology strived to keep these the same
Expected no differences

## Availability

**Availability**

- Users forget to bring their portable devices

- Portable power sources and networking less reliable

- More available in general – always there, always on

**Notes:**
Availability is extent to which system is functioning properly when you need it
Expected availability to decrease with portability

## Trust

- Non-users suggested people, at least in Japan, might feel more comfortable accessing their personal documents through their cell-phone

**Notes:**
Trust is extent to which users believe their personal data is safe from corruption or misuse
Our system accesses users’ documents (the originals, not copies) containing potentially sensitive information
Thought trust would be a critical issue.
Very few questions on security of the system
evaluated within a small and trusted environment: namely our internal, firewall-protected corporate network of approximately 30 users

## Privacy

**Privacy**

- Privacy not an issue since files shown on private display

- Privacy not an issue; informal setting; close colleagues

- Privacy an issue; formal setting and activities;

- Privacy not an issue; one-shot interaction; few people around

**Notes:**
Privacy is extent to which users are comfortable that sensitive information will not be revealed to others
System displays interfaces derived from a user’s recent file activities
shows what a user has been doing in his or her private office
assumed that portable interfaces would provide users a greater sense of privacy

## Highlights

**Usability:**
- Embedded easier to use in general, especially for complex tasks
- Portable separation of UI from device can confuse new users
**Utility:**
- Portable UI provided new utility (remote control) in conference room
**Availability:**
- Embedded interfaces more reliable
**Trust:**
- Not an issue in corporate intranets
- Portable may be more trusted in public places
**Privacy:**
- Portable inherently more private
- But less important in informal settings, and for quick tasks

**Notes:**
Table here, talk back to comparative methodology

## Methodology issues

- Technical effort.
- Social effort.
- Design decisions not atomic.
- Varied situations not atomic.
- Complicated analysis.
- Generalization.

## Conclusions

- Comparative prototypes methodology
- a framework for better understanding a ubiquitous system
- promotes designing for evaluation
- can prevent “over-design” and focus on particular problem areas for subsequent iterations
- PIPs was designed using this methodology
- compares embedded vs. portable solutions in several situations
- successful system in its own right
- reinforced design intuitions
- must carefully consider the variety of situations and tasks
- small differences produced very different results
- produced a matrix of observations to think about ubiquitous computing design

**Notes:**
goes beyond designing for use and