© 2008 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or 
for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be 
obtained from the IEEE.  
For more information, please see www.ieee.org/web/publications/rights/index.html. 
MOBILE AND UBIQUITOUS SYSTEMS
www.computer.org/pervasive 
Hacking, Mashing, Gluing:  
Understanding Opportunistic Design 
Björn Hartmann, Scott Doorley, and Scott R. Klemmer 
Vol. 7, No. 3 
July–September 2008 
This material is presented to ensure timely dissemination of scholarly and technical 
work. Copyright and all rights therein are retained by authors or by other copyright 
holders. All persons copying this information are expected to adhere to the terms 
and constraints invoked by each author's copyright. In most cases, these works 
may not be reposted without the explicit permission of the copyright holder. 
And paste pdf into powerpoint - software Library dll:C# Create PDF from PowerPoint Library to convert pptx, ppt to PDF in C#.net, ASP.NET MVC, WinForms, WPF
Online C# Tutorial for Creating PDF from Microsoft PowerPoint Presentation
www.rasteredge.com
And paste pdf into powerpoint - software Library dll:VB.NET Create PDF from PowerPoint Library to convert pptx, ppt to PDF in vb.net, ASP.NET MVC, WinForms, WPF
VB.NET Tutorial for Export PDF file from Microsoft Office PowerPoint
www.rasteredge.com
46 
PERVASIVE
computing
Published by the IEEE CS      1536-1268/08/$25.00 © 2008 IEEE
TH E   H A C K I N G   T R A D I T I O N
Hacking, Mashing, Gluing: 
Understanding 
Opportunistic Design
Björn Hartmann, Scott Doorley, 
and Scott R. Klemmer
Stanford University
Learn about principles of opportunistic design through an interview 
study of 14 professional and hobbyist “mashers” from three design 
disciplines: Web 2.0, hardware, and ubiquitous computing.
O
pportunistic practices in interac-
tive system design include copy-
ing and  pasting source  code 
from public online forums into 
your own scripts, taking apart 
consumer electronics and appropriating their 
components for design prototypes, and “Frank-
ensteining” hardware and software artifacts 
by joining them with duct tape and glue code. 
We consider these opportunistic practices part 
of mashup design. Although many ubiquitous 
computing practitioners have engaged in these 
practices, design tools and software engineering 
research don’t traditionally address them.
Mashup design’s ad hoc nature might be an-
tithetical to classical software 
engineering  methods,  but  it 
can have a signifi cant impact. 
For example, Eric von Hippel 
chronicles the importance of 
end-user innovation in  fuel-
ing  commercial  product  de-
velopment in this issue (p. 66) and elsewhere.1 
Because hobbyists and amateurs often under-
take opportunistic design, it relates to end-user 
programming.2,3 Even professionals engage in 
opportunistic practice when speed and ease of 
development are valued over robustness and 
maintainability.4 We aimed to understand how 
mashup design of software and hardware takes 
place today to derive goals for better design 
tools in the future.
In this article, we introduce a framework that 
situates opportunistic  design for ubiquitous 
computing at the intersection of three existing 
hacking traditions and distinguishes between 
deep and surface-level approaches for integrat-
ing components. We interviewed 14 professional 
and amateur “mashers” from three design disci-
plines: Web 2.0, hardware, and interactive ubiq-
uitous computing. This interview study revealed 
how designers choose between integration lev-
els; how mashups provide epistemic, pragmatic, 
and intrinsic values for their creators; and how 
shopping becomes a central activity.
Ubicomp mashups
In our view, mashups consist of recombination 
and ad hoc design across boundaries of bits and 
atoms. This broad perspective builds on previ-
ous concepts of mashups in computer science and 
music. Mashups originated in music, where the 
term denotes the practice of taking elements of 
two or more existing songs and creating a new 
piece by rearranging, interspersing, and superim-
posing parts of these sources. Computer science 
later adopted the term to refer to applications 
created by programming against one or more 
public Web APIs, also known as infrastructure 
services.5 We’re most interested in the nascent 
area of ubiquitous computing mashups. Ubi-
comp mashups attempt to move computation off 
the desktop and integrate it with the artifacts of 
everyday life.6 They extend beyond the Web and 
combine the functionality of both software and 
hardware components. 
software Library dll:C# PDF Page Extract Library: copy, paste, cut PDF pages in C#.net
Ability to copy selected PDF pages and paste into another PDF file. Copy three pages from test1.pdf and paste into test2.pdf.
www.rasteredge.com
software Library dll:VB.NET PDF Page Extract Library: copy, paste, cut PDF pages in vb.
Ability to copy PDF pages and paste into another PDF file. Support ' Copy three pages from test1.pdf and paste into test2.pdf. Dim
www.rasteredge.com
JULY–SEPTEMBER 2008 
PERVASIVE
computing 47
A framework   
of mashup components
Moving from the physical to the digi-
tal domain, a ubicomp mashup can use 
four types of components (see Figure 
1). First, a mashup can contain built or 
repurposed mechanisms, such as a toy 
doll’s movement mechanism. Second, 
sensors and actuators can interface with 
these mechanisms and other physical 
phenomena; electronics such as embed-
ded  programmable  microcontrollers 
provide the logic for sensors and actua-
tors. Third, designers can write their 
own programs or leverage off-the-shelf 
software on their personal computers 
(be it a desktop, PDA, or smart phone). 
Local applications might offer hooks for 
programmatic automation through APIs 
or built-in scripting languages. Fourth, 
mashups can use Web infrastructure ser-
vices such as search and mapping APIs.
Each of these four components has 
a history of opportunistic design prac-
tice (see Figure 2). Shell scripts and 
application macros  have long  func-
tioned as glue between desktop appli-
cations. John Ousterhout provides a 
good overview of scripting languages’ 
advantages for connecting preexisting 
software components.7 Bonnie Nardi’s 
account of end-user programming de-
scribes tool-independent practices such 
as programming by example modifi ca-
tion.8 In the tangible world of mecha-
nisms and  electronics,  amateurs  as 
well as professional product designers 
cannibalize or repurpose off-the-shelf 
products to fi t new needs. Hardware 
hacking has seen a recent resurgence in 
popularity with hobbyists, evidenced 
by the success of publications such as 
Make magazine (www.makezine.com). 
The advent of open APIs for Web ser-
vices has spurred development of nu-
merous services and sites that aggregate 
disparate data sets. The Web API cata-
log programmableweb.com lists 3,109 
Web mashups leveraging 775 distinct 
APIs as of June 2008.
Integration strategies:  
Dovetail joints versus hot glue
A broad shift that the mashup para-
digm introduced  is the reallocation 
of the designer’s effort and creativity. 
More time and ingenuity go to select-
ing components and shaping the “glue-
ware” that interfaces them. 
We  distinguish  between  two  ap-
proaches to glue. In the fi rst, two com-
ponents explicitly support combination 
through  a shared interface.  They’re 
aware of each other, allowing for tight 
integration.  We  use  the  carpenter’s 
dovetail joint metaphor to label these 
deep combinations. Dovetail joints are 
Web
infrastructure
services
(remote code)
Electronics
hardware
Mechanisms and
physical phenomena
Off-the-shelf
software
(local code)
Web 2.0 mashups
Ubicomp mashups
Hardware hacks
(a)
(b)
Figure 1. Ubicomp systems ingredients. 
(a) Four components of a ubicomp 
mashup. (b) Ubicomp mashups unite 
hardware and Web practices.
Hardware
Software
Electronics
Mechanisms
Web APIs and
services
Local (desktop)
applications
Hardware hacking,
do-it-yourself
electronics
Ubicomp
mashups
Web 2.0
mashups
Macros and
shell
scripts
Hardware
Software
Electronics
Mechanisms
Web APIs and
services
Local (desktop)
applications
Figure 2.  A classifi cation of mashups based on their components. The arrows 
indicate how existing communities and practices inform ubicomp mashups.
software Library dll:C# PDF insert text Library: insert text into PDF content in C#.net
Parameters: Name, Description, Valid Value. value, The char wil be added into PDF page, 0
www.rasteredge.com
software Library dll:VB.NET PDF insert image library: insert images into PDF in vb.net
project. Import graphic picture, digital photo, signature and logo into PDF document. Add file. Insert images into PDF form field in VB.NET. An
www.rasteredge.com
48 
PERVASIVE
computing
www.computer.org/pervasive
THE HACKING TRADITION
documented extension and integration 
points in the system architecture—APIs 
in software, breakout headers and con-
nectors in electronics, and mounting 
holes in hardware. 
In contrast, hot glue combinations 
adjoin components that are either in-
compatible, don’t know  about  each 
other, or don’t support each other. You 
can apply hot glue to almost anything, 
but it has limited adhesive power—all 
it can offer is shallow, surface-level in-
tegration.  Screen scraping—parsing 
rendered user interfaces such as Web 
pages to gather data—and screen pok-
ing—generating synthetic mouse and 
keyboard events computationally—are 
examples of digital hot glue joints. Im-
portantly, a designer’s intent is often 
hidden in such glue code: what is re-
corded is only a trace of the taken ac-
tions (for example, a sequence of mouse 
clicks), but not their semantics (such as 
opening a particular fi le).
In practice, most systems, whether 
software or hardware, are constructed 
from preexisting components—code 
libraries, integrated circuits, and me-
chanical subassemblies. This raises the 
question of whether there’s a dividing 
line between component-based engi-
neering and mashup practice.
One  distinguishing  characteristic 
might be the degree to which systems 
rely on dovetail and hot glue joints to op-
erate. Where engineering methods strive 
to cleanly integrate dovetails, mashups 
often use both dovetail and hot glue con-
nections simultaneously. In mashup de-
sign, component selection is informed, 
but not dictated, by the availability of a 
suitable interface. If a clean integration 
interface is available, the practitioner 
will use it; if not, the practitioner will 
resort to more brittle workarounds.
Furthermore,  because  component 
vendors don’t sanction hot glue joints 
and appropriations, the source of au-
thoritative information and support 
shifts away from vendors and manu-
facturers and toward the community 
of mashup designers.
We were curious to what extent inte-
gration practices are shared by mashup 
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
Figure 3. Participants’ mashups. Samples include applications for (a) planning an evening out, (b) plotting weather forecasts 
on a map, and (c) fi nding train schedules. Participants (d) created a combination toy and fl ashlight and (e) a fl ying toy car, 
(f) listened to audio in noisy environments, (g) developed an application for annotating printed documents with video, 
(h) developed an indoor positioning prototype for smart shopping carts, and (i) built audio art installations.
software Library dll:VB.NET PDF File Split Library: Split, seperate PDF into multiple
Split PDF file into two or multiple files in ASP.NET webpage online. Support to break a large PDF file into smaller files in .NET WinForms.
www.rasteredge.com
software Library dll:VB.NET PDF Page Insert Library: insert pages into PDF file in vb.
DLLs for Adding Page into PDF Document in VB.NET Class. Add necessary references: RasterEdge.Imaging.Basic.dll. RasterEdge.Imaging.Basic.Codec.dll.
www.rasteredge.com
JULY–SEPTEMBER 2008 
PERVASIVE
computing 49
designers across hardware and software 
domains. We also wanted to know to 
what extent current domain-specifi c 
tools are appropriate to support ubi-
comp mashups. We approached these 
questions through an exploratory inter-
view study.
Interview methodology
We interviewed 14 practitioners from 
three areas of mashup design.  Four 
participants  were  involved  in  Web 
2.0 development. Four others focused 
on hardware hacking—working with 
mechanisms and embedded electron-
ics.  Six participants  worked as ubi-
comp designers—creators of interactive 
computing systems spanning hardware 
and software components. In our inter-
views, we asked participants to describe 
their work philosophy and general ap-
proach to problem solving, and then to 
focus on one particular recent project. 
To ground and structure the discus-
sion, we asked participants to produce 
artifacts or visual representations (pho-
tographs or sketches) of their project. 
Specifi cally, we asked participants to 
describe third-party components they 
integrated, how they decided to include 
particular parts, and the trade-offs and 
challenges they experienced.
Sampling mashups: 
Who, what, why
Here we review the material collected: 
who our participants are, what kinds 
of systems they build, and how and 
why they build them. For brevity, we 
only mention a subset of the interview-
ees and focus on commonalities within 
groups.
Web 2.0 programmers
Our participants  were  professional 
programmers or Web developers who 
didn’t feel that mashup programming’s 
technical aspects were a hurdle. 
Our fi rst participant, W1, owns a cell-
phone software company. In his spare 
time, he developed a mashup Web site 
that overlays restaurant and bar infor-
mation on an interactive map (see Figure 
3a). Users build a graphical path from 
one venue to the next to plan an evening 
out with friends. They can also send these 
paths to a compatible mobile phone. This 
mashup combines three online services: 
CitySearch for entertainment reviews, 
Google Maps for mapping and naviga-
tion on the desktop, and Yahoo! Maps 
for mapping on mobile devices.
A second mashup, written by partici-
pant W2, also builds on Google maps. 
His Web site features georeferenced 
weather  forecasts  and  temperature 
readings, integrated displays of user-
contributed webcam feeds, and weather 
histories. His application aggregates 
forecasts from more than a dozen na-
tional and regional weather data pro-
viders and locates these forecasts on a 
map (see Figure 3b). The site is generat-
ing enough traffi c—and ad revenue—
that he is contemplating making this 
side project his full-time job.
Aiming at the emerging mobile ap-
plication market, participants W3 and 
W4 built a mashup that delivers relevant 
train schedules for three US commuter 
rail systems to mobile phones through 
SMS or email (see Figure 3c). Users send 
a short message with a station name ab-
breviation to their system, which replies 
with upcoming train times. The system 
links an SMS email gateway to a sched-
ule database gathered from the individ-
ual rail companies. 
Screen scraping vs. Web APIs. One major 
concern for our Web 2.0 participants is 
access to and strategies for getting data: 
“Getting the data is the absolute hard-
est part” (W3). The surveyed mashups 
derived their value from integrating 
disparate data sets in ways not previ-
ously possible. Although two of the 
three projects used Google Maps’ open, 
documented infrastructure service, all 
three projects resorted to screen scrap-
ing (parsing) to gather at least part of 
their data. Participants gave two pri-
mary reasons for scraping: 
APIs simply weren’t available for ob-
taining the desired data, and 
Web  APIs  are  generally  designed 
for smaller data requests, so it’s still 
easier to obtain large data sets by 
scraping.
W2 reported building his own scrap-
ing toolkit so it now takes him as much 
time to develop a scraper as it would to 
integrate an available API. 
Business models and obstacles. All par-
ticipants reported that their mashups 
started as side projects to their full-
time jobs as consultants, business own-
ers, and developers. However, two of 
the three projects expressed interest in 
turning the mashup into a profi table 
business. With Web mashups, shifting 
from the personal sphere to the com-
mercial sphere can be challenging for 
both legal and technical reasons. W1 
reported that making money by using 
scraped content is problematic because 
of licensing restrictions. W2 reported 
that he  had  to add  redundant  data 
sources because individual weather pro-
viders could alter the format or with-
draw their data streams at any time.
Hardware hackers
In the physical and electronic design 
realms, we interviewed three toy in-
ventors at two design companies and 
a hobbyist who refashions consumer 
goods into personalized tools and pub-
lishes instructions for creating these 
tools online. The toy inventors build 
prototypes that illustrate new interac-
tion design concepts. They don’t create 
fi nished products. Project schedules are 
very short, ranging from two days to 
less than a month.
When we visited participant H1, she 
was working on a toy that functioned 
as a fl ashlight with sound effects. To 
make the concept tangible, she bought a 
pair of plastic monkeys from a local toy 
store because the monkeys had a similar 
opening mechanism to the one she envi-
sioned (see Figure 3d). She then embed-
ded a tactile switch into the mechanism’s 
lever to trigger light and sound effects 
using external electronics. A previous 
software Library dll:C# PDF insert image Library: insert images into PDF in C#.net, ASP
Import graphic picture, digital photo, signature and logo into PDF document. Merge several images into PDF. Insert images into PDF form field.
www.rasteredge.com
software Library dll:C# PDF File Split Library: Split, seperate PDF into multiple files
Divide PDF File into Two Using C#. This is an C# example of splitting a PDF to two new PDF files. Split PDF Document into Multiple PDF Files in C#.
www.rasteredge.com
50 
PERVASIVE
computing
www.computer.org/pervasive
THE HACKING TRADITION
project prototype combined a toy car 
body with plastic rocket engines from a 
model plane kit to create a new fl ying car 
(see Figure 3e). To her, the aesthetics (the 
“toyness”) of the repurposed packaging 
mattered, even though the fi nal product 
would have a radically different look.
At the second toy company, partici-
pants H2 and H3 described how they 
prototyped a handheld wireless con-
troller for a TV game. They took the 
controller’s barrel from a soda bottle, 
and they built the grip from a Gyra-
tion wireless mouse that uses a gyro-
scope to sense tilt, transforming that 
tilt data into cursor movement. A cus-
tom-made plastic mold joined the two 
pieces into one unit using custom-made 
plastic molds. They then used the wire-
less mouse’s cursor and click events to 
animate graphics on a laptop (used as 
a stand-in for a television set) running 
Adobe Flash.
In  contrast  to  the  toy  designers’ 
rough-and-ready prototypes, partici-
pant H4  builds his hardware-based 
mashups  for  long-term private  use. 
Many of the artifacts  he uses daily 
were created by modifying consumer 
goods. One project he created was a 
pair of jackhammer hearing-protection 
earmuffs that he retrofi tted with a pair 
of airline headphones to listen to audio 
books in noisy environments (see Fig-
ure 3f). According to H4, this design 
offers better noise reduction than com-
mercial  noise-canceling headphones 
and is signifi cantly cheaper.
For all three toy inventors, visiting 
large retail stores to purchase interest-
ing new toys was an integral part of 
their core practice. They would later 
disassemble these toys in their shop. We 
identifi ed three strategies of appropriat-
ing store-bought toys: 
Designers extract mechanisms and 
reuse them in different  skins  (for 
example, H2 and H3 transferred a 
purchased toy’s animated movement 
into a new prototype).
Designers keep a toy’s shell but em-
bed new electronics into it (H1 did 
this “because it immediately looks 
like a toy”).
Designers fuse different shells (such 
as H1’s metal toy car with air plane 
rocket engines) to produce a compos-
ite object. 
While many Web mashups build on 
a few high-value components, such as 
Google Maps, our hardware hackers’ 
choices  didn’t cluster  around high-
value products. To the contrary, within 
a given genre the toy designers collected 
a wide variety of products in their stor-
age bins for later reuse.
In contrast to the toy designers, H4 
saw the tailoring of existing artifacts as 
a partial rejection of consumer culture. 
The self-suffi ciency of “do it yourself” 
offers a degree of intrinsic satisfaction 
along with a level of personalization and 
novelty unavailable in mass-produced 
artifacts. For H4, the economies of scale 
that mass-produced consumer goods le-
verage are incentives. Picking existing 
parts is cheap: “It’s never cheaper to 
start from scratch to make your own.”
Ubicomp designers
Our six ubicomp developers used mash-
ups as prototypes and proof-of-concept 
deliverables, but also as a way to design 
and implement site-specifi c tools for a 
single user or a small community.
Participant U1, a design researcher, 
worked on a system for design teams 
to annotate printed documents with 
short video messages. In his functional 
prototype (see Figure 3g), users push a 
button to initiate video message record-
ing on a laptop. After recording, the 
system prints a small label displaying a 
snapshot of the video and a bar code. 
The user attaches this bar code to the 
document described in the video. If an-
other user wants to access the video, she 
waves the bar code in front of the same 
camera, upon which the system retrieves 
and plays back the desired video. U1 re-
lied heavily on commercial off-the-shelf 
software, combining fi ve different ap-
plications through AppleScript. For ex-
ample, he scripted QuickTime to record 
and play back video, and he used the 
Excel spreadsheet software as a data-
base. To convey this project’s complex-
ity, Figure 4 shows our redrawn version 
of his system architecture sketch.
Participant  U2,  an  industrial  re-
searcher, described a project where he 
designed an indoor positioning proto-
type for smart shopping carts. This po-
sitioning system employed computer vi-
sion. To test the vision data quality, U2 
attached a custom-built optical rotation 
sensor to a shopping cart’s wheel and 
soldered its contacts to the left button of 
a gutted PC mouse, so that each revolu-
tion yielded one click (see Figure 3h). By 
counting the total number of clicks on 
the PC, he received ground truth data 
about the total distance the cart had 
traveled. (For more information, also 
see “Hacking in Industrial Research 
and Development” in this issue.)
U3 has been developing his own musi-
cal programming language and graphi-
cal  environment  for  producing  and 
performing electronic music. He builds 
audio installations that he shows at the 
annual Burning Man festival (see Figure 
3i). Although he spent years designing 
his software from the ground up, the 
physical controllers he used were off-the-
shelf game console input devices such as 
“Dance Pad” fl oor mats. According to 
him, “you can choose what level of ef-
fort you want to put in—you can buy the 
next level of integration.” To him, a key 
component enabling his installation was 
a small hardware converter that lets him 
connect controllers built for proprietary 
game consoles to a PC USB port.
As Web  2.0 programmers employ 
screen scraping to  harvest  informa-
tion from online databases, ubicomp 
programmers use screen poking to re-
motely control software. In addition to 
U2’s appropriation of a mouse button 
for measuring turns of a wheel, U1 ini-
tially used the macro software Automate 
as a means to control desktop applica-
tions by computationally injecting syn-
thetic mouse and keyboard events. U3 
purchased a hardware converter that 
transformed  the  output of pressure-
JULY–SEPTEMBER 2008 
PERVASIVE
computing 51
sensing dance pads into Windows plat-
form game controller events. U3 chose 
these  glueware  techniques  for  simi-
lar  reasons  as  screen scraping: APIs 
are sometime unavailable, don’t yield 
the desired information, or are more 
time-consuming  than  surface-level 
instrumentation.
Screen  scraping  can  also  be inter-
preted as an act of sensing, while screen 
poking in turn is analogous to actua-
tion. As sensing the physical world yields 
ambiguous, noisy data that must be con-
ditioned and fi ltered, data from screen 
scraping often has to be cleaned and 
processed. This suggests that mediation 
techniques for ambiguous sensor input9 
might transfer to Web scraping, and vice 
versa. Despite the analogies, there are 
barriers in crossing the chasm between 
Web-centric applications and the physi-
cal realms of  sensing and actuation. 
One reason is that client-side Web tech-
nologies have increasingly moved into 
secure-execution sandboxes that can’t 
communicate  directly  with external 
hardware. We still need design tool sup-
port for bridging these two domains to 
enable experimentation by lead users.
Themes in opportunistic 
programming
Our interviews uncovered some com-
mon concerns across the three design 
domains. Choosing between levels of 
integration,  shopping,  and connect-
ing to larger communities of mashup 
designers emerged as unifying themes, 
among others.
Dovetail joints versus  
hot glue revisited
Across domains, our interviewees freely 
mixed deep and surface-level integra-
tion techniques in their projects. Each 
choice has important limitations: while 
shallow hot glue is brittle, deeper inte-
gration might have limited reach. These 
trade-offs are exemplifi ed by U1’s expe-
rience. He scripted an earlier version of 
his document annotation system using 
software that lets users record interac-
tion with GUI widgets and replay those 
actions programmatically. Although 
this system succeeded as an experience 
prototype, it wasn’t robust enough for 
any unsupervised deployment. Seeking 
to improve on stability, U1 then switched 
to AppleScript, which let him leverage 
application-specifi c APIs. Although the 
deeper glue that AppleScript provides is 
signifi cantly cleaner for expressing logic 
than GUI events, U1 found no program-
matic means within AppleScript for up-
loading the video clips to an online me-
dia-sharing site, a task that his previous 
strategy could accomplish.
Beyond  the  technical  consider-
ation of how to adjoin components is 
a larger question about the relation-
ship between the  designed intent of 
the constitutive elements and that of 
Excel
looks up ID
XLS file
launches
Griffin
PowerMate
iSight
Proxi
iSight
Evo
Barcode
Record
AppleScript
Reuse
AppleScript
launches
writes
Label printer
Quicktime
DymoPrint
starts playback
Quicktime
Video
Own code
COTS
Physical I/O
File I/O
Screenshot
(JPG)
pulls
snapshot
generates
doc
detects barcode
returns ID
launches
retrieves video
Figure 4. System diagram of U1’s project. The project enabled designers to annotate printed documents with video messages.
52 
PERVASIVE
computing
www.computer.org/pervasive
THE HACKING TRADITION
the resulting mashup. Mashups might 
appropriate technologies, repurposing 
them as building blocks toward a goal 
at odds with their original design.
One suitable defi nition of appropria-
tion is “the extent to which a violation 
of a technology’s intended purpose oc-
curs.”10 This violation is easy to see 
in toy hacking: toys were intended for 
children to play with, not for design-
ers to take apart. Similarly, in the digi-
tal realm, screen scraping appropriates 
output intended for human consump-
tion as program input. In contrast, us-
ing Web 2.0 APIs such as Google Maps 
isn’t an act of appropriation because the 
API’s providers give explicit permission 
to use the service in new contexts. 
It’s notable that in the Web 2.0 space, 
where the general trend has been to open 
up infrastructure services to allow reuse 
without appropriation, all of our par-
ticipants still resorted to screen scraping 
techniques. There are valid business rea-
sons not to make all company data avail-
able for automatic processing by others 
through APIs. Simultaneously, those 
same business reasons make capturing 
the data valuable for third parties. We 
conclude that support for both tight and 
loose coupling (dovetail joints and hot 
glue) will be inevitable for design tools. 
Opportunistic design is based on inte-
grating existing artifacts that best fulfi ll 
a functional or informational need, re-
gardless of their programming interface 
or licensing agreement.
Mashing as a design activity
Next, we consider the activity of creat-
ing mashups: when, how, and why is 
mashing preferable to other design and 
development approaches? What value 
do practitioners derive from it?
Short  timelines,  small  audiences? 
Mashup design in the physical world 
tends to happen on short timelines— 
the mashups we encountered were built 
quickly, and many were discarded just 
as quickly afterwards. By necessity, 
the artifacts were intended for small 
audiences; physical mashups are one-
offs that can’t be duplicated easily. The 
emphasis on speed is a good match for 
designers who want to rapidly proto-
type multiple ideas, consultants oper-
ating on compressed project schedules, 
and hobbyists with limited leisure time. 
Similarly, for these constituencies, the 
audience of a user’s mashup is small: the 
design team, a single client, or oneself. 
The Web mashups we encountered 
have different traits: they operate con-
tinuously, and their success is measured 
in  the number  of users they attract. 
Thus, engineering for robustness, re-
dundancy, and maintenance becomes 
important—in  this  respect, building 
Web mashups more closely resembles 
traditional software engineering. This 
difference could be an artifact of our 
small survey population, but Web appli-
cations offer the unique opportunity to 
reach larger audiences without reengi-
neering from the ground up: the proto-
type is the product. This opportunity to 
scale could lead Web developers to con-
template robustness from the outset.
Although it’s certainly fast to get ap-
plications up and running by appropri-
ating existing technology, completing 
the “last mile”—fi ne-tuning applica-
tion logic and interaction design—can 
be diffi cult as desired functionality and 
offered features of existing components 
diverge. On the other hand, building 
with lower-level blocks, or even from 
scratch, incurs a large initial cost be-
cause developers must write their own 
tooling. In exchange, they preserve fl ex-
ibility and can leverage their own tools 
later in the project cycle. The sweet spot 
for rapid, disposable mashups that our 
interviews found is consistent with this 
analysis. It also suggests an opportu-
nity for design tools that leverage op-
portunistic development early on while 
preserving fl exibility or offering some 
level of guaranteed robustness. 
Epistemic, pragmatic, and intrinsic values. 
We found that mashups provided both 
pragmatic and epistemic value to our 
participants. An artifact is pragmatic to 
the extent that it enables actual use, and 
it’s epistemic to the extent that it serves 
as a locus of communication with other 
stakeholders—clients, team members, 
and users—and provides information 
that can drive future design.11,12 For 
some participants, creating mashups 
also held intrinsic value generated by the 
activity itself, rather than the utilitarian 
or educational value of the outcome.
Pragmatic decisions for mashups are 
made if using mashups is more effi cient 
or effective than other techniques to 
reach a goal. Participant U3 estimated 
that by repurposing a mouse button to 
fi re a click event with each revolution 
of a wheel, he was able to complete the 
sensing part of his project in a quar-
ter of the expected time. Furthermore, 
incorporating existing pieces lets de-
signers leverage functionality that they 
couldn’t build themselves. Framed this 
way, we can think of the set of exist-
ing technologies in the world as a vast 
library that we can use to lower the 
threshold for development. For exam-
ple, U4 didn’t have suffi cient technical 
knowledge to build his own physical 
music controller, but, through adapt-
ers, he was able to leverage commer-
cially available game controllers.
Other times, practitioners employ 
mashup design as a means of explo-
ration, learning, or inspiration. This 
epistemic activity was most prevalent 
among our toy inventors, who chose 
mashups as effective means to illustrate 
new concepts. What their clients paid 
for was the idea, prototyped through 
the mashup, not the implementation. 
Furthermore, rapidly creating proto-
types gives designers concrete artifacts 
they can expand on, react against, mod-
ify, and transform. This conversation 
with materials (as opposed to thinking 
in the abstract) is an important strategy 
of refl ective practice.13 Refl ective prac-
titioners are concerned with problem 
setting as much as problem solving, and 
they let prototypes inform their under-
standing of the larger design space.
In the intrinsic case, practitioners 
create mashups because they regarded 
the activity of mashing  as  fulfi lling 
JULY–SEPTEMBER 2008 
PERVASIVE
computing 53
in its own right. They derive intrin-
sic value from the joy of exercising a 
craft (“what a great way to spend an 
afternoon”) or from a personal ideol-
ogy (“recycling is my form of protest 
against consumer culture”). Our inter-
views suggest that intrinsic activity is 
most common among hobbyists. 
Shopping for functionality. As Frederick 
Brooks wrote, “The most radical pos-
sible solution for constructing software 
is not to construct it at all.”14
How exactly does the activity of de-
signing and developing change when no 
“new” software is created? Participants 
reported spending signifi cant time on 
fi nding and acquiring their ingredients. 
In fact, some reported that this was the 
most challenging or time-consuming 
part of their process. U1 described the 
processes of searching for components 
and determining how to integrate them 
into his design as “the main part of the 
whole thing.” Or, as U3 put it, “The 
real challenge is fi nding the interface 
between the problem and commercially 
available stuff.”
Our toy inventors also reported fre-
quent trips to the toy store without hav-
ing a shopping list for a project. U4 did 
the same at electronics retail stores. We 
found three reasons for shopping with-
out a project in mind: 
It builds awareness of the state of the 
art and shows designers what’s com-
mercially available. 
It reduces the cost of future searches. 
Like  squirrels  gathering  nuts  be-
fore the winter, designers stockpiled 
mechanisms to have them ready later. 
H2 said, “We collect [mechanical] 
movements. … [During a project, 
one of us will say] ‘Remember that 
freaky belly movement?’”
It inspires new projects. “I go on shop-
ping trips and think about repurpos-
ing objects. ... I’ll walk around Wal-
greens and look at objects and think, 
‘What could this be?’” (H1). 
Searching for and acquiring pieces was 
inspirational and helped steer projects 
in a particular direction. This suggests 
that shopping itself can take on an epis-
temic function. 
Searching for bridges. Several times, 
participants reported fi nding crucial 
connecting pieces for their mashups in 
fi elds only tangentially related to their 
own. U4 discovered that a MIDI-to-
relay interface used by church-organ 
builders would trigger lights based on 
music commands for his Burning Man 
installations. Adapters and bridges are 
well-known design patterns for soft-
ware engineers. We focus on the social 
side—the bridges that led practitioners 
to discover these connections in the 
fi rst place. While Web search was uni-
versally used, effective search requires 
prior knowledge of the space of op-
portunity. Community sources play an 
important role: for example, U1 inte-
grated two external button interfaces 
into his project because he knew that 
other researchers in his building had 
used those particular models success-
fully. Scaling such community aware-
ness  to  geographically  distributed 
teams of designers is an important goal 
for the future. In the hobbyist market, 
Web sites like http://instructables.com 
that publish instructions and parts lists 
for do-it-yourself projects have begun 
to address this need. 
O
ur analysis raises several 
suggestions  for  creat-
ing future mashup design 
tools. First, it’s important 
to recognize mashup programmers and 
hardware hackers as a unique target au-
dience: they’re not professionals, in that 
their primary job description isn’t cre-
ating mashups, but neither are they un-
trained end users. Our participants were 
all technologically sophisticated and 
used mashup techniques to achieve some 
other goal in their domain of expertise. 
So, design tools must strike a balance 
between complexity and fl exibility. 
Second, the use of both dovetail as 
well as hot-glue combinations in many 
of the projects suggests that we need 
tools that better support fl uidly tran-
sitioning between the two integration 
styles within the same project. 
the 
AUTHORS
Björn Hartmann is a PhD candidate in HCI at Stanford University. His research 
focuses on prototyping tools for designers and lead users. Hartmann received 
his MSE in computer and information science from the University of Pennsylva-
nia. Contact him at bjoern@cs.stanford.edu.
Scott Doorley is the director of the environments lab at Stanford University’s 
Hasso Plattner Institute of Design. His research interest is applying design 
methods to creative domains such as writing, fi lm making, and informal learn-
ing. Doorley received his MA in learning, design, and technology from Stan-
ford University. Contact him at sdoorley@stanford.edu.
Scott R. Klemmer is an assistant professor of computer science at Stanford 
University, where he codirects the Human-Computer Interaction Group. His 
primary research focuses are interaction techniques and design tools that en-
able integrated interactions with physical and digital artifacts and environ-
ments. Klemmer received his PhD in computer science from the University of 
California, Berkeley. Contact him at srk@cs.stanford.edu.
54
PERVASIVE
computing
www.computer.org/pervasive
THE HACKING TRADITION
Third, we can learn from product de-
signers who keep their studios stocked 
with cannibalized parts by developing 
tools that more fully embrace “design 
by example modifi cation” or “design 
by example augmentation” as a funda-
mental strategy. 
Finally, design tool research often 
focuses on the construction of appli-
cations. The important epistemic and 
pragmatic functions of shopping sug-
gest that tools that support search, se-
lection, and sharing of existing compo-
nents could be equally valuable.
REFERENCES
1.  E. von Hippel, Democratizing Innova-
tion, MIT Press, 2005.
2.  A. Cypher, Watch What I Do: Programming 
by Demonstration, MIT Press, 1993.
3.  H. Lieberman, F. Paterno, and V. Wulf, 
End-User Development, Springer, 2005.
4.  J. Brandt et al., “Opportunistic Program-
ming: How Rapid Ideation and Prototyp-
ing Occur in Practice,” Workshop End-
User Software Eng., ACM Press, 2008, 
pp. 1–5.
5.  E.A. Brewer, “Lessons from Giant-Scale 
Services,” IEEE Internet Computing, vol. 
5, no. 4, 2001, pp. 46–55.
6.  M. Weiser and J.S. Brown, “The Coming 
Age of Calm Technology,” Beyond Calcu-
lation: The Next 50 Years of Computing, 
P.J. Denning and R.M. Metcalfe, eds., 
Copernicus Books, 1997, pp. 75–86.
7.  J.K. Ousterhout, “Scripting: Higher Level 
Programming  for  the  21st  Century,” 
Computer, Mar. 1998, pp. 23–30. 
8.  B.A. Nardi, A Small Matter of Program-
ming: Perspectives on End User Comput-
ing, MIT Press, 1993.
9.  J. Mankoff, G.D. Abowd, and S.E. Hud-
son, “OOPS: A Toolkit Supporting Medi-
ation Techniques for Resolving Ambigu-
ity  in  Recognition-Based  Interfaces,” 
Computers and Graphics, vol. 24, no. 6, 
2000, pp. 819–834.
10.  R. Eglash, “Appropriating Technology: 
An Introduction,” Appropriating Tech-
nology: Vernacular Science and Social 
Power, R. Eglash et al., eds., Univ. of Min-
nesota Press, 2004, pp. vii–xxi.
11.  D. Kirsh and P. Maglio, “On Distinguish-
ing Epistemic from Pragmatic Action,” 
Cognitive  Science,  vol.  18,  1994,  pp. 
513–549.
12.  S.R.  Klemmer,  B.  Hartmann,  and  L. 
Takayama, “How Bodies  Matter: Five 
Themes for Interaction Design,” Proc. 
6th Conf. Designing Interactive Systems, 
ACM Press, 2006, pp. 140–149.
13.  D.A. Schön, and J. Bennett, “Refl ective 
Conversation with Materials,” Bringing 
Design to Software, T. Winograd, ed., 
ACM Press, 1996.
14.  F.P. Brooks, The Mythical Man-Month: 
Essays on Software Engineering, Addison-
Wesley, 1995.
For more information on this or any other com-
puting topic, please visit our Digital Library at 
www.computer.org/csdl.
The opportunistic paradigm requires a major change of mindset 
from designing and writing original software to a world of few rules, 
theories, or recipes. Some titles to look for:
“Pragmatic and Opportunistic Reuse in Two Innovative Startups”
“Creative Thinking through Opportunistic Software Development”
“Monoliths to Mashups: The Need for Opportunistic Integration”
“Situated Software—Concepts, Motivation, Technology, and 
the Future”
“Balancing Opportunities and Risks in Component-Based Software    
Development”
And more ….
Check the IEEE Software Web site www.computer.org/software in 
November or email software@computer.org and ask to be notified 
when it’s published.
If you’re enjoying this issue 
on hacking, you’ll also enjoy
Opportunistic Software
Systems Development
The November/December ‘08 special issue from
IEEE Software magazine!
Documents you may be interested
Documents you may be interested