Usage of the Web for Various Prototyping Scenarios

Usage of the Web for Various Prototyping Scenarios Markus Zimmermann Abstract—The emergence of new techniques for the web like JavaScript and AJAX and strong network technologies and servers are empowering software developers to create vivid web applications. In this paper we will analyze the benefits of web applications for one of the first steps in software development, the prototyping process. In combination with a vast amount of public accessible APIs, a web prototype can be simply mashed by combining different data and presentation sources, that are easily wired with code (those products are called a mashup). This paper will have a look at some projects, which employed this new prototyping approach by gathering the main findings of the corresponding studies: high fidelity prototypes through low effort. In addition, the used frameworks for rapidly creating web mashups will be figured out. Index Terms—Web, Internet, Rapid, Prototyping, Mashup, API, AJAX

1 I NTRODUCTION AND OVERVIEW At the same time Eric Knorr produced the term Web 2.0 in late 2003 [20] because of the ”genuinely new technology” in the web, he diagnosed that web services have reached a sufficient level to be an alternative to proprietary middleware (at least for new, not established projects). Now, six years later, we take a step forward and explore, how the web can be (and already has been) involved in the development process of new applications, especially the task of prototyping. First, we will analyze the technological principles of the Web 2.0 and examine the evolution that allows the development of web applications. This will lead us to Patchwork Prototyping by mashups. Second, we will apply ourselves to different frameworks, that are useful for rapid web prototyping without distinct knowledge of details. Third, we will emblaze different studies that attend to various web prototypes compared to traditional prototypes or existing products. In conclusion we will put all findings of web prototypes in context and lift web-prototyping out of different prototyping approaches. 2

E MERGENCE OF N EW T ECHNOLOGIES D EVELOPMENT

FOR

R APID W EB

Development of new techniques not only made it possible to display static hypertext sites, but also to dynamically create highly interactive web-applications, where client and server are closely interacting (a precondition for web-applications in general). As there are several technologies available, we will highlight the well-established techniques: PHP and MySQL as representatives of approaches on the server side. DHTML, JavaScript and CSS on top of all modern browsers, as well as helpers like Libraries and the new technology AJAX and different Application Programming Interfaces (APIs) . 2.1

Server-Side: PHP and MySQL

MySQL stands for My Structured Query Language, which is a free software for all major server platforms for accessing databases and tables on a web server. The user can put, modify and delete data in the tables and fetch the entries easily by requesting queries like SELECT * FROM staff WHERE name = ’Smith’ (which will result in a list of all employees called ”Smith”). MySQL has a comfortable interface to PHP. [22] By combining the scripting language PHP with the database MySQL, it is possible to dynamically create actual or even live content out of a huge stock of data, where the contemporary appropriation of the same data as a static web document would have been impossible. 2.2 Client-Side: DHTML, Javascript, CSS and Libraries While the server is responsible for creating and delivering content, the experience of interacting with an application comes up on the client-side: Data has to be rendered, formatted and conditionally modified. The user input has to be collected, evaluated and delivered to the server. Most browsers are standard-conform by now, so in the recent years it became possible to create and style applications for all browsers by joining the technologies (each in detail described by Christian Wenz [27]) DHTML for website modification, the browser scripting language JavaScript and the formatting-language CSS. Libraries make the usage and combination of all techniques easier. DHTML stands for Dynamic HTML and allows the programmer to modify a website dynamically. While static websites stay changeless after loading them, DHTML (also known as DOMScripting) affects style and function of elements like images or paragraphs on the webpage when needed (for example by a JavaScript call).

The scripting language PHP and the database engine MySQL are popular for creating web applications and often used in combination, so that most users mention them in one breath. Both Systems are robust, approved and work with good performance. So significant and high traffic websites like Wikipedia[28], YouTube[15] or Facebook[7] use these two technologies for their service.

JavaScript is a modern, object oriented scripting language executed in the web browser (with a java-like syntax). JavaScript enables the web designer to validate user input on the client side, to manipulate the website via DHTML/DOM and to compute, send and receive data.

