The trend towards mobile devices usage has put more than ever the Web as a ubiquitous platform where users perform all kinds of tasks. In some cases, users access the Web with “native” mobile applications developed for well-known sites, such as LinkedIn, Facebook, Twitter, etc. These native applications might offer further (e.g. location-based) functionalities to their users in comparison with their corresponding Web sites because they were developed with mobile features in mind. However, most Web applications do have not these native mobile counterparts and users access them using browsers in the mobile device. Users might eventually want to add mobile features on these Web sites even though those features were not supported originally.
The increasing growth of both the Web and mobile technology in today’s global scenario has raised new forms of participation of end-users. Mobile devices started to be used as personal computers, competing and even replacing computers for daily life tasks, and, as far as the resources of these devices increased, so it did –and still does– the number of innovative implemented functionalities they can benefit from. Today, it is usual that end-users interact with the same Web applications from both, desktop computers and mobile devices.
Some of the most popular Web applications (like Facebook, Twitter, YouTube, and others) provide native mobile applications, and some of them (like Booking) also provide nice location-based features to profit from the mobile nature of user devices. However, the majority of Web sites are still accessed from Web browsers in the device, and they do not provide any mobile features. This phenomenon might be caused either by economic reasons (to build the native application), by the difficulties of modifying the Web application to support the mobile features, or just for lack of interest. In any case, end users lack the possibility to better access the information and services provided by these applications.
This situation is worse for Web applications providing information that is naturally location-based, such as the one presented by museums, city halls, or tourist applications. In these cases, accessing parts of such information “insitu” (e.g. visiting the museum with a smartphone) could certainly enrich the visit, providing the end-user with locative media experiences, as it has been shown in dozens of cases. Some of these institutions provide a location-based feature by adding QR-codes to some of the points of interest (artworks, monuments) so users can explore some information with their devices (e.g. using QRPedia). More complex scenarios, like itinerant or temporary exhibitions, might complicate things further. The underlying philosophy of our approach is the one provided by the concept of Web augmentation.
During the last years, end-users started to –unofficially– add new functionalities to Web applications when some of their requirements were not contemplated originally. In this way, users began to participate not only under the role of consumers of Web applications but also learned how to become producers of their own solutions. Being a producer is not necessarily synonymous with having –or not– technical knowledge or expertise. Within this category of end-users, you can find people with skills for textual or visual programming, as well as those who do not have much technical knowledge but can also build their applications by using simple or assisted tools, such as form-based wizards or tools supporting programming by example.
Applying Web augmentation on mobile devices implies that, besides the common aspects that may be adapted typically (e.g. look and feel, personalization, recommendations, etc), mobile and context-aware features can be contemplated as well. For instance, we could take into account the user’s position for augmenting a News portal with geo-positioned and content-related videos and tweets. By taking the current user’s position through the Geoposition Web API, it is possible to use it for building geo-located queries through the Data API of Youtube and the REST API of Twitter. Then, the retrieved content could be injected into a News portal’s Web page by using the AddonSDK5 of Firefox. We can listen for the device’s orientation changes (DeviceOrientationEvent) and augment Google Maps’ Web page with a real-world view (camera capture) and an arrow pointing to the target location when the user tilts the device vertically. We can calculate the perceived sound level by using the WebRTC API for automatically adapting the volume of Youtube videos at middle levels, or stopping/resuming the reproduction at high ones.
Although there are already some approaches for augmenting Web applications from mobile Web browsers, such as, they are aimed at and limited to producers with programming skills (from now on, developers). We have developed the Mobile Web Augmentation (MoWA) approach, which comprises a software framework and a set of tools for developers. Basically, MoWA provides developers with a framework for creating mobile Web applications based on client-side adaptation including the addition of new (e.g. location-based) contents and functionality (such as context-awareness) directly on the front-end, i.e., the Web browser. In this paper, we change our target audience from developers to a broader one: producers with no programming skills (from now on just producers).
Providing producers with the tools for specifying how their preferred applications should be augmented is a good solution to help them to augment the Web from mobile devices and, at the same time, to create better mobile Web experiences. This strategy is reasonable since many recent studies have demonstrated that there is a global tendency of end-users meeting the concrete needs of domain-specific scenarios by creating their own applications by using EndUser Development (EUD) tools.
Some studies indicate that there is a strong tendency demonstrating that the end-user is starting to create, modify or extend their own software artifacts by using programming environments that abstract, somehow, the complexity of the development. This tendency gave rise to what we actually call EUD, and was motivated by the need of users to quickly build their own solutions to the needs they have in their daily lives or circumstantially. Different from “traditional” software engineering approaches, in EUD the same person plays the role of developer and end-user; he is the one who knows his context and needs better than anybody, and that not necessarily has formal education in development processes. EUD comprises a set of methods, techniques, and tools that empower the user with the capability of creating, modifying, or extending software artifacts. For achieving the aforementioned, EUD relies on some well-known programming techniques, like Programming. By Example (a.k.a. by Demonstration), Extended Annotation (a.k.a. extended parametrization), Visual Programming and Scripting Languages.
The first technique consists in recording the sequence of actions of an end-user in a system, so the application is built on the specification of the user’s demonstration, and it does not require the user to code. The generated application should reproduce the commands he executed, and also allow him to parameterize some data objects used in the demonstration. The main benefit is that the user is writing programs through the user interface he is already familiar with, but it limits the end-user to use already existing functionality in the base system or to add control structures to the recorded program. The second one is about associating a new functionality to the annotations the user makes, for example, allowing the user to annotate the DOM elements of a Web Page and associating a specialized behavior to the element.
Visual Programming is another set of techniques, all of them intended to build a program by letting the user combine visual constructs. Languages here have a visual counterpart, a representation of the available conceptual entities and operations –the programming constructs–. In contraposition, text-based languages cover just one dimension and require the user to learn the construct names and syntax. Although this last technique can be a bit confusing –because it is hard to imagine an end-user writing code– there are already widely used tools that implement this technique, and which are considered traditional examples of EUD, such as applications created using formulas in spreadsheets. EUD applications started spreading on the Web, where a large number of users joined different online communities to create and share their applications through public repositories. For instance, Userscripts and GreaseFork allow users to share Greasemonkey scripts that adapt and augment the Web. Even traditional applications, such as desktop spreadsheets, began to be conceived as part of the global Web scenario with the use of online, shareable, and multiple access applications, like Google Sheets. In the mobile applications field, EUD raised, expanding its scope and representing new challenges of integration with the possibility of providing both, the development process and the resultant application, with features based in diverse context types, like positioning, orientation, or noise perception level.
MOBILE WEB APPLICATIONS
One of the main benefits brought by the development of Mobile Applications was the possibility of providing applications with mobile features (e.g. location-based) to offer the users customized services according to their environment. For instance, Context-Aware applications constantly monitor the users’ environment and adapt the behavior of the application accordingly. Mobile Hypermedia applications make use of the position of the users and the Points of Interest (PoI) for assisting them in their navigation through the real world. There are also Mobile Augmented Reality applications, that consider the user’s position for computing the position of digital objects in the real environment and draw them into a virtual layer.
For a long time, these kinds of applications were developed with native code or specialized intermediate frameworks, which allowed developers to create native or hybrid applications. At that time, Mobile Web Applications had little significance because there were no mechanisms for direct access to the device’s internal services. Then, some works started to develop strategies for allowing Web applications to access the context information. For example, the authors presented a browser that interprets applications enhanced with specific XML tags. Such tags requested specific context information, and the information communication was achieved through the implementation of RESTful web services or POST requests. The authors adapt existing Web applications according to the context of use –e.g. sensing light and noise levels, heart rate, user movements– resolving the adaptation content at the server-side and then delivering the modified version for user consumption. Nevertheless, due to recent advances in mobile Web browsers, Web applications can use the device’s sensors values for adapting their behavior, and new and interesting functionalities can be created.
Web Augmentation is a technique for manipulating and enhancing existing Web pages with new features. This makes it possible to meet needs that were not contemplated when a Web application was implemented, either because a) there was no such need at that time and could not be anticipated) it was not detected at the requirements elicitation stage) simply because it was intentionally ignored. Augmentation is suitable for third-party stakeholders with very particular interests that have not been implemented; augmentations might also convey useful information for the owners of Web applications because it can be used to identify uncovered needs of customers. For example, we can appreciate how Télam, a news portal, can be augmented with the capability of looking at definitions in an online encyclopedia when the user holds a word on the screen of his mobile.
There are several ways for implementing WA, but in general terms, we can classify them according to where the process takes place: at the client-side or remotely (usually proxy-servers). In all cases, augmentations are materialized through the manipulation of Web Sites DOM, which is basically the UI that users perceive on the client-side. Web augmentation on the client-side is appealing since different users can share or eventually improve the same augmenter on their own devices, without depending on third-party proxy servers such as transcodings. On the client-side, there are several ways to address the deployment of such augmenters, but usually, it implies installing some Web browser extension. These extensions may be found in the corresponding browsers markets (e.g. Firefox, Chrome, etc), and they are usually designed for augmenting a specific Web application (for instance, Amazon, Youtube, etc.). There are other kinds of extensions that act as weaving engines enabling the execution of augmenters written in a Web browser agnostic way. Such augmenters are usually referred to as user scripts. Most of these engines are available for all well-known Web browsers; they allow the reuse of the augmenters, something that is not possible with specific Web Browser extensions. Without taking into account the deployment strategy, we can find several hundred thousand augmenters.
There are even “official” extensions that provide a better experience to customers, such as Amazon Assistant, with more than three million users. Besides that, all these repositories allow users to contribute and send feedback about the augmenters. The reader may see that for the most used ones, there are hundreds of comments suggesting changes or improvements. A deeper survey about exiting artifacts for the augmented Web.