User-Friendly Functional Programming for Web Mashups

Rob Ennals David Gay

Intel Research Berkeley
2150 Shattuck Avenue, Penthouse Suite
Berkeley, CA 94704
{robert.ennals,david.e.gay}@intel.com

Abstract Digg.com with Slashdot.org, and WikiMapia.com which combines

MashMaker is a web-based tool that makes it easy for a normal WikiPedia.org with Google Maps to provide information about
user to create web mashups by browsing around, without needing physical locations. At the time of writing, ProgrammableWeb.com
to type, or plan in advance what they want to do. lists around 2,100 known mashup sites and the number is growing
Like a web browser, Mashmaker allows users to create mashups rapidly.
by browsing, rather than writing code, and allows users to book- While there are a large number of mashup sites in existence,
mark interesting things they find, forming new widgets — reusable there are many more that could usefully be created. For example,
mashup fragments. Like a spreadsheet, MashMaker mixes program as far as the authors are aware, no existing mashup site can answer
and data and allows ad-hoc unstructured editing of programs any of the following questions1 :
MashMaker is also a modern functional programming language
with non-side effecting expressions, higher order functions, and • Which of these houses on Craigslist has lots of good restaurants
lazy evaluation. MashMaker programs can be manipulated either nearby according to Yelp, and would be less than a 30 minute
textually, or through an interactive tree representation, in which a commute to work according to Google Maps?
program is presented together with the values it produces. • Which of these events on Upcoming clash with things on my
In order to cope with this unusual domain, MashMaker contains Google Calendar?
a number of deviations from normal function languages. The most
• How much would each of these recipes from Epicurious cost to
notable of these is that, in order to allow the programmer to write
programs directly on their data, all data is stored in a single tree, and make if I bought the ingredients at Safeway?
evaluation of an expression always takes place at a specific point in • How much of my weekly expenditure according to Bank of
this tree, which also functions as its scope. America goes to companies who donate money to political
parties I don’t like according to OpenSecrets?
Categories and Subject Descriptors D.3.2 [Language Classifica-
tions]: Very high-level languages; H.4.3 [Information Systems Ap- • What is the best route through town according to GoogleMaps
plications]: Information Browsers that allows me to visit highly rated shops according to Yelp that
sell suggested Christmas presents appropriate for each of my
General Terms Languages, Human Factors, Design, Manage- friends according to FindGift?
ment
Keywords Mashup, web, end-user programming, browser It seems reasonable to assume the number of such useful ques-
tions users might ask is huge. New web sites, containing new infor-
mation, appear on the web every day, and the number of possible
1. Introduction ways of combining them is huge, particularly when one considers
There has recently been lots of interest in so called “mashup sites” the affect of combining three, or four, or more different web sites
– web sites that combine information, processing, or visualiza- to answer a question. At the time of writing, ProgrammableWeb
tions from several web sites to provide information the user could lists over 450 web sites with published APIs intended to be used
not easily obtain by manually browsing the base web sites sepa- by mashups, and millions more web sites can be used via scrap-
rately. One of the first such sites was HousingMaps.com, which ing (Schrenk 2007).
uses a map from Google Maps to visualize houses available for If each mashup site were only able to answer a single question,
rent on Craigslist.org. Other examples include WeatherBonk.com based on a fixed set of source web sites, then it seems the number
which combines various sources of information about weather, Bid- of mashup sites needed would be impractical — both for the pro-
Nearby.com which finds items being sold nearby on sites such grammers who create them, and the users who have to find them.
as EBay.com and Craigslist.org, DiggDot.com which combines The obvious solution seems to be generic mashup sites that allow
end users to easily combine information from multiple web sites to
answer a wide range of questions. Indeed several groups have built
such generic mashup creation sites (see Section 5).
Permission to make digital or hard copies of all or part of this work for personal or In this paper, we describe MashMaker, a tool that makes it easy
classroom use is granted without fee provided that copies are not made or distributed to create mashups, for users ranging from naı̈ve to expert. The
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. To copy otherwise, to republish, to post on servers or to redistribute
to lists, requires prior specific permission and/or a fee. 1 Ifsuch a mashup site does exist then that merely goes to underscore one
ICFP’07 October 1–3, 2007, Freiburg, Germany. of our other points — having such a large number of mashup sites makes it
Copyright c 2007 ACM 978-1-59593-815-2/07/0010. . . $5.00 very hard to find a site that can answer a specific question.
design of Mashmaker is guided by a number of principles that
Value
support this goal:
v ::= c constant (file)
• Program as you browse: creation of mashups should be viewed | ∅ empty directory
as an extension of the normal web browsing habits. | v n (k 7→ v) extension
| s, λ(x0 . . . xn ).e.x closure with body e, env s
• Direct manipulation: users should be able to work directly on
and result selector x
the data that they are interested in, without having to think about
abstract concepts such as programs. Subnode Key
• Least surprise: local changes should produce local effects. k ::= x Property with name x
• Pay as you go: unskilled users should be able to gain some | • Unnamed child
benefit with very little effort, but more skilled users should be
able to do powerful things. Expression
e ::= c constant
• Code sharing: mashups, and elements used to create mashups | ∅ empty directory
should be shared across users. | e n (q 7→ e) extension
| λ(x0 . . . xn ).e.x lambda
MashMaker is a combination of a custom functional program-
| e (e) function application
ming language and a web-based user interface. We believe mashups
| this current context
are an excellent application domain for a programming language.
| p link to another node
Moreover, many web sites can be modeled as functions from
| X global
form parameters to structured results. As a result, the majority
of mashups combine side-effect-free queries and list manipulation,
Extension Path
making them an excellent application domain for a functional pro-
q ::= k new subnode
gramming language.
| ∗.q for all children
In addition to functional languages, Mashmaker draws inspira-
| x.q inside property x
tion from spreadsheets, web browsers, and file systems. Time has
shown that these are all metaphors that normal users are able to use
Reference Path
productively, and as a result, all three have been very successful.
p ::= x variable
We explain in Section 2 how each of these tools has influenced the
| x.p inside property x
design of MashMaker, in ways that support the principles outlined
| !.p inside parent
above.
Scope
1.1 The Language and the Interface s ::= v0 : . . . : vn stack of parent dir values v
The heart of MashMaker is a functional programming language.
A simplified grammar for this language is given in Figure 1. Figure 1. Simplified grammar for the MashMaker core language
MashMaker has several significant differences from previous func-
tional languages. Most of these differences stem from the fact that
the MashMaker language is designed to be accessed through a • MashMaker allows operations such as map, fold, and filter to
spreadsheet-style user interface, rather than as a textual program. be applied through direct manipulation of data (Section 2.3.1).
Like a spreadsheet, MashMaker stores every value that is com- • MashMaker automatically suggests functions that a user might
puted in a single, central data structure (in this case a tree). There
apply to their data, based on the functions that other users have
are no intermediate values that get thrown away. This tree contains
applied to similar data. This allows less skilled users to create
every intermediate value that was computed on the way to produc-
mashups simply by clicking on suggestions, without having to
ing the final result. Even the values computed internally by a func-
do any programming or having to think about what websites
tion can be made visible by expanding the function call.
might connect together (Section 2.4).
MashMaker has no concept of a scope, or of a local variable. An
expression is evaluated at a specific location in the data tree, and all • MashMaker’s user interface allows users to write expressions
variable references refer to fields at the current location. This is in a simplified form. This form allows users to avoid quoting
again similar to a spreadsheet, in which cell references are relative constants, and automatically infers arguments for lambda ex-
to the current location, and temporary values are stored directly in pressions (Section 3.5).
the data. • All data is “live”, meaning that functions automatically recom-
The language also has some more conventional features: it is pute their values in response to changing data (Section 3.6).
dynamically typed, function arguments are bound by name rather
than order, evaluation is lazy, and functions are first class values. • MashMaker bundles functions up together with associated
We describe the MashMaker language in more detail in Section 3. metadata to form “widgets” — reusable mashup fragments
The novel features of MashMaker are not just in the core lan- (Section 2.4).
guage, but also in the way that we expose this language through a • Users can interact with MashMaker at a number of different
user interface. In particular: levels making it useful for anyone from a complete beginner to
a skilled programmer (Section 2.5).
• MashMaker’s tree view shows the value that the current expres-
sion evaluates to. Each node in this tree contains an internal 1.2 Why this Paper is Interesting
reference back to the subexpression that defined that node. This This paper makes several interesting and novel contributions:
is made practical by the fact that the MashMaker language con-
siders each evaluation to have a logical position in the data tree. • We propose the use of a functional language for the creation of
(Section 2.3). web mashups.
 Figure 2. Craigslist apartment listing imported into MashMaker Figure 3. Using a Google Maps visualization for an apartment