PHP (PHP: Hypertext Preprocessor) was originally created as a toolkit for personal home pages, then continuously developed towards a free and general purpose scripting language. PHP can be embedded into a classic HTML page. The code is evaluated by the web server when the user invokes the website. [13]

CSS is a style-sheet markup language for appealing design of web pages and applications. As a powerful amendment of HTML or XML it can be used for formatting structured content (for example adjusting color, position, size or spacing of elements). Individual objects can be modified as well as it is possible to define central formats for classes of elements.

• Markus Zimmermann is studying Media Informatics at the University of Munich, Germany, E-mail: [email protected] • This research paper was written for the Media Informatics Advanced Seminar on Prototyping, 2009/2010

Libraries such as Prototype [25] (helper functions for JavaScript development) and the Dojo toolkit [9] (various user interface elements for JavaScript) provide a comfortable way for solving recurring tasks. For example requesting data from a server, DHTML/DOM modifications in the document or creating complex input elements like menus and calendars or drag-and-drop functionality.

2.3

Interaction: AJAX

Classic web interaction is limited to a hypertext structure: Whenever the displayed page or information is needed to be changed, this is accompanied by a reload of the whole page. This basic and slow interaction mechanism was the only way of web interaction for a long time. JavaScript improves the scope, but traditionally could not gather completely different data than delivered with the first page load. In 1998, Microsoft developed a remote scripting component, enabling a web access interface for the Outlook email client (first as a java applet, then directly supported by their browser, the InternetExplorer, as a XMLHttpRequest-Object). Microsoft’s (and analog) approaches allowed the background loading of data without the need for refreshing the whole page. Google adopted this technology for the Google Suggest functionality: when you start typing new york, the part new y is enough for Google to autocomplete the possible search terms New York City or New York Times. All the loading is done in the background, without the page’s reload. The term AJAX was first mentioned by J. J. Garrett [10] in 2005: He called the technique of dynamical loading data in the background Asynchronous JavaScript + XML, ”a fundamental shift in what is possible on the Web”, featured by the mentioned technologies HTML (and its ”dialect” XML), DOM, JavaScript and the XMLHttpRequest.

The most popular services are (the numbers represent the APIs’ usage based on 4506 analyzed mashups): • Google Maps API [11] for geographical information and browsing maps (1867) • Flickr API [29] for photo acquisition (488) • YouTube API [12] to get any video content (429) • Amazon API [1] for book information retrieval (327) With the help of all the so far considered technologies and tools, combined with API service calls, it is possible to create entirely new web services by wiring the chunks and foreign informations, commonly known as mashups. 3 U TILITIES FOR CREATING P ROTOTYPES IN THE W EB Because of the simplicity of creating mashups, those can be used as rapid prototypes of future software products. The developer has no need to create dummy content close to reality and is able to reach a high fidelity prototype level without taking care of details. We will distinguish between different integratable content: Foreign data (like metadata gathered from a Music Database), applications/services and presentation (e.g. display maps from Google) and look on different toolkits and frameworks valuable for a rapid prototyping process. 3.1 Mashups and Patchwork Prototyping In 2007, Ingbert R. Floyd [8] did a research called Web Mashups and Patchwork Prototyping about novel practices in development with Web 2.0, open APIs and open source systems. He introductorily describes the two terms as following: Mashups are websites combining data and services from multiple sources, all across the web, conceptually like a DJ creating a remix of multiple music sources. Mashups are being used for ”rapid realization of creative ideas which would be too time consuming or expensive”. A requirement for a mashup are public accessible APIs and data sources and the detailed knowledge about how to access them. This barrier can be lowered by the toolkits described in the following sections. Patchwork Prototypes ”use combinations of web services, mashups, locally developed code and open source software”. They reduce development periods by rapid iteration cycles, incorporation of the prototype in the users’ daily activities, and massive user feedback. The prototypes’ innovations are user-driven.

Fig. 1. Classic and AJAX web application model (original image in [10])

