Each tool cited in this chapter has its own idiosyncrasies and their use will reveal very specific challenges. But beyond the use of a particular tool, WA challenges users to revise what they know about the web and how to program applications. When it comes to WA, users should be aware of a number of aspects, namely: WA is mainly a browser-based technology. Regardless of the technology employed to store and run the augmentation scripts, the adaptation only affects how a website is displayed in the user’s personal machine. Users must understand that their adaptation is personal and that will not be visible to other visitors of the same website.
WA is mainly a single browse technology. Changes performed by the user will only occur on the browser where the augmentation has been performed. The same user performing the same actions on another computer will not see the augmentation. It thus requires replication of the augmentation multiple times if the users are using multiple execution platforms (e.g. desktop computers, smartphones. Similar to other EUD technologies, WA requires the adaption of the code produced by someone else. This has multiple implications for assessing the code of Web pages before adopting them.
WA is constricted within the DOM hierarchy. Users should be aware of the manipulation of DOM elements imposes a certain order of access to contents. For instance, elements might appear visually together but be arranged in separated DOM nodes. This might imply having different ancestors. This, in turn, prevents these “alongside elements” from being selected as a single DOM element. This constraint is imposed by the DOM element hierarchy. Notice that the DOM hierarchy itself does not need to be made visible but manipulated through metaphors and witty interactive tools. But no matter the tool, it is constricted within the DOM hierarchy. WA is fragile upon Website upgrades. Web sites evolve over time and with the evolution of a website, some elements resulting from the augmentations may disappear and/or be replaced by other elements that directly affect the way WA scripts operate. Thus, whilst some scripts will be resilient to the maintenance of websites, other scripts will stop working once a Web site is upgraded. This makes the use of WA a more suitable technique when users’ needs are volatile.
WebMakeup illustrates the feasibility of having dynamic updates for contents but the bindings between WA scripts and the website remain fragile and prone to become obsolete when the underlying website evolves. This is a major challenge as, by definition, web applications are meant to evolve. Beyond, as the users do not own the web application, the loss of a web augmentation is not predictable. WA does not create brand-new applications but enhances existing ones. The inclusion of content from other websites raises some pragmatic questions about the type of relationship created between websites. The simplest approach is the clone&own of elements. This implies that changes in the source element will not propagate to its clones. Alternatively, it is also possible to keep a dynamic binding with the source element so that changes in the source ripple throughout its clones.
As it allows users to recycle, reuse and exploit material that can be obtained from other websites it supports the construction (by the end-users themselves) of more usable and more adapted web applications. One of the biggest challenges is how to treat dynamic states of Web applications, which means contents that evolve over time. Whilst this remains an unsolved issue that should be addressed by future research, it is possible to envisage various copy and paste strategies to address the problem. In a study of WA tools, we have observed a prominence of tools that run exclusively on the client-side. This is not surprising as one of the advantages of using a client-side approach is the faster execution that has a huge impact on the user performance while interacting with the web application making it possible to provide immediate feedback to the users. Moreover, users do not need to understand severe side functioning and to deal with complex installations on a remote webserver (for which they, most of the time, have no access rights). Whilst the client-side approach is not a panacea, we suggest that this is still a suitable strategy for giving end-users more autonomy on the scripts they want to develop.
Despite our efforts, it is important to note that none of the references provided refer to studies with a large number of users. Because of that, we cannot measure the impact of such a strategy on the end-user community. Nonetheless, the tools we have presented are functional and a dedicated community maintains most of them. We believe that these WA tools deserve more publicity and that a wider and more systematic communication towards end-users would deeply impact the usability of web applications and, more generally, of the Web as a whole.