• We propose several changes to the standard functional paradigm,

in order to make such languages more suitable for this domain.
In particular, we present a model made on tree extension, in
which an expression is evaluated with respect to a location in a
data tree.
• We demonstrate that this approach is practical, through the
creation of MashMaker, which is, in our opinion2 , the first truly
general purpose mashup creation tool that is usable by normal
users. MashMaker is currently undergoing a closed beta test
program, and we plan to open it up to the general public soon.

2. The MashMaker Design

In this section we sketch the overall design of the MashMaker
system, and explain how it draws inspiration from file systems,
spreadsheets, and web browsers.

2.1 An Illustrative Example

Since MashMaker is quite different from most functional lan-
guages, it is perhaps helpful to set the scene with a walk through of Figure 4. Joining Yelp to Craigslist
an actual session using the current version of the MashMaker tool.
1. Alice is planning to rent an apartment, so she navigates her
normal web browser to Craigslist.com and has a look at the 3. MashMaker notices that Craigslist apartments are things that
apartments listed there. Alice looks at the apartments listed users have previously displayed on maps, so it provides a button
by Craigslist and would like to know more about them. In at the top of the window allowing Alice to add a map to each
particular, she would like to know which apartments have good apartment. Alice clicks on this button to get a map for each
restaurants nearby. Since Craigslist can’t do this itself, Alice apartment (Figure 3).
realizes she needs to use MashMaker. 4. Alice would like to see Yelp restaurant reviews near each apart-
2. Alice clicks on the “Add to MashMaker” button on her web ment, but is disappointed to see that MashMaker has not pro-
browser bookmark bar to launch MashMaker and view the vided a button to do this automatically. She will thus need to
Craigslist housing web page within the MashMaker proxy- teach MashMaker about this connection herself.
browser. MashMaker starts up as an AJAX web application, 5. Alice navigates to Yelp and searches for food at an arbitrary
within Alice’s web browser, hosted by the central MashMaker address. When the result of the query appears, she clicks on
webserver (Figure 2). The right hand window shows the web “Add to MashMaker” to suck this query page into MashMaker.
page Alice is looking at, and the left hand side shows a tree The resulting Yelp node is called “food nearby” and contains
representation of the web site. In this case, there is a node for nodes for all restaurants near to the specified address.
the Craigslist query, with a child node for each apartment. Each
of these apartment nodes has a set of property nodes, expressing 6. Alice now has both Craigslist and Yelp in her MashMaker
properties of that apartment such as its price and the number of scratch space but they are not yet connected. Alice copies the
bedrooms. Yelp node into one of the apartments3 . She then expands the
“form panel” to reveal the form defining the Yelp query, and
2 Terms such as “truly general purpose” and “usable by normal” are hard to changes the “address” field of the Yelp form to be “=address” –
define formally, so some might disagree with this statement. a reference to the address property of the enclosing apartment
 9. This new property is dependent on the existence of a “food
nearby” property, and so will not be suggested by MashMaker
for Craigslist apartments that lack this property.5 Thinking that
this property might be useful for other users searching for
apartments on Craigslist, Alice decides to bundle up the new
property, together with the other properties it depends on, as a
new widget. To do this, she clicks “bookmark as new widget”,
and tells MashMaker which of the properties that this property
depends on should be considered to be arguments, rather than
being internal to the widget. In this case, the address is an
argument, and “food nearby” is internal. In the future, when
another user browses a Craigslist apartment, “good restaurants
within walking distance” may be suggested to them.
10. To allow themselves to get an overall view of the quality of each
apartment on offer, Alice adds a number of additional properties
(commute time to work, crime level, average income) and uses
the “calculator” widget to define a scoring metric by combining
these features. She then sorts all the data by this metric.
Figure 5. Yelp displays restaurants near the apartment

Section 3.2 shows the functional program that this editing ses-
sion created.

2.2 Learning from File Systems