AJAX’ mode of operation is described in figure 1: While a classic web application is just based on interaction between a browser (requesting pages on the client side) and a server (delivering the content gathered from various sources), the AJAX approach has an additional intermediary service level, the ajax engine (the simplest case is a single XMLHttpRequest), which requests (unformatted) content from the existing server infrastructure and attends to the styling and integration on client side. We can contend that AJAX is rather a paradigm than a technology, powerful in combination with the well-established web techniques. 2.4

Application Programming Interfaces

An aspect of Web 2.0 are the various and public available data and presentation sources from anywhere in the web. Content providers allow users to connect to their applications and retrieve information like database records, product informations or even graphical data like pictures, videos or maps. ProgrammableWeb [23], an API database, announces over 1.500 public accessible APIs by the end of 2009.

Fig. 2. Wikipedia-Amazon Search And Browse Environment, a simple mashup (original image in [8])

As an example for creating a mashup as a patchwork prototype, Floyd developed Wasabe (see figure 2) ”as a prototype hybrid library

catalog system that allows users to search within a single interface both the detailed bibliographic information typically found in library catalogs as well as more general information about the topic of interest, typically found in encyclopedias” [8]. Wasabe used the Amazon API, the Google Search API and Wikipedia as additional data source. The first prototype of Wasabe has been created in less than ten minutes. The prototypes’ successor is now present and used in the A9 search engine. He compared mashups to patchwork prototypes and found similarities: Technical innovations are user driven (that means better software through involved users). Although the methods are not new, Floyd finds out that technological innovations made patchwork prototyping affordable for single persons and small companies without hiring experts. Nearly isochronal Cameron M. Jones [18] released his study Patching Together Prototypes on the Web with the same awareness: ”Patchwork prototyping is a rapid prototyping approach” that saves speed and cost but also creates depth and high functional, high fidelity prototypes through mashups. By incorporation in the users’ daily work, fast feedback can be gained while all the features and functionalities of the prototype are disposable. 3.2

Data Integration

A problem for a mashed-up web application or web patchwork prototype (in the following both are meant equally) is receiving data that is not reachable via API services or existent databases but only visible as a website or as the output of a present software. An experienced software developer would write some kind of converter. But in terms of rapid prototyping that is neither economic nor fast or universal enough. The solution could be programming by example, Rattapoom Tuchindra [26] created ”a Mashup building approach that combines most problem areas in Mashup building into a unified interactive framework that requires no widgets, and allows users with no programming background to easily create Mashups by example” called Karma (see figure 3).

Fig. 3. The Karma interface: On the left an embedded browser, on the right a table for data extraction (original image in [26])

A prototype developer only has to browse a website with Karma and show the software where a data input (for example the search field) is located and how the resulting output is aligned (for example a table with corresponding names on the left and descriptions on the right). The extracted data sets can be included directly into the prototype. 3.3

wiki. Thence the content and service call are hosted, can be modified and easily be integrated into a prototype.

Fig. 4. Example of d.mix mappings between HTML elements and corresponding API service calls: Flickr Title, Image URL and Taglist retrieval (original image in [14])

3.4 Presentation Integration As an alternative to AJAX (where JavaScript renders new content without reload), Jin Yu et al. created the presentation layer OpenXUP [30], an approach for creating highly interactive web user interfaces, consisting of a event driven thin client and server toolkit. It is based on the Simple Object Access Protocol (SOAP) and the Extensible User Interface Protocol (XUP). SOAP is a technology for calling procedures on the server and exchanging data between client and server. XUP is a protocol used for communicating events and user interface updates on the web. The Framework enables the Model-View-Controller paradigm for web applications, offering a set of user interface components and bringing them closer to their desktop counterparts. Developers can create whole applications including user interfaces without assumed knowledge of many distinct web-technologies. In his subsequent work, Yu proposed an XML-based presentation language XPIL for creating generic presentation objects without the need of interfaces and APIs [31]. The language is event based and the user interface components are easily applicable towards both desktop and web applications. 3.5 Prototyping Toolkit: WARP Mario Bochicchio describes an environment called Web Application Rapid Prototyping (WARP), that is suited for fast prototyping of web applications [3]. WARP supports the user in the complete prototype design process, from requirement analysis via design of the software’s functionality to the complete coding and data handling process. The complete creationary process as well as the phase of execution is taking place in the web. Therefore WARP is covering a set of online tools:

