August 2003 93

I N V I S I B L E C O M P U T I N G

D esign is about finding solu-tions. Unfortunately, notknowing how others previ-ously applied a solution orwhy they did things a certain

way makes it difficult to reuse priordesign knowledge. Consequently,designers—whether they are softwareengineers, architects, or Web design-ers—often end up having to reinventthe wheel.

Because they are neither too generalnor too specific, design patterns offera solution to the difficult problem ofreusing prior design knowledge. Theyare written to be flexible enough forreuse in many situations, and design-ers can use them to identify and pro-pose solutions to recurring problems.We propose that such patterns alsooffer an effective way to communicatesolutions to ubiquitous computingdesign problems.

EVOLUTION OF DESIGN PATTERNS Design patterns emerged from the

field of architecture in the 1970s withthe work of Christopher Alexander andhis colleagues at the University ofCalifornia, Berkeley. In the still widelyread classic A Pattern Language:Towns, Building, Construction (OxfordUniv. Press, 1977), they proposed a setof 253 formal patterns not only as atool for architects, but as a way for allstakeholders in the design process,

including the client, to communicateabout a given project.

Sample architectural design pattern

The Beer Hall pattern provides oneexample of Alexander’s distinctiveapproach to design. This patternaddresses the following problem:

Where can people sing and drink,and shout and drink, and let go oftheir sorrows?

The solution is:

Somewhere in the community atleast one big place where a few hun-dred people can gather, with beerand wine, music, and perhaps a half-dozen activities, so that people arecontinuously crisscrossing from oneto another.

Figure 1 shows an abstract sketch ofthis solution. To accommodate such a

large gathering of people, a beer hallshould have tables in the middle andactivities around the circumference toencourage movement throughout theroom.

The description of a pattern is typi-cally three to five pages long and discusses forces, or tradeoffs, thatdesigners must consider to successfullyapply the pattern. For example, indesigning a beer hall: What should bethe focus of attention? How will peo-ple mingle? How will they feel they arein a place of their own?

Design patterns range in scale from acity to a room and, together, form a pat-tern language that designers can adapt

to a project’s particular level of com-plexity or detail. For example, in design-ing a beer hall, you could select Alcoves,a subpattern that states that any com-mon room should have small spaces atthe edge “large enough for two people

Design Patterns for UbiquitousComputingJames A. Landay, University of California, BerkeleyGaetano Borriello, University of Washington

By communicating solutionsto common problems, designpatterns make it easier tofocus efforts on uniqueissues.

Figure 1. Beer Hall design pattern. A beerhall should have tables in the middle andactivities around the circumference.

94 Computer

I n v i s i b l e C o m p u t i n g

covered” themselves, making such con-cepts easy to share.

UI designMore recently, design patterns have