Like a file system, MashMaker presents all data as a tree (Figure 2).
All nodes in this tree are immutable. The underlying implementa-
tion uses sharing to avoid duplicating data, but users are encouraged
to think of their data as being in a tree.
Like a file system, each node either has its own content (a file),
or subnodes (a directory). The content can be of arbitrary type, for
example, some text, a number, an expression, an image, a URL.
Each subnode is either a property with an explicit name, or a child
with no name. It is assumed that all children will represent things of
roughly equivalent type, whereas the types of properties will vary,
and correspond to their names.
MashMaker’s tree view shows a text summary for each node.
If the node is a named property, then this summary is preceded
by the property name. The summary for a simple file node is a
Figure 6. Filtering apartments using a lambda expression text summary of the content (e.g. the text for a text node). The
summary for a directory node is a user-configurable combination
of the summaries for its properties — by default the summary of
node (Figure 4). Each apartment now has a “food nearby” prop- the first property.
erty, showing the restaurants near to that apartment (Figure 5). MashMaker’s right hand pane shows a visualization of the se-
lected node. If the node is a file, then this will be a visual repre-
7. Now that Alice has created this “food nearby” node, Mash- sentation of the file’s data. In some cases, this will be a computed
Maker learns that this is a property that users might want to representation of other data in the tree, for example a map, a graph,
define for Craigslist apartments. In the future, if another user or a table. If the node’s content is a URL then that URL is shown.
views a Craigslist apartment, MashMaker will provide a “food Similarly, text, images, and other visualizations can be shown in
nearby” button to allow other users to add this same property. this panel..
8. Currently “food nearby” shows all restaurants near to each Figure 1 shows the notation for such tree values in MashMaker’s
apartment, but Alice is picky, and so is only interested in highly underlying language. We write ∅ to denote an empty directory, and
rated restaurants very near to the apartment. MashMaker knows v n (k 7→ v 0 ) to denote the directory that results from extending
that previous users have applied a filter operation to Yelp list- the directory v with a new subnode v 0 – where k is • if the subnode
ings, so it suggests that Alice apply a filter operation here (Fig- is a child and a property name if the subnode is a property. As the
ure 5). Alice clicks on this button and types “distance < 1 underlying language is purely functional, all dependencies between
AND rating > 4” as the condition4 (Figure 6). Alice could nodes are explicit, preserving the principle of least surprise.
alternatively have used an interactive user interface to compose For convenience, one can write [k0 7→ v0 , . . . , kn 7→ vn ] as an
this query. Alice renames the result of the filter to “good restau- abbreviation for ∅n(k0 7→ v0 )n. . .n(kn 7→ vn ). To illustrate the
rants within walking distance”. way this notation works, here is the notation for the value shown in
Figure 5:
3 This corresponds to a “map” operation (Section 2.3.1).
4 This is actually a lambda expression, despite the absence of lambda sym-
bol or explicit arguments (Section 3.5). 5 See Section 2.4 to see why.
 The tree view on the left side of the MashMaker window shows
[ the value that the user’s current program evaluates to. Each node
food nearby 7→ . . . , is either a defined node, meaning that there is a user-specified
craigslist housing 7→ [ expression defining its value, or it is a result node, meaning that it
url 7→ . . . , is part of the result of evaluating a parent defined node. In the user
• 7→ [ interface, result nodes have a green ball as their icon while defined
title 7→ “Rare Jordan Park Listing”, nodes have an icon corresponding to the function that defines them.
food nearby 7→ [ A defined node contains an internal reference to the expression that
• 7→ {title 7→ “Tawan’s Thai Food”, . . .}, defines it, allowing the user to easily edit this expression. Each
• 7→ {title 7→ “Assab Eritrean ...”, . . .} expression is evaluated by referring to the values of other nodes
], near it in the tree.
google map 7→ . . . , . . . Just as a spreadsheet allows a user to edit a formula using
], . . . the formula bar, but avoids displaying the formula in the normal
], . . . display, MashMaker allows a user to edit the form arguments for a
] defined node using the form panel which pops down from the top
of the right hand side when a user clicks on its icon. For advanced
Somewhat unusually for a programming language, but entirely users, MashMaker also allows the user to turn on a spreadsheet-
in keeping with a file system, MashMaker allows identifier names style formula bar, which displays the current expression textually,
to contain spaces. in MashMaker’s underlying functional language.
MashMaker’s data representation is also heavily influenced by
XML6 . In particular, the idea of distinguishing between properties 2.3.1 Map and Fold
and children is taken from XML. The key differences are that, An appealing feature of spreadsheets is the way they allow a user
unlike XML, MashMaker allows properties to be arbitrary subtrees, to map a single expression over a collection of objects by simply
rather than just simple text, and MashMaker nodes do not have tag writing a formula in one cell, and then copying the expression to all
names. We believe that this representation is simpler for users to data rows below. This approach allows the user to easily see how
understand than XML, but it is close enough to XML that it is easy their expression is evaluated for each data element. MashMaker
to encode each in the other. takes a similar approach. If a user adds a new property to a node,
then similarly defined properties are automatically created for all
2.3 Learning from Spreadsheets
sibling nodes. For example, in Section 2.1, when the user added a
One of the key principles behind mashmaker is that users should google map to one apartment, a map was automatically added to
create mashups through “direct manipulation” of their data, rather all other apartments. All these expressions use the same defining
than writing an abstract program. To support this goal, we have expression, and when the user uses the form panel to change the
taken much inspiration from spreadsheets. arguments they change the arguments for all the other replicas too.
Spreadsheets have achieved remarkable success in allowing nor- As in a spreadsheet, a MashMaker user can easily look at a specific
mal users to write relatively complicated programs. One of the key application of the expression to some data and see directly how it
features that has allowed spreadsheets to do this is their avoidance evaluates.
of unnecessary separation between a program and the data it is Similarly, spreadsheets provide an easy way for users to fold an
working with. In a conventional programming language, the pro- operation over a collection of objects. fold is infamous within the
grammer writes a program in isolation of any argument data. As functional programming community as being a difficult function
they write this function, they must imagine what it will do with ar- for beginners; they either can’t remember the argument order, or
guments they might give it. By contrast, a spreadsheet avoids this they have difficulty thinking about exactly what a function will do
separation by allowing the programmer to apply operations directly when folded over a collection of data. However those same users
to a specific piece of data and then copying the operation to other have little difficulty performing fold operations in a spreadsheet.
data if it seems to work. In a spreadsheet, all a user has to do to fold their function over
MashMaker borrows six key features from spreadsheets: data rather than simply map it is write an expression that refers to
• Program and data mixed in one central workspace. the cell above, and then read out the final value from the bottom.
Following this example, MashMaker allows users to write fold-like
• All data is stored explicitly in the workspace. There are no operations using the built in “prev” property to refer to the previous
“local variables”. sibling. If there is no previous sibling then “prev” returns the value
• An expression is evaluated at a specific location, and refers to of the user-defined “init” property, or an empty value if this is not
other data relative to its current location. defined.
MashMaker also appropriates spreadsheet syntax for distin-
• Map and fold are described through direct manipulation of data,
guishing constants from expressions within the user interface. By
rather than using abstract functions. default, any text entered by a user is assumed to be a string con-
• Text entered by a user is assumed to be a constant, unless stant, unless it is proceeded by “=”. We chose this default partly
proceeded by “=”. because it is what users are familiar with and partly to avoid the
• Expressions re-evaluate automatically in response to changing need for beginning users to learn about expressions before they can
arguments7 . edit form arguments. This feature is not part of the textual repre-
sentation of the MashMaker language — it is simply part of the
6 Originally user interface.
our plan was to use XML as the data model, but we eventually
decided that a simplified model would be easier for users.
7 There are some systems issue here. In particular, how does one determine
2.4 Learning from Web Browsers
that a web site has changed, and how does one avoid querying a web site Another guiding principle of MashMaker is “program as you
too often? However these are off-topic for this paper, so we will not discuss browse”, meaning that creating a mashup should feel like the nor-
them further. mal web browsing process.
 The web browser is perhaps the most successful user interface 2. Normal Users: Occasionally expand the widget panel to edit