Application Integration

But even if API service calls are present, their invocation can be quite complicated. In his research, Bj¨orn Hartmann et al. introduced a tool called d.mix [14], which enables the prototype developer sampling those service calls through a proxy by demonstration (this approach is basically similar to Tuchindra’s). The main difference is the accessibility of the content through API calls. In the background a mapping of HTML elements and their associated service calls takes place (see figure 4). Users browse a website where API accessible content is highlighted by the proxy, mark elements they wish to copy, d.mix creates a corresponding service call and copies the results in its internal

Fig. 5. The online tool WARP Page Designer (original image in [3])

• The Schema Editor for creating the application’s model and exporting a XML scheme. • The Feeder module that is complementary to a content management system. It can produce a sample of actual data. • With the Page Designer the user can visually define the presentation of the Web Application (see figure 5). • A Generator that creates a runtime Database for caching purposes. • The core Engine that dynamically delivers the pages based on the schemas, contents and layouts. By recording all the events, the usage of the prototype may be analyzed and evolved.

4.2

Healthcare Workers Service Prototype: GEOHEALTH

In his paper GeoHealth, A Location-based Service for Nomadic Home Healthcare Workers, Claus M. Christensen describes the implementation of a functional prototype, ”which supports distributed and mobile collaboration through representation of live contextual information about clients, co-workers, current and scheduled work activities, and alarms adapted to the users’ location” [4]. The GeoHealth web prototype heavily uses the Google Maps API, Web 2.0 techniques and a GPS module for positioning. The prototype was developed after design sketching, paper prototyping and technology exploration (see figure 6). The prototype was evaluated in a field study and was used for way finding assistance and task management for workers.

WARP, introduced in 2004 and presented as ”first environment for fast-prototyping completely on-line”, is an innovative but only partly finished project. Although it is apparently discontinued in its development process, it could be a trendsetting toolkit for all-in-one webprototyping. 4 P ROJECTS Now that the technical fundamentals have been highlighted, we will discover some tangible projects, which had their origins in web prototypes. We will have a look at a Crisis Management Prototype and a Healthcare Workers Service Prototype, both powered by the Google Maps API. Furthermore we graze the different development steps of a Mixed-Fidelity Prototype of a task planner for Mars surface operations and we will end with considerations of Clinical Information System Prototypes. 4.1 Crisis Management Prototype: CHEOPS CHEOPS 2.0 is a prototype of a replacement for the CHEOPS geopolitical risk and crisis management system designed in 1997, helping the military to understand and classify the situation. In his paper, Francis Rousseaux [24] is describing the system and comparing the complexity of the creation of the original software to the creation of the prototype. Table 1. Resources needed for CHEOPS and CHEOPS 2.0 (adapted from [24])

Maps/Images Geographical Information System Crisis Management System User Interface Other

CHEOPS Software/ Men/ Equipment Month 20% 3% 70% 70%

CHEOPS 2.0 Prototype Software/ Men/ Equipment Month 0% 5% 0% 0%

2%

20%

0%

65%

n/a 8%

n/a 7%

80% 20%

20% 10%

CHEOPS had as components a commercial database management system, a commercial geographical information system and the core functionality. As we see in table 1, most of the development work and time (70%) was spent for the geographical information system, while the core system itself required only 20% of the attention. The new prototype, CHEOPS 2.0, is a web application powered by the Google Maps API as geographical information system and AJAX techniques. Table 1 also shows the effort taken for the single steps, while the geographical information system was now an external application, most of the time could be spent for the core functionality (65%). Rousseaux’s main findings are the increased productivity in prototyping but limitations for real applications on the other hand. The product could not have been validated, secured and maintained. This can not be guaranteed while using external components.