sparked interest in user interface design,a field that shares the customer focus ofarchitecture. Jenifer Tidwell’s patternlanguage, the first for UI design, offersmany interaction patterns for GUIs(http://time-tripper.com/uipatterns/).

Web site design A new book co-authored by Douglas

K. van Duyne, James A. Landay, andJason I. Hong, The Design of Sites:Patterns, Principles, and Processes forCrafting a Customer-Centered WebExperience (Addison-Wesley, 2003),offers 90 patterns targeted at Web sitedesign (www.designofsites.com). Forexample, Quickflow Checkout explainshow to let customers easily purchaseitems in their Shopping Cart withoutbeing delayed by unnecessary distrac-tions such as Cross-Selling and Up-Selling.

UBICOMP DESIGN PATTERNSThe next step in the evolution of

design patterns is to apply them in amore formative field such as ubiquitouscomputing by documenting lessonsalready learned in this new field or thatcan be carried over from previousdesign knowledge. Some of the ubi-comp patterns we have brainstormedinclude Context-Sensitive I/O, Physical-Virtual Associations, Global Data,Proxies for Devices, Follow-Me Dis-play, Appropriate Levels of Attention,and Anticipation. Some of these pat-terns focus on user interface aspects,some on systems aspects, and some onboth.

Context-Sensitive I/OOne design pattern we have devel-

oped that hints at what an eventualubicomp pattern language might belike addresses the following problem:

Ubicomp devices will be used in avariety of locations and situations,

to sit, chat, or play and sometimes largeenough to contain a desk or a table.”Likewise, Beer Hall could be an integralpattern in Night Life, a higher-orderpattern that recommends knittingtogether “shops, amusements, and ser-vices which are open at night, alongwith hotels, bars, and all-night diners toform centers of night life.”

Software designAlexander’s ideas have caught on in

disciplines other than architecture. Sincethe mid-1990s, design patterns havebeen one of the most influential ideas insoftware engineering, first popularizedby the “gang of four”—Erich Gamma,Richard Helm, Ralph Johnson, andJohn Vlissides—in their book, DesignPatterns: Elements of Reusable Object-Oriented Software (Addison-Wesley,1995). For example, the Listener pat-tern offers a solution to the problem ofhow to notify one part of a program ofan event that has occurred elsewhere inthe program. Software design patternsgave concrete names to abstract con-cepts that many developers had “dis-

but the device interfaces must notinterrupt or distract the user fromperforming a primary task or annoya nearby group of people.

Because certain input and outputmodalities are more appropriate in dif-ferent circumstances, applying thedesign-pattern concept to this problemmight yield the following solution:

Input and output modalities shouldadapt to the user’s current context.

For example, relying on speech oraudio output is not a good idea whenthe user is participating in a meeting,attending a lecture, or in a movie the-ater. As Figure 2 shows, a context-sen-sitive cell phone should know when itsowner is in a meeting and switch auto-matically to a vibration alert ratherthan require the owner to turn off theaudible ringer.

On the other hand, direct manipu-lation input to a handheld device maybe inferior to speech or pushing a fewphysical buttons when the user is dri-ving a car. Likewise, when the driverplaces or receives a call, the car stereovolume should lower automatically.

Physical-Virtual AssociationsAnother ubicomp design pattern we

have developed addresses the follow-ing problem:

When people get together to collab-orate in some way, they should nothave to spend lots of time configur-ing their devices.

For example, at a meeting, the appro-priate files, including biographies andcontact information, should appearautomatically on each person’s laptopor PDA. The following solution wouldapply to this problem:

When users are near one another,make it easy for their devices to con-nect and create an association thatlets them share information over thelife of a session.

Figure 2. Context-Sensitive I/O design pat-tern. A cell phone should detect whetherthe owner is driving or at a meeting andaccordingly either ring or vibrate.

Figure 3. Physical-Virtual Associationsdesign pattern. Devices should create asso-ciations, either automatically or via directuser input, when users are near each other.

Roy Bill

such patterns, given the time andexpense required to test each one?Also, how do you evaluate the processof using patterns? Conducting con-trolled studies is difficult because of thecreativity and skill involved in the actof design.

The process of developing designpatterns is still fairly ad hoc, but we fol-low one simple rule: Find patterns thathave been used successfully in realproducts or systems. Ideally, we preferto find three good examples of a pat-tern being used in practice before wedeclare it to be a design pattern. Weinvite readers to submit their own ideas at http://guir.berkeley.edu/wiki/ubicomp. �

James A. Landay is an associate pro-fessor of computer science in theDepartment of Electrical Engineeringand Computer Sciences at the Univer-sity of California, Berkeley. He is alsoon the faculty of the university’s Groupfor User Interface Research andcofounder of the Berkeley Institute ofDesign. Contact him at landay@cs.berkeley.edu.

A Context-Sensitive I/O device pro-vides the appropriate output for mak-ing a Physical-Virtual Association.Some associations can occur automat-ically when two known devices comeinto physical proximity—for example,a user’s PDA and PC could synchronizeautomatically. As Figure 3 shows, cre-ating other associations might requiredirect user action—for example, lettingothers in the same meeting see docu-ments on a PDA might require theowner’s approval.

In other circumstances, users canconnect their devices to create an asso-ciation that allows them to share infor-mation over the life of a session. Forexample, the Hummingbird estab-lishes a virtual connection betweennearby users skiing at the same resort,enabling them to track one another’slocation on the slopes and therebycommunicate more easily.

A pplying design patterns to ubiq-uitous computing raises severalinteresting research questions.

For example, how do you validate

Gaetano Borriello is a professor in theDepartment of Computer Science andEngineering at the University of Wash-ington and laboratory director of IntelResearch Seattle. Contact him at gae-tano@cs.washington.edu.

Editor: Bill N. Schilit, Intel Research Seattle; bill.schilit@intel.com.

Investing in Students

computer.org/students/

Lance Stafford Larson Student Scholarship best paper contest

✶Upsilon Pi Epsilon/IEEE Computer Society Award

for Academic Excellence

Each carries a $500 cash award.

Application deadline: 31 October

SCHOLARSHIPMONEY FORSTUDENTMEMBERS

Join a community that targets your discipline.

In our Technical Committees, you’re in good company.

computer.org/TCsignup/

Looking for a community targeted to yourarea of expertise? IEEE Computer SocietyTechnical Committees explore a variety

of computing niches and provide forums fordialogue among peers. These groups influenceour standards development and offer leadingconferences in their fields.

JOIN A THINKTANK