People's Newsroom


Before deepening into details, it is worth making a clear distinction between two end-user roles that are considered by our approach. In this research we distinguish between:

Producers. who create their own applications by using a EUD programming environment.

Consumers. the ones who install and execute applications (created by a developer or a producer).

In order to understand which are the requirements for being a producer, we have surveyed the literature to identify common learning barriers on end-user programming systems. There are six learning barriers (design, selection, coordination, use, understanding, and information) in the context of end-user programming systems. In this regard, and following some author’s recommendations and findings, we defined a producer’s live programming environment, mainly based on pre-built widgets and forms. In this way, from our point of view, producers require to know what kind of mobile experience they want to have on a target Web site, and which context information (and the associated sensors) they want to use. They need to be capable of filling forms, placing widgets by drag and drop, and, in order to let producers understand their creation, they should be able to manage the preview of the mobile augmentations at any moment and check that the expected behavior is working as expected.

The main idea behind our approach comprises, at least, a producer creating a Mobile Web application with a domain-specific authoring tool and a consumer using such application through a mobile browser weaver. There are other possibilities such as developers extending or instantiating the framework and improving the end-user tool, but we will concentrate on the former for the sake of clarity and conciseness.

We provide three tools to support this process:

  • MoWA authoring, an extension to Firefox for Android,supporting the creation of Mobile Web Applications at client-side).
  • MoWA crowd, an online platform supporting crowdsourcing and sharing services for MoWA artefacts.
  • MoWA weaver, another extension to Firefox for Android supporting the management and execution of MoWA applications.

A producer can interact with MoWA authoring, basically, for creating Mobile Web experiences from existing Web applications. He can create such applications based on his own requirements, but he can also do so upon the request of consumers, materialized in an app request posted in the MoWA crowd. In both cases, creating an application may involve the extension of an existing one; to do so, the user must select an existing application, either in the local storage or in the remote repository. For the second option, he should search and download one of his applications in the repository, or a public one created by another user. The user may follow a series of steps and, at the end of the process, it involves automatically saving a copy of the created application in the local storage of the browser extension, so it can be further edited or just executed in the producer’s EUD environment. Finally, the producer has the chance of sharing his application in the MoWA crowd. He can do so with the aim of sharing a new user experience, or for completing the app request process started in the MoWA crowd context.

A consumer can install MoWA weaver in his mobile browser, and start experiencing the augmented Mobile Web. To do so, he may execute MoWA applications that may be retrieved from the MoWA crowd repository or the ones he already has in his local storage (in the case he already has imported any or if the same user plays both roles). If the consumer cannot find an application facing his requirements in the public repository, he can start a new app request in the MoWA crowd. Finally, and for the sake of space, we just mention that a consumer can also manage their local applications. E.g., he can edit or delete them, change the order of execution in relation to other applications, etc.


We present the architecture of the tool supporting our approach, the authoring process, and the involved steps, and finally, we use our authoring tool for solving and presenting a case study, by following each step of the mentioned process.


Two mobile tools are shown at both sides of the figure; they are in charge of enabling the authoring process and executing the resultant applications. There are also server-side components supporting application sharing and some crowdsourcing services, so consumers can demand new solutions, and producers and developers can meet such needs. Both client applications are Firefox for Android extensions, running on version 41 of such a mobile Web browser. First, the same mobile Web browser, allows them to access the underlying capabilities of the device; for instance, it exposes multiple APIs for accessing the battery, the camera, the geolocation, the orientation, etc. This means that developers can access values of the user’s context and take advantage of them in a direct way. E.g. by using the navigator.geolocation.getCurrentPosition, but also by using the APIS for processing data and tracking other context types. An example of this is accessing the camera, asking the user to point a QR code, making it a picture, and analyzing it for decoding a QR code, which contains information related to the user’s position. Second, they share the same base framework for instantiating, extending, and executing applications: the MoWA framework. Finally, they also share some generic components for managing the user’s installed applications in local storage, but also for connecting to the server and uploading, updating, or downloading applications.

At the right of the Figure, you can see the customer’s device, which has installed the MoWA weaver extension. He can import already defined applications from our repository, and use it for visiting existing Web sites with augmented features (e.g. he can download applications solving the aforementioned scenarios). Such applications can be created in two ways: by client-side scripting (for developers) or by using the authoring tool (for producers). The first ones are downloaded from the repository as JavaScript files, and our weaver has a specialized interpreter in charge of loading the required classes for each application and instantiating them in the context of a set of concrete Web pages. In the second case, another engine interprets authored applications, the ones created with MoWA authoring, that are materialized as an XML file, and specified according to the XSLTForms data model. This engine is in charge of interpreting such specifications, instantiating the proper classes with the values in the data model, and then also cloning such objects in the context of the original Web page to augment. Then, in the middle, we have MoWA crowd, an online platform supporting crowdsourcing tasks management, and also a repository of MoWA artifacts, among them, a collection of applications ready to be installed and used by consumers. Concerning the source of such applications, they can be both: the ones created by developers, or the ones created by producers with the MoWA authoring tool.

At the left of the figure, the MoWA authoring tool architecture is presented. It is installed as an extension of the mobile browser on the producer’s device. It comprises a set of specialized classes that decorate the base classes composing a MoWA application and extend their functionalities with the ability to ask the end-users for the required parameters through a form-based assisted process, in order to instantiate such classes with the required values. For every configurable artifact supported in the authoring process, we have a decorator wrapping it; we call them builders, and they assist the user in the authoring process by helping to configure specific instances to run properly. There is the main builder, the one in charge of orchestrating the full authoring process: the Mobile Application Builder. It knows all the builders in charge of the application’s construction process and their dependency to execute the application while it is being authored. The order matters; consider an augmenter dependent on the user’s position. It can not be properly set up if at least, a Web page has not been defined and if a sensor has not been selected. Therefore, it is important not to allow customers classes to access those subsystems directly. This way, the Mobile Application Builder also plays the role of a façade, being on charge of delegating the configuration of the application’s components to other builders in the subsystem, in a specific order.

Builders might also depend on some values of the user’s context. For example, consider a user walking a city and building a tour; he may want to retrieve his current position for creating a marker in a map or detecting noisy areas in the city for defining an augmenter that increases the volume of a video. If the user is building an indoor tour based on existing QR codes in the building, he needs the tool to be capable of decoding those QR codes in order to associate the data to a physical position. And if the user selects a context-dependent augmenter for his application, it also needs to be subscribed, somehow, to the changes in the context. This depicts how the in-situ authoring process also depends on the MoWA sensors to be notified when their values change.

Back to top button