Fig. 6. The GeoHealth Home Screen (original image in [4])

While Christensens main findings deal with the improvement of the UI, he casually mentions the benefits of web prototyping: The web application resulted in a user friendly, high fidelity and real life prototype, with the advantage of mobility. But the future technological platform was not sure yet, a tangible application would follow. 4.3

Mixed-Fidelity Prototype: SPIFe

Michael McCurdy et al. [21] compared the renewed web prototype (SPIFe) of a preexisting tool (MAPGEN Activity Planning Tool) to a tool based on the eclipse platform that has been developed (Ensemble) using the prototype (see figure 7). The preliminary case: MAPGEN, an activity scheduling tool for the Mars Exploration Rover shown in figure 7(a) had to be redesigned because of missing functionalities and the lack of performance, after identifying the goals for the new product. The web prototype SPIFe took advantage of HTML, DOM and CSS, dynamically created by a server-side program as shown in figure 7(b). The prototype was created by a single developer in one month. Through creating a web application, it was possible to measure the accurate timing data (a mentioned goal was to increase the performance), what would not have been possible when using traditional user interface prototyping methods. The final application Ensemble was built using the Java Eclipse Development Framework, which allowed to transport the gained results quickly into working software, necessarily being high fidelity. Ensemble can be found in figure 7(c). McCurdy et al. compared and tested all the three software artifacts, the results were (as expected) a slow MAPGEN tool. But for all tasks, SPIFe and Ensemble showed no significant differences in usability. Even though Ensemble was a high fidelity software product compared to SPIFe with its high fidelity data depth but low fidelity user interface. The prototype was as useable as the productive version (apart from the lack of graphical refinement).

(a) The MAPGEN Activity Planning Tool, used during the NASA Mars Exploration Rover missions in 2004

(b) The SPIFe Prototype Timeline

(c) The Ensemble Timeline

Fig. 7. The evolvement of an activity planning tool for Mars surface operations (original images in [21])

4.4

Clinical Information System Prototypes

An interesting sector for prototyping applications in the web are Clinical Information Systems (CIS). Because of the complex and different procedures in clinical workday life, new ideas and processes have to be implemented quickly and tested regularly. An old study of web development has been done 1995 by J. Cimino [6]. Subject is a Clinical Information System Prototype with the upcoming techniques HTML and CGI (an early approach for executing server sided scripts). Cimino used foreign internet based resources for his project, for example medical information retrieval, as an early form of a mashup. His findings at that time: The internet is an ”exciting new environment” that excellently integrates with other resources. Ciminos follow-up study in 1996 [5], was based on the earlier findings and put a closer look on web prototyping, again considering the CIS case. He still believes in the web as platform for rapid prototyping that makes ”implementation of new functions quickly without large investments of effort”, which had never been possible with traditional prototyping. He discovers the anyway available logfiles valuable for his user studies. In 1998, G. Hripcsak built a web based CIS on top the existing Columbia University CIS [16]. The goal was to ”make clinical information available to users wherever and whenever they need it”, later potentially replacing the classic system. Figure 8(a) shows the main screen of the web application entirely written in C as a CGI appli-

(a) Hripcsak’s WebCIS prototype in 1998 (original image in [16])

cation. Although the system can be distinguished as a prototype and Hripcsak mentions that the development cycle was fast, he discusses that all time-consuming ”other aspects of the application life cycle” are still necessary. He criticizes that in the moment the application got finished, all used techniques (CGI, HTML and JavaScript) became obsolete and maybe unsupported by browsers. He concludes his study with the assumption, that ”the best one can do is stick to a good clinical application architecture, with well-isolated modules, well-defined layers, and industry standard protocols.” A further disclosure and contemporary approach by J. H. Kim et al. [19] followed in 2001: Kim recognized the complex and everchanging demands in CIS, too. Hence he developed of a rapid prototyping and clinical conversational system. Clinicians themselves (experts in acquaintance of clinical information systems but without programming skills and database knowledge) were now able to compose their own web-based clinical dialogues. Kims forecast was that applications will stay in the internet, because of the growing acceptance and the possibility to link between heterogeneous systems. Todays developments are unambiguous: Because of the complexity and the demand for network compatibility, many CIS become webbased. For example the IBA CIS (developed in the early 1990s), a widespread system, has been redesigned because of lower maintenance cost and contemporary user interface look [17]. BizMatics’ PrognoCIS shown in figure 8(b) is another example for the consequent port of existing systems into the web.

