**3. Web mashups**

Web mashups allow end-users to build applications by integrating data and functionalities from various web services into a single application. The visual web mashup programming environments facilitate easy creation of applications by enduser programmers who have very little knowledge and experience in programming. Mashup environments provide a full set of functions to the end-users to build new applications.

End-users often create situational mashups as per their specifications [44]. For example, a mashup can take data from Instagram and combine it with Google Maps to display the most recent images and videos of any given location. Users can get the data from APIs, Information Feeds (e.g., Really Simple Syndication (RSS)), or they can collect data by scraping various web pages. Mashup application can be executed within the client's browser, in a server, or combination of both. The advantage of rendering the application in a client's web browser is to give users the opportunity to interact with it. Mashups are popular because of their dynamic content creation and ability to build and share applications through publicly hosted repositories [45].

End-users often develop mashup applications using visual black-box oriented programming environments. Mashup programming environments such as Yahoo! Pipes [2], IBM mashup maker [3], xfruit [4], Apatar [5], Deri Pipes [6], and JackBe [7] provide an easy-to-use visual environment to support the mashup development. Cappiello at el. [46] researched mashup development frameworks oriented towards end-user development to allow users to compose different resources at different levels of granularity relying on the user interface (UI) of the application. Ennals and Gay created MashMaker [24], a tool which allowed end-users to create web mashups without needing to write much code/script. Other mashup creation tools to facilitate end user programmers include MapCruncher [25], Marmite [26], Automator [27], Creo [28], and TreeSheet [47]. Rather than directly studying mashup environments or creating new mashup tools, we qualitatively observe how end-users debug and forage for solutions in programs built in these mashups.

Grammel and Storey [9] investigated various mashup development environments and found lack of debugging support in these environments. Similarly, Stolee and Elbaum [48] studied how we can improve the refactoring of pipe-like mashups, i.e., Yahoo! Pipes for end-users. We focus on understanding end-user programmers' behavior while debugging mashups instead of creating support for mashups.

#### **3.1 Yahoo! Pipes**

Now defunct, Yahoo! Pipes was introduced in 2007 and was one of the most popular mashup creation environments that helped users to "rewrite the web" during its existence. During its first year of existence, the Yahoo! Pipes platform executed over 5,000,000 pipes per day. As a visual programming environment, Yahoo! Pipes was well suited for representing the solutions to dataflow-based processing problems. Yahoo! Pipes "programs" helped in combining simple commands together such that the output of one acted as the input for the other. The Yahoo! Pipes engine also facilitated the wiring of modules together and the transfer of data between them.

The Yahoo! Pipes environment was made up of three major components: the canvas, the library (list of modules), and the debugger (refer **Figure 1**). Users used the canvas to create the pipes. The library situated to the left of the canvas, consisted of various modules that were categorized according to functionality. Users dragged modules from the library and placed them on the canvas, then proceeded to connect them to other modules as their need. The debugger, located at the bottom, helped users check the runtime output of the modules.

**Figure 1.** *Yahoo! Pipes.*

The inputs and output of the pipes supported different formats. For input, most common formats were APIs, HTML, XML, JSON, RDF, and RSS feeds. Similarly, pipe output formats were RSS, JSON, and KML. The inputs and outputs between modules were primarily RSS feed items consisting of parameters and descriptions. Yahoo! Pipes modules provided manipulation actions that could be executed on these RSS feed parameters. In addition to items, Yahoo! Pipes also allowed datatypes like URL, location, text, number, and date-time to be defined by users.

**Figure 1** shows the interface and components of the Yahoo! Pipes environment. The pipe displayed in the figure takes Reuter's Newsfeed (RSS feed) as input using a Fetch Feed module which is then filtered (using a Filter module) based on users' input (sports). These results are converted from English to Greek using a Translate module inside a Loop module. The pipe titles are limited to the first seven results using the truncate module. In **Figure 1**, the debugger window displays the runtime output from the Fetch Feed module.

Yahoo! Pipes allowed the creation and rendering of the pipes on the client side while the executing and storing of the pipe was done on the Yahoo! Servers. The data between the client and server was transfer using JSON format. Yahoo! Pipes allowed end-users to share their pipe (code) as well as reuse other user's pipes by cloning.

Stolee et al. [49] analyzed 32,000 mashups from Yahoo! Pipes repositories based on popularity, configurability, complexity, and diversity. Wang and Wang [50] used Yahoo! Pipes to build a mobile news aggregator application. We used Yahoo! Pipes for this study as it had the best debugging support at the time of the research.