of modern times. This simple interface allows users to find infor- form parameters. The changes they make flow through into the
mation and perform sophisticated queries by merely following a suggestions made to all users.
sequence of links and occasionally typing data into forms. 3. Skilled Users: Connect up new sites that have not previously
MashMaker follows this model as much as possible. When a been connected, using copy and paste and simple expressions
user is looking at a particular node, MashMaker will automatically that refer to other properties.
suggest additional functions that they might want to apply by pro-
viding buttons across the top of the view pane (Figure 5). Clicking 4. Semi-Expert Users: Use semi-automated scraper-creation tools
on one of these buttons will insert a new node whose defining ex- (not yet written) to create scraper widgets for new web sites.
pression extracts data from the data already available (e.g. “food 5. Expert Users: Write complex expressions directly in Mash-
nearby” finds its address argument from the existing address prop- Maker’s core language.
erty).
The expectation is that most users of MashMaker will never use 6. Gurus: Teach MashMaker how to understand the content of new
the keyboard or expand the widget pane. Instead they will explore websites, either by uploading a hand-written XML description
their data entirely by clicking on MashMaker suggestions. In effect, (the current state), or by using an interactive tool (the future).
MashMaker extends the web browsing experience by adding new
We expect that each category will contain an order of magnitude
links that users can follow.
fewer people than the previous category. However, even though
The suggestions that MashMaker makes are derived from ob-
the number of highly skilled users may be small, their presence
servations of functions that other users have previously applied
is essential since it is they who import the web sites and write the
to similar-looking data, following the code sharing principle.
functions that less skilled users later use.
For example, in Section 2.1, once one user had added a node
to a Craigslist apartment whose defining expression was food
nearby = Yelp([address = address, what = "food"]), 3. The MashMaker Language
MashMaker will automatically suggest adding a node with the
In the previous sections we have explained the general model of
same definition for all other Craigslist apartments.
how MashMaker works and the mental model that it presents to
Another behavior that MashMaker borrows from web browsers
a user. In this section we will describe in more detail the func-
is bookmarks. If a user is using a web browser, they can use book-
tional programming language that is at the heart of MashMaker,
marks to remember interesting pages that they have found, or to
and in particular the concept of directories and tree extension (Sec-
share an interesting page with friends. The equivalent behavior in
tion 3.2).
MashMaker is user-defined widgets. To create a user defined wid-
get, the user navigates to an interesting result that they would like
3.1 Core Syntax
to remember for later or share with friends and clicks “bookmark
as new widget” (Figure 4). MashMaker will then prompt the user to Figure 1 gives the grammar for expressions in MashMaker’s core
select which of the nodes that the result depends on should be con- language. This grammar deals with a simplified version of the full
sidered arguments and which should be considered internal to the MashMaker language. In particular we omit the expression forms
function. Non-expert users will typically opt for the default — all for special built-in functions such as prev.
nodes the result depends on are internal, causing the entire mashup Values were described in Section 2.2. A value is either a con-
to be bookmarked, just as if the user had bookmarked a normal web stant file value (of arbitrary type), a directory with property and
page. child subnodes, or a lambda expression. A directory is either empty,
This approach allows users to experiment with their function or is a smaller directory that has been extended with an additional
on real data before abstracting it as a function. Perhaps more im- subnode8 . It is legal for a directory to contain multiple properties
portantly, it allows users to browse around aimlessly, looking for with the same name, however one will only be able to look up the
something interesting, without necessarily having to think in ad- value of the last one.
vance that they might be going to create a function at the end. Even MashMaker is dynamically typed, in common with the Lisp
when they do create a function, our intention is that they think of family of languages, and, of course, spreadsheets. If a dynamic type
what they are doing as bookmarking an interesting discovery, rather error occurs then the erroneous node’s text summary and view pane
than writing a function. will explain what went wrong.
An expression is evaluated with respect to its location in the data
tree. The location is represented as a stack of parent values, each of
2.5 Multi-Level MashMaking which is a directory. If an expression looks up a variable, the lookup
We have designed MashMaker with the intention that it should be is relative to the current location. The innermost directory value in
usable by anyone from a complete novice to an expert programmer the location is known as the context.
(following the “pay as you go” principle). In particular, we antici- Expressions take the following forms:
pate that users will use MashMaker at the following levels, where
each level requires a little more skill from the user and allows the • A literal constant c
user to do more powerful things: • An empty directory ∅
• An extension e n (q 7→ e0 ) adds a new subnode to e. e is
1. Basic Users: Never unfold the widget panel. They explore required to evaluate to a directory, and q is an extension path
their data purely by clicking on “Add to MashMaker” in their that says where the new subnode should appear. The expression
browser, and clicking on suggestion buttons to add enhance- e0 is evaluated at e, so e0 can refer to any properties in the
ments to their data. Basic users will sometimes bookmark directory that e evaluates to. We discuss extensions in more
things they find, using the default bookmark settings (Sec- detail in Section 3.2.
tion 2.4). Basic users do not even have to see the tree on the
left, since all the information they need is visible in the view 8 Note that, unlike normal list concatenation, we add new elements to the
pane on the right. end, rather than the beginning of a directory.
 For convenience, one can write [q0 7→ e0 , . . . , qn 7→ en ] as an
abbreviation for ∅ n (q0 7→ e0 ) n . . . n (qn 7→ en ). Good Food Nearby = λ(address).(
• A lambda expression λ(x0 . . . xn ).e.x defines a closure value [
whose arguments have names x0 . . . xn and whose body is the food nearby 7→ Yelp([what 7→ “food”, where 7→ address]),
expression e. The return value is computed by evaluating e to a good food nearby 7→ Filter([what 7→ food nearby, how 7→
directory and then selecting the property called x. MashMaker λ(distance, rating).(distance < 1) ∧ (rating > 5)]),
identifies function arguments by their label, rather than their ].good food nearby)
order. We can see that this function was created by copying the “food
For syntactic convenience, one can omit the final “.x” part of a nearby” and “good food nearby” properties out of the scratch-space
lambda expression, meaning that the result is the entire value, data tree, recording the fact that “address” was an external input,
rather than some property of it. and noting that “good food nearby” is the result value.
• A function application e (e0 ) applies e to e0 . e must evaluate to 3.3 Semantics
a function and e0 must evaluate to a directory with properties
matching the names of all the arguments of e. Figure 7 gives a big-step operational semantics for strict evaluation
of MashMaker expressions. The real semantics for MashMaker is
• Writing “this”, allows an expression to refer directly to the lazy, however this strict semantics allows us to more easily present
current location as a directory value. language constructs such as tree extension, without the distraction
• A path reference p looks up a property relative to the current of lazy evaluation. We discuss lazy evaluation more in Section 3.4.
location. By default, only properties in the current context are The evaluation relation is of the following form:
matched, but the !x form allows one to search the parent loca-
tions. s, e ⇓ v
where
3.2 Tree Extensions • s is the location at which the expression is evaluated. This is a
The key new construct in the MashMaker language is the tree stack of parent values, each of which is a directory value. The
extension: innermost parent value is known as the context. We write v : s
to denote a location with context v on top of the rest of the
location.
e n q 7→ e0
• e is the expression being evaluated
This construct is key to the connection between the core Mash- • v is the value that e evaluates to in the location s
Maker language and the MashMaker user interface, since it denotes
the action of adding new computed nodes to the data tree. In this Most of these rules should be easy to follow:
construct, e is the base of the current tree, q is a path to the position • (CONST) and (EMPTY) are already values, and so do nothing
at which the user has inserted a new node, and e0 is the expression
used to define the new node. • (EXTEND-NEW) adds a new subnode to a directory. The new
The path q can include the wildcard symbol, “∗”, meaning that node is evaluated in a context that includes all previous proper-
the rest of the path should be applied to all children. In fact, there is ties, but not any properties added to the directory subsequently.
no way to add a new subnode for just one child node. If one wishes • (EXTEND-EMPTY), (EXTEND-ALL) and (EXTEND-SKIP)
to add a subnode to one child node then one must add it to all of add an extension to all child nodes. (EXTEND-SKIP) skips
them. over property nodes, (EXTEND-ALL) extends the last child
Here is the simple expression that the user created interactively node, and then recursively extends the others.
in the example in Section 2.1.
• (EXTEND-PROP1) and (EXTEND-PROP2) extend a named
property. (EXTEND-PROP1) matches the last property and ex-
[ tends it. (EXTEND-PROP2) skips over a non-matching prop-
houses 7→ Craigslist Housing([area 7→ sfbay]), erty.
houses.*.map 7→ Google Maps([address 7→ address]), • (LAM) builds a closure, stashing the current location as the
food nearby 7→ Yelp([what 7→ “food”, where 7→ . . .]),
environment.
houses.*.food nearby 7→
Yelp([what 7→ “food”, where 7→ address]), • (APP) applies e to e0 . e is evaluated to a closure with body
houses.*.good food nearby 7→ e00 . e0 is evaluated to a directory v 00 . A new context is built by
Filter([what 7→ food nearby, how 7→ extending the closure environment with properties from v 00 that
λ(distance, rating).(distance < 1) ∧ (rating > 5)]), match the closure arguments. The closure body e00 is evaluated
] in this context and the property x is selected from the result.
• (THIS) simply grabs the current context value.
Here, we see that the user took Craigslist Housing and extended
it to add a new defined node called “map” inside each apartment. • (VAR), (FIELD), and (PARENT) follow a path from the current
The value of each map was computed with reference to the “ad- location.
dress” property of that apartment. The user also added an additional
top-level node called “food nearby” and defined “food nearby” and 3.4 Lazy Evaluation
“good food nearby” nodes for each apartment. Within the user in- Like Haskell (Peyton Jones 2003b), all MashMaker expressions are
terface, each of these defined nodes contains an internal reference evaluated lazily. The current consensus in the programming lan-
to the program subexpression that defines it, allowing the user to guage community seems to now be that lazy evaluation is the wrong
easily edit function arguments. evaluation model for conventional programming languages (Peyton
The user in that example also defined the following global function: Jones 2003a). This is because the bookkeeping overhead of lazy
 ( EXTEND - NEW ) ( EXTEND - EMPTY )
( CONST ) ( EMPTY ) s, e ⇓ v 0 v 0 : s, e0 ⇓ v s, e ⇓ ∅
s, c ⇓ c s, ∅ ⇓ ∅
s, e n k 7→ e ⇓ v 0 n (k 7→ v)
0
s, e n ∗.q 7→ e0 ⇓ ∅

( EXTEND - ALL ) ( EXTEND - SKIP )

s, e ⇓ v1 n (• 7→ v2 ) s, v1 n ∗.q 7→ e0 ⇓ v10 v10 : s, v2 n q 7→ v20 s, e ⇓ v1 n (x 7→ v2 ) s, v1 n ∗.q 7→ e0 ⇓ v10
0 0 0
s, e n ∗.q 7→ e ⇓ v1 n (• 7→ v2 ) s, e n ∗.q 7→ e ⇓ v10 n (x 7→ v2 )
0

( EXTEND - PROP 1) ( EXTEND - PROP 2)

s, e ⇓ v1 n (x 7→ v2 ) v1 : s, v2 n q 7→ e0 ⇓ v20 s, e ⇓ v1 n (x0 7→ v2 ) x 6= x0 s, v1 n x.q 7→ e0 ⇓ v10
s, e n x.q 7→ e0 ⇓ v1 n (x 7→ v20 ) s, e n x.q 7→ e0 ⇓ v10 n (x0 7→ v2 )

( LAM )
s, λ(x0 . . . xn ).e.x ⇓ (s, λ(x0 . . . xn ).e.x)

( APP )
s, e ⇓ (v 0 : s0 , λ(x0 . . . xn ).e00 .x)
s, e0 ⇓ v 00 (x0 7→ v0000 ) ∈ v 00 . . . (xn 7→ vn000 ) ∈ v 00 (v 0 n (x0 7→ v0000 )) n . . . n (xn 7→ vn000 ))) : s0 , e00 ⇓ v 0000 v 0000 : s, x ⇓ v
s, e(e0 ) ⇓ v

( VAR ) ( FIELD ) ( PARENT )

( THIS ) (x 7→ v) ∈ v 0 (x 7→ v 00 ) ∈ v 0 v 00 : v 0 : s, p ⇓ v s, p ⇓ v
v : s, this ⇓ v
v 0 : s, x ⇓ v v 0 : s, x.p ⇓ v 0
v : s, !.p ⇓ v

Figure 7. Operational semantics for strict MashMaker evaluation

evaluation makes programs run slowly, the complex evaluation be- marked as such and arguments explicitly listed, the user interface
havior makes performance hard to predict, and programmers often attempts to hide this from users as much as possible.
have to battle with space leaks due to long chains of lazy thunks. Although MashMaker is dynamically typed, the Widget meta-
MashMaker, however, is not a conventional programming lan- data for a function includes a flag for each argument saying whether
guage. We believe that the unusual application domain that Mash- it is a closure. If an argument is a closure then the forms UI inter-
Maker works in makes lazy evaluation highly appropriate. In par- prets text entered for that argument a little differently than for non-
ticular: closure arguments. Any text entered is assumed to be the body of a
lambda expression, and any variables in the expression that are not
• In the case of web mashups, the bookkeeping cost of remember- bound at the current location are assumed to be lambda arguments.
ing how to evaluate something is tiny compared to the massive Advanced users can tell that this alternative text handling is in use
cost of fetching and scraping a web site, thus it is only neces- by noticing a λ icon next to the argument text box.
sary for a very small number of expressions to be unneeded for
the bookkeeping cost to be more than paid back. 3.6 Live Data
• Even if fetching a web site was cheap, it is important for us to All data in MashMaker is live, meaning that it may change over
minimize the number of queries we make to a remote server, to time and will react to changes in other parts of the data tree. If a
avoid overwhelming a server (Section 3.7). tree is the result of a web query, then this tree will update over
• Typical mashup programs work with relatively small amounts time, as the source web site changes 9 .
of data that are not directly presented to the user, and so space The MashMaker language is designed to handle changing data
leaks are far less of a problem. well. In particular, since MashMaker overlays extensions over gen-
erated data (Section 3.2), rather than modifying it in-place, these
• Many web sites are already essentially lazy. For example when extensions will be automatically applied to new versions of the
one makes a search using Google, it does not return all results underlying data. Also, since the MashMaker extension construct
in one page, but instead produces results lazily as one presses automatically adds new properties to all children of a node, these
the “next” buttons. properties will also apply to any new children that are added to the
tree.
MashMaker’s lazy evaluation works largely as one would ex-
pect. The value of a node is only evaluated when it is either de- 3.7 Throttling
manded by the evaluation of another node, or the user attempts to
One important practical issue that has to be dealt with whenever
view it through the graphical interface.
one creates a mashup is the need to avoid placing too much load on
the web sites supplying data. If one has an agreement with the web
3.5 Lambda Expressions in the User Interface site provider then it is likely to specify a maximum load, and if one
The MashMaker user interface has somewhat unusual treatment
of lambda expressions. While the syntax in the underlying core 9 Either by polling the web site at a fixed frequency, or waiting until the user
language is fairly conventional, with lambda expressions explicitly asks for a refresh.
does not have an explicit agreement then placing too much load on Abstraction gra- What are the minimum and maximum lev-
a server could cause the owners to block the mashup system’s IP dient els of abstraction? Can fragments be encap-
address. sulated?
As a result of this, it is necessary for MashMaker to throttle the Consistency When some of the language has been learnt,
rate at which requests can be made to external web sites. Indeed this how much of the rest can be inferred?
rate is one of the primary issues that determines the performance of Error-proneness Does the design of the notation induce
a Mashup, since if a mashup needs to make too many requests, then ‘careless mistakes’?
it will have to slow itself down in order to avoid sending requests Hidden depen- Is every dependency overtly indicated in
too rapidly. This performance restriction has motivated MashMaker dencies both directions? Is the indication perceptual
not only to use lazy evaluation (Section 3.4), but also to use a or only symbolic?
number of other tricks (not discussed in this paper) to minimize the Premature com- Do programmers have to make decisions
number of requests that need to be made to external web servers. mitment before they have the information they need?
Progressive Can a partially-complete program be exe-
3.8 When Websites turn Bad evaluation cuted to obtain feedback on “how am I do-
One limitation of MashMaker, as with most other tools that scrape ing”?
information from web sites, is that mashups can break if the under- Role- Can the reader see how each component of
lying websites change. If a website changes the structure of the data expressiveness a program relates to the whole?
it produces, or changes its HTML such that the current scraper no Viscosity How much effort is required to perform a
longer understands it, then mashups that depend on this data will single change?
no longer function correctly. In the long term, we hope this this Visibility and Is every part of the code simultaneously vis-
problem will become less severe as websites increasingly publish juxtaposability ible (assuming a large enough display), or
semantic information in well defined data formats. is it at least possible to compare any two
More generally, MashMaker is not intended to be used for parts side-by-side at will? If the code is dis-
“mission critical” applications where data integrity is essential. persed, is it at least possible to know in what
Instead, its focus is on applications where it is more important to order to read it?
be able to produce interesting data than to be certain that the data
is correct. Figure 8. Cognitive Dimensions (taken from Peyton Jones et al.
2003)
4. Evaluating Usability
Following Peyton Jones et al. (2003), we evaluate the usability of
MashMaker using the Cognitive Dimensions of Notations (CDs) then this does not affect the behavior of non-dependent parts of
framework (Blackwell et al. 2001). CDs provide a vocabulary that the program.
enumerates concepts important to users who are engaged in pro- • Viscosity: MashMaker’s support for user-defined functions, au-
gramming tasks. While evaluation against cognitive dimensions is tomatic synchronization of property definitions across multiple
subjective, and is not a substitute for thorough user testing, these children, and its general preference for linking of data rather
concepts have been shown over time to be important to human than copying, make it easy to make widespread changes.
problem solving and it is important to consider each when design- • Visibility and Juxtaposability: Unlike conventional program-
ing a usable interface. We list the cognitive dimensions in Figure 8 ming languages, MashMaker juxtaposes program and data to-
and evaluate MashMaker against these dimensions below: gether, so the programmer can easily see the effects of evaluat-
• Abstraction Gradient: MashMaker can be used at a number ing their expressions. While MashMaker does not allow one to
of different levels of abstraction, allowing use by users rang- view multiple forms or multiple view panels in the same win-
ing from complete beginner to experienced programmer (Sec- dow, MashMaker does allow one to view the same data store
tion 2.5). with multiple browser windows, allowing one to put arbitrary
information side-by-side.
• Consistency: New widgets are created using the same mecha-
nism as creating simple expressions. All work in MashMaker Based on this analysis, and also our personal experiences using
is done using the same simple mechanism of applying widgets MashMaker, we believe that our design is fundamentally sound.
and setting form parameters. However, in order to demonstrate this objectively, we need to per-
• Error Proneness: Unlike normal spreadsheets, MashMaker
form a proper user study, and indeed we intend to do this in the near
future.
automatically ensures that when a user adds a property to a set
of children the defining expression is identical for all children.
5. Related Work
• Hidden Dependencies and Role Expressiveness: When a
node is selected, all dependent or source nodes are automat- In this section, we explain how MashMaker relates to previous
ically highlighted to make it clear that there is a dependency. work on Mashup creation and end-user programming in general.
In prior work, we described the basic MashMaker tool from a
• Premature Commitment: Users do not have to decide in ad- database angle (Ennals and Garofalakis 2007).
vance what they are looking for, but instead can wander aim-
lessly, looking for something useful. If they find something they 5.1 Mashup Creation Tools
like, they can bookmark it as a new function widget, but they Mashups are an increasingly hot topic, and thus there have been
need not decide in advance that this is what they are going to many efforts to simplify their creation. Relative to MashMaker,
do. these previous tools generally fall into two groups: those which
• Progressive Evaluation: There is no requirement that a pro- are easy to use, but can only create a limited family of mashups;
gram be in any sense “complete” in order for the user to look at and those which are relatively difficult to use, but can create a wide
its result. Similarly, like a spreadsheet, if some evaluations fail range of mashups.
 Google MyMaps 10 and MapCruncher 11 make it easy for end TreeSheet (Leonard 2004) represents data as an XML tree, but
users to create mashups involving maps. Swivel.com makes it very unlike MashMaker, programming is done using imperative scripts,
easy for end users to create graph mashups from multiple data rather than functional overlays.
tables. However, while each of these tools is easy to use, and Within the database community, SEMEX (Cai et al. 2005) and
excellent at producing mashups of a specific type, none of them DataSpaces (Franklin et al. 2005) have looked at data-integration –
is as general purpose as MashMaker. how to get transform various data sources into a suitable structure
Yahoo Pipes 12 is a powerful tool that allows users to process so that they can be combined with queries.
data from RSS feeds. While, at the time of writing, the small
set of operations available in Pipes makes it less flexible than 5.2 End-User Programming Tools
MashMaker, it seems likely that the tool will be extended to give it MashMaker also bears some similarity to a number of end-user pro-
equivalent expressive power. The key difference between Pipes and gramming tools that have not been used for creating web mashups:
MashMaker is that, unlike MashMaker, pipes presents the program Programmable Structured Documents (PSDs) (Takeichi et al.
as an explicit graphical dataflow graph, rather than mixing it with 2003; Hu et al. 2004; Liu et al. 2005) allow one to extend a stan-
the data being browsed. dard XML document by embedding elements in the tree that are
Marmite (Wong and Hong 2006) takes a pipeline-based ap- computed from other elements. An expression defining an XML
proach, similar to Apple’s Automator 13 . The data from a web site node can refer to other nodes using XPath expressions and then pro-
is routed through a sequence of pipeline stages, each of which is cess the nodes using arbitrary Haskell functions. Like MashMaker,
configurable, and can produce data of a different type. Like Yahoo PSDs are based on a functional language (in this case Haskell) and
Pipes, the program is separated from the data and presented as a are evaluated lazily. Unlike MashMaker PSDs deal with static XML
graph, rather than being embedded in the data like a spreadsheet. documents, rather than live data. Indeed, since PSDs include ex-
Like MashMaker, Marmite will automatically suggest operations to pressions directly in a document, rather that overlaying changes on
apply to data. Unlike MashMaker, these suggestions are based on top of generated data in a way that can be automatically re-applied,
the type of the data (similar to Jungloids (Mandelin et al. 2005)), they could not be used to add additional properties to live data with-
rather than based on the behavior of previous users. Anthracite 14 out changes to the model (Section 3.6).
is similar to Marmite, but requires that the user be familiar with Subtext (Edwards 2005) is a programming tool that allows one
complex concepts such as HTML and regular expressions. to look at a program together with the results of its evaluation. In
Creo (Faaborg and Lieberman 2006) augments web pages with Subtext, every node in the data tree corresponds to the execution of
additional links that can obtain additional information about items a single program line with specific data and is annotated with the
on a web page. Like MashMaker, Creo will automatically make value produced. Function calls are expanded as subtrees and func-
suggestions and can learn by example from things that users do tion definitions contain example arguments that the programmer
with their data. Unlike MashMaker, Creo is limited to adding addi- can adjust to interactively see how their program will behave. Like
tional hyperlinks to web pages and cannot perform bulk data pro- MashMaker, subtext allows programmers to easily see how their
cessing tasks. program will behave when applied to particular arguments. Unlike
Google Mashup Editor, Plagger.org, Ning.com, Javascript Dataflow MashMaker, the Subtext interface is program-centric, rather than
Architecture (Lim and Lucas 2006), and Web Mashup Scripting data-centric — meaning that data is layered on top of a program,
Language (Sabbouh et al. 2007) are powerful tools for creating rather than overlaying a program on top of data.
mashups, but they require that the user write code. MashMaker’s function creation system is influenced by the
ClearSpring.com, Widsets.com, WidgetBox.com, and Apple’s work of Peyton Jones et al. (2003) in extending Microsoft Excel to
Dashboard 15 allow users to write small graphical web widgets support user-defined functions. Like MashMaker, they allow one
and then lay them out together on a screen. DataMashups.com to define a new function by selecting a result cell and then using a
additionally allows users to connect these widgets together (e.g. graphical interface to specify which other cells are arguments.
the output of this widget is the input to that widget), but complex MashMaker’s suggestion system is influenced by Jungloids (Man-
tasks require considerable programmer skill. delin et al. 2005) and Google Suggest 16 . Like Jungloids, Mash-
HunterGatherer (Schraefel et al. 2002) and Internet Scrap- Maker suggests operations that are appropriate to the data one has
book (Sugiura and Koseki 1998) allow users to extract parts of at hand. Like Google Suggest, MashMaker learns from the behav-
multiple web sites and composite them together, but are not able to ior of other users.
perform complex processing on these sites and extract collections More generally, MashMaker draws on past work on Program-
of data. ming by Example (Cypher et al. 1993; Lieberman 2001), and pre-
Like MashMaker, C3W (Fujima et al. 2004) uses a spreadsheet vious work on programming approaches for beginners (Kelleher
metaphor. C3W uses a standard flat two-dimensional spreadsheet and Pausch 2005).
to connect web sites together. If a user defines values for a web
site’s input cells, then it will produce results in its output cells, 6. Conclusions
clipped from the web page. Unlike MashMaker, C3W uses a flat
two dimensional grid, rather than a tree. This prevents one writing We have presented MashMaker, a tool that allows end-users to
mashups that produce nested data, such as producing a list of easily create web mashups. While MashMaker is, at its core, a
restaurants for each of several apartments. functional language, it contains a number of deviations from the
standard functional paradigm. By taking ideas from such popular
tools as file systems, spreadsheets, and web browsers, we have
produced a tool that we believe is well suited to the task of mashup
10 http://maps.google.com creation.
11 http://research.microsoft.com/mapcruncher This project is interesting as a programming language research
12 http://pipes.yahoo.com project both because it approaches an application domain for which
13 http://www.apple.com/ programming languages have not historically been seen as the solu-
14 http://www.metafly.com/products/anthracite
tion, and also because, in the process of fitting our language to this
15 http://www.apple.com/ 16 http://labs.google.com/suggest/
domain, we have produced a language that has many differences Caitlin Kelleher and Randy Pausch. Lowering the barriers to programming:
from previous functional languages. A taxonomy of programming environments and languages for novice
We have implemented MashMaker as an AJAX web applica- programmers. ACM Comput. Surv., 37(2):83–137, 2005. ISSN 0360-
tion, currently made available within our organization as part of 0300. doi: http://doi.acm.org/10.1145/1089733.1089734.
a closed beta program. We plan to make it publically available in Thomas Leonard. Tree-Sheets and Structured Documents. PhD thesis,
the near future. In the long term, the success of MashMaker will University of Southampton, 2004.
be judged based on the extent to which real users adopt it, and the Henry Lieberman. Your wish is my command: programming by example.
scale of the benefit they are able to obtain from it. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2001.
For more information on MashMaker, and access to the public ISBN 1-55860-688-2.
beta when it opens, please go to the following url: Seung Chan Slim Lim and Peter Lucas. Jda: a step towards large-scale
http://berkeley.intel-research.net/rennals/mashmaker/ reuse on the web. In OOPSLA ’06: Companion to the 21st ACM SIG-
mashmaker.html PLAN conference on Object-oriented programming systems, languages,
and applications, pages 586–601, New York, NY, USA, 2006. ACM
Press. ISBN 1-59593-491-X. doi: http://doi.acm.org/10.1145/1176617.
Acknowledgments 1176631.