(b) Bizmatics Medical Centre, a Web CIS Application in 2009 (original image in [2])

Fig. 8. Development of different Clinical Information Systems from a prototype to a running web application

5

D ISCUSSION

AND

C ONCLUSION

The use of the web for prototyping applications with the aid of Web 2.0 and APIs is an ascent for prototyping, due to the development of programming possibilities and general conditions of the web. ”Highly interactive” became an attribute for websites as well as for web applications. Prototyping scenarios benefit thereof, applications can easily be prototyped in the web with low effort, high fidelity prototypes can be created. A limitation of the web is its stateless technology. Big effort has to be taken to (certainly) identify an user or to authenticate him. There is a huge offer of different browsers on several platforms (with slightly different techniques). Whenever a constriction to a single system is not possible, much work has to be invested for achieving a similar result on all browsers. A piece of software has to be validated, secured and maintained, that can not always be guaranteed when using foreign enclosed products. But the benefits of web prototyping are predominant: In patchwork manner, the development cycle is fast. There is few need for knowledge of technical details and user interface development to achieve a wealth of functionality. The prototypes are highly interactive, here mid fidelity, there high fidelity, resulting in a mixed fidelity prototype. Prototypes (once adjusted) are platform- and device-independent, the worldwide access is guaranteed. Future Work will probably be spend in even more simplifying the creation and data sampling process and imitating different target platforms (like embedded systems, special hardware or mobile phones). New upcoming techniques in the dynamic web will drastically blur the borders between classic applications and web applications. R EFERENCES [1] Amazon. Amazon web services. http://aws.amazon.com/, 2009. Last checked: 2009-12-09. [2] Bizmatics. Emr software. http://www.bizmaticsinc.com/ emr-software.html, 12 2009. Last checked: 2009-12-09. [3] M. Bochicchio and N. Fiore. Warp: Web application rapid prototyping. In SAC ’04: Proceedings of the 2004 ACM symposium on Applied computing, pages 1670–1676, New York, NY, USA, 2004. ACM. [4] C. M. Christensen, J. Kjeldskov, and K. K. Rasmussen. Geohealth: a location-based service for nomadic home healthcare workers. In OZCHI ’07: Proceedings of the 19th Australasian conference on ComputerHuman Interaction, pages 273–281, New York, NY, USA, 2007. ACM. [5] J. J. Cimino and S. A. Socratous. Just tell me what you want!: the promise and perils of rapid prototyping with the world wide web. Proc AMIA Annu Fall Symp, pages 719–723, 1996. [6] J. J. Cimino, S. A. Socratous, and P. D. Clayton. Internet as clinical information system: application development using the world wide web. J Am Med Inform Assoc., pages 273–284, 1995. [7] Facebook. Facebook platform news. http://developers. facebook.com/news.php, December 2009. Last checked: 200912-11. [8] I. R. Floyd, M. C. Jones, D. Rathi, and M. B. Twidale. Web mash-ups and patchwork prototyping: User-driven technological innovation with web 2.0 and open source software. In HICSS ’07: Proceedings of the 40th Annual Hawaii International Conference on System Sciences, page 86, Washington, DC, USA, 2007. IEEE Computer Society. [9] T. D. Foundation. The dojo toolkit. http://dojotoolkit.org/, 2010. Last checked: 2010-01-15. [10] J. J. Garrett. Ajax: A new approach to web applications. http://www.adaptivepath.com/ideas/essays/ archives/000385.php, February 2005. Last checked: 200911-20. [11] Google. Google-maps api. http://code.google.com/apis/ maps/, 2009. Last checked: 2009-12-09. [12] Google. Youtube apis and tools. http://code.google.com/ intl/de/apis/youtube/overview.html, 2009. Last checked: 2009-12-09. [13] T. P. Group. Php: Hypertext preprocessor. http://www.php.net/, December 2009. Last checked: 2009-12-11. [14] B. Hartmann, L. Wu, K. Collins, and S. R. Klemmer. Programming by a sample: rapidly creating web applications with d.mix. In UIST ’07: Pro-

