[ Home | Prototype | Table of Contents | Related Work | Members | Unresolved Issues]

Directory Information

User group: Visitor [1], Staff [2,3], Repairman [3], Fireman [3]

Location: Everywhere [1,2], Printer/Photocopier/FAX Room [3]

Scenarios

1. You're visiting FX Pal's parent company in Japan, and need to find your way to the office of the researcher who's hosting you. You walk up to the conveniently placed kiosk in the lobby, and select his name from a list of employees. You print out the map returned from your query and use it to navigate the unfamiliar building.
2. You're standing <in a meeting, in front of Joe's door> and want to find out where Joe is. You select his name from a list of employees, and ask for his location. The screen prompts you for authentication, and when it discovers you're his <wife, best friend, ...>, immediately returns a map with his location highlighted ...
3. You need to make slides, but you don't know where the transparancies are kept. You walk up ta PALplate and select "transparancies" from a list of objects relevant to your location. It returns a map of the room you're in, with the location of the transparancies highlighted.

Interface

The directory is almost the equivalent of the Macintosh "Finder". One main difference: it is based on an Office metaphor instead of a desktop metaphor. It is one view (spatial) into the database of objects, people, and locations representing FX Palo Alto.

The directories usefulness is in finding fixed objects. Without active badges or some other tracking system, it can't be of use in finding moving objects (eg people). Rather than make inferences which could easily be wrong, it leaves that up to the user.

Once a search is performed (on some combination of properties -- objects, locations, and people), the directory returns a map of the smallest container in which both the user and the located object reside (maps are built recursively from database information), along with a drawn path between them. One example -- you could search for "Fax Machine" and the map would return the location of all <or the nearest?> fax machines.

The map is active --

• by clicking on other PALplates, the user can bring up interfaces relevant to their location and context. (this is one form of teleporting).
• If the user is searching for a person, and the map can't find them, it will tell you where her office is instead. If she's left a note tagged with the "directory" property, and you have permissions to view it, a stick-it with handwriting will appear on the map. Clicking on it will allow you to view the note.

Issues

Privacy

It's important to identify when to show someone's location, and when not to. This can be done partially based on authentication, but it might be important to consider using other inforamiton as well. For example, even if I put you in my "friends" list, I might still not want the computer to tell you when I'm in the bathroom. Instead, it should say that I'll be back soon. This probably isn't too much of an issue since our interface will locate people either based on the last kiosk at which they authenticated themselves, or based on data they entered before leaving their office. In either case, a binary differentiation (eg friends, strangers) is probably good enough for deciding when to disclose location.

Hardware

???

Software

Database of office kiosk/resident pairs. Database of all kiosks.

Network

The application needs to be able to query other kiosks in it's attempts to locate someone. It also needs to be able to query the specific kiosk at the office of the person being searched for, to ask if s/he left a location pointer.

...

Copyright © 1996 FX Palo Alto Laboratory, Inc. For problems or questions regarding this web contact Jen Mankoff. Last updated June 17, 1996.