This work has benefited from the input of many people. Particular Dongxi Liu, Zhenjiang Hu, and Masato Takeichi. An environment for main-
taining computation dependency in XML documents. In DocEng ’05:
thanks should go to Minos Garofalakis, Eric Paulos, and Ian Smith. Proceedings of the 2005 ACM symposium on Document engineering,
pages 42–51, New York, NY, USA, 2005. ACM Press. ISBN 1-59593-
240-2. doi: http://doi.acm.org/10.1145/1096601.1096616.
References David Mandelin, Lin Xu, Rastislav Bodik, and Doug Kimelman. Jungloid
Alan F. Blackwell, Carol Britton, Anna Louise Cox, Thomas R. G. Green, mining: helping to navigate the API jungle. In PLDI ’05: Proceedings of
Corin A. Gurr, Gada F. Kadoda, Maria Kutar, Martin Loomes, Chrysto- the 2005 ACM SIGPLAN conference on Programming language design
pher L. Nehaniv, Marian Petre, Chris Roast, Chris Roe, Allan Wong, and implementation, pages 48–61, New York, NY, USA, 2005. ACM
and Richard M. Young. Cognitive dimensions of notations: Design tools Press. ISBN 1-59593-056-6. doi: http://doi.acm.org/10.1145/1065010.
for cognitive technology. In CT ’01: Proceedings of the 4th Interna- 1065018.
tional Conference on Cognitive Technology, pages 325–341, London,
Simon Peyton Jones. Wearing the hair shirt: a retrospective on Haskell
UK, 2001. Springer-Verlag. ISBN 3-540-42406-7.
(invited talk). In ACM SIGPLAN Conferenge on Principles of Program-
Yuhan Cai, Xin Luna Dong, Alon Halevy, Jing Michelle Liu, and Jayant ming Languages (POPL’03), 2003a.
Madhavan. Personal information management with SEMEX. In SIG-
Simon Peyton Jones, editor. Haskell 98 Language and Libraries: the
MOD ’05: Proceedings of the 2005 ACM SIGMOD international con-
Revised Report. Cambridge University Press, may 2003b.
ference on Management of data, pages 921–923, New York, NY, USA,
2005. ACM Press. ISBN 1-59593-060-4. doi: http://doi.acm.org/10. Simon Peyton Jones, Alan Blackwell, and Margaret Burnett. A user-centred
1145/1066157.1066289. approach to functions in Excel. In ICFP ’03: Proceedings of the eighth
ACM SIGPLAN international conference on Functional programming,
Allen Cypher, Daniel C. Halbert, David Kurlander, Henry Lieberman,
pages 165–176, New York, NY, USA, 2003. ACM Press. ISBN 1-58113-
David Maulsby, Brad A. Myers, and Alan Turransky, editors. Watch
756-7. doi: http://doi.acm.org/10.1145/944705.944721.
what I do: programming by demonstration. MIT Press, Cambridge, MA,
USA, 1993. ISBN 0-262-03213-9. Marwan Sabbouh, Jeff Higginson, Danny Gagne, and Salim Semy. Web
mashup scripting language (poster). In 16th International World Wide
Jonathan Edwards. Subtext: uncovering the simplicity of programming. In
Web Conference, 2007.
OOPSLA ’05: Proceedings of the 20th annual ACM SIGPLAN confer-
ence on Object oriented programming, systems, languages, and applica- M. C. Schraefel, Daniel Wigdor, Yuxiang Zhu, and David Modjeska. Hunter
tions, pages 505–518, New York, NY, USA, 2005. ACM Press. ISBN gatherer: within-web-page collection making. In CHI ’02: CHI ’02
1-59593-031-0. doi: http://doi.acm.org/10.1145/1094811.1094851. extended abstracts on Human factors in computing systems, pages 826–
827, New York, NY, USA, 2002. ACM Press. ISBN 1-58113-454-1. doi:
Robert Ennals and Minos Garofalakis. Mashmaker : Mashups for the
http://doi.acm.org/10.1145/506443.506617.
masses (demo paper). In Proceedings of the 2007 ACM SIGMOD
International Conference on Management of Data (SIGMOD’2007), Michael Schrenk. Webbots, Spiders, and Screen Scrapers. No Starch Press,
2007. 2007.
Alexander Faaborg and Henry Lieberman. A goal-oriented web browser. In Atsushi Sugiura and Yoshiyuki Koseki. Internet scrapbook: automating web
CHI ’06: Proceedings of the SIGCHI conference on Human Factors in browsing tasks by demonstration. In UIST ’98: Proceedings of the 11th
computing systems, pages 751–760, New York, NY, USA, 2006. ACM annual ACM symposium on User interface software and technology,
Press. ISBN 1-59593-372-7. doi: http://doi.acm.org/10.1145/1124772. pages 9–18, New York, NY, USA, 1998. ACM Press. ISBN 1-58113-
1124883. 034-1. doi: http://doi.acm.org/10.1145/288392.288395.
Michael Franklin, Alan Halevy, and David Maier. From databases to datas- Masato Takeichi, Zhenjiang Hu, Kazuhiko Kakehi, Yashushi Hayashi, Shin-
paces: A new abstraction for information management. In SIGMOD Cheng Mu, and Keisuke Nakano. TreeCalc: towards programmable
Record, 2005. structured documents. In Japan Society for Software Science and Tech-
nology, 2003.
Jun Fujima, Aran Lunzer, Kasper Hornbæk, and Yuzuru Tanaka. Clip, con-
nect, clone: combining application elements to build custom interfaces Jeffrey Wong and Jason Hong. Marmite: end-user programming for the
for information access. In UIST ’04: Proceedings of the 17th annual web. In CHI ’06: CHI ’06 extended abstracts on Human factors in
ACM symposium on User interface software and technology, pages 175– computing systems, pages 1541–1546, New York, NY, USA, 2006. ACM
184, New York, NY, USA, 2004. ACM Press. ISBN 1-58113-957-8. doi: Press. ISBN 1-59593-298-4. doi: http://doi.acm.org/10.1145/1125451.
http://doi.acm.org/10.1145/1029632.1029664. 1125733.
Zhenjiang Hu, Shin-Cheng Mu, and Masato Takeichi. A programmable
editor for developing structured documents based on bidirectional trans-
formations. In PEPM ’04: Proceedings of the 2004 ACM SIGPLAN
symposium on Partial evaluation and semantics-based program manip-
ulation, pages 178–189, New York, NY, USA, 2004. ACM Press. ISBN
1-58113-835-0. doi: http://doi.acm.org/10.1145/1014007.1014025.