[15]

[16]

[17]

[18] [19]

[20] [21]

[22]

[23]

[24]

[25] [26]

[27] [28]

[29] [30]

[31]

ceedings of the 20th annual ACM symposium on User interface software and technology, pages 241–250, New York, NY, USA, 2007. ACM. T. Hoff. Youtube architecture. http://highscalability.com/ youtube-architecture, December 2009. Last checked: 2009-1211. G. Hripcsak, J. J. Cimino, and S. Sengupta. Webcis: large scale deployment of a web-based clinical information system. Proc AMIA Symp., pages 804–808, 1999. IBAGroup. Web clinical information system. http://www. iba-it-group.com/en/case-studies/technology/ other/a27c0d064f36a74f.html, 2009. Last checked: 2009-1209. M. C. Jones, I. R. Floyd, and M. B. Twidale. Patching together prototypes on the web. 2006. J. H. Kim, R. Ferziger, H. B. Kawaloff, D. Z. Sands, C. Safran, and W. V. Slack. A web-based rapid prototyping and clinical conversational system that complements electronic patient record system. Stud Health Technol Inform, 84(Pt 1):628–632, 2001. E. Knorr. 2004 - the year of web services. In CIO: Fast Forward 2010 The Fate of I.T., volume 6, page 90. Gary J. Beach, December 2003. M. McCurdy, C. Connors, G. Pyrzak, B. Kanefsky, and A. Vera. Breaking the fidelity barrier: an examination of our current characterization of prototypes and an example of a mixed-fidelity success. In CHI ’06: Proceedings of the SIGCHI conference on Human Factors in computing systems, pages 1233–1242, New York, NY, USA, 2006. ACM. S. Microsystems. Mysql - the world’s most popular open source database. http://www.mysql.com/, December 2009. Last checked: 200912-11. ProgrammableWeb. Mashups, apis, and the web as platform. http: //www.programmableweb.com/, December 2009. Last checked: 2009-12-11. F. Rousseaux and K. Lhoste. Rapid software prototyping using ajax and google map api. In ACHI ’09: Proceedings of the 2009 Second International Conferences on Advances in Computer-Human Interactions, pages 317–323, Washington, DC, USA, 2009. IEEE Computer Society. P. C. Team. Prototype javascript framework. http://www. prototypejs.org/, 2007. Last checked: 2010-01-15. R. Tuchinda, P. Szekely, and C. A. Knoblock. Building mashups by example. In IUI ’08: Proceedings of the 13th international conference on Intelligent user interfaces, pages 139–148, New York, NY, USA, 2008. ACM. C. Wenz. JavaScript und AJAX. Number 3-89842-859-1. Galileo Computing, 2008. Wikimedia and Various. Wikimedia servers - overall system architecture. http://meta.wikimedia.org/wiki/Wikimedia_ servers#Overall_system_architecture, December 2009. Last checked: 2009-12-11. Yahoo. The app garden. http://www.flickr.com/services/ api/, 2009. Last checked: 2009-12-09. J. Yu, B. Benatallah, F. Casati, and R. Saint-Paul. Openxup: an alternative approach to developing highly interactive web applications. In ICWE ’06: Proceedings of the 6th international conference on Web engineering, pages 289–296, New York, NY, USA, 2006. ACM. J. Yu, B. Benatallah, R. Saint-Paul, F. Casati, F. Daniel, and M. Matera. A framework for rapid integration of presentation components. In WWW ’07: Proceedings of the 16th international conference on World Wide Web, pages 923–932, New York, NY, USA, 2007. ACM.