Organizations increasingly seek to integrate generative AI into their workflows, yet deciding which tasks to augment, and to what degree, remains a poorly structured challenge. Current design toolkits such as Microsoft’s HAX and Google’s PAIR offer valuable guidance for building human-AI interfaces but assume the decision to deploy AI has already been made. This paper addresses the upstream question: is a given task ready for AI augmentation? We present a five-dimensional framework that evaluates tasks along Cognitive Load, Temporal Engagement, Expertise Requirement, Social-Relational Demands, and Agency & Responsibility. The first three dimensions capture readiness—malleable conditions where AI can reduce burden and extend human capability—while the latter two capture suitability—structural and normative constraints that may limit AI involvement regardless of technical feasibility. Each dimension is operationalized through four concrete factors, grounded in a systematic mapping of 41 HAX and PAIR guidelines. We validate the framework’s content through an expert survey (n = 10), which confirmed strong relevance and clarity across all dimensions and factors, and a focus group with practicing AI consultants (n = 5). The framework aims to serve as a structured precursor to design-level toolkits.

Concept maps are visual tools for organizing knowledge, commonly used in education and design. The process often involves reading and developing conceptual models, where feedback is crucial. Learners (e.g., students, designers) often refer to reading materials, and receive feedback from instructors (e.g., teachers, stakeholders) based on the maps they create. However, annotations made by learners, like highlights, are usually not visible to instructors, limiting tailored feedback. We propose incorporating annotation practices into concept mapping. Learners could highlight text and link these highlights to existing or newly created concepts in their concept map. This way, instructors can access both the concept map and the relevant readings for better feedback. This vision is realized through Concept&Go , a plug-in for the editor CmapCloud . This extension aims at the interplay between mapping, reading, and feedback during concept mapping. The effectiveness of this approach is demonstrated through a focus group (n=5) and a UTAUT evaluation (n=12). Concept&Go is publicly available.

Today’s web personalization technologies use approaches like user categorization, configuration, and customization but do not fully support individualized requirements. As a significant portion of our social and working interactions are migrating to the web, we can expect an increase in these kinds of minority requirements. Browser-side transcoding holds the promise of facilitating this aim by opening personalization to third parties through web augmentation (WA), realized in terms of extensions and userscripts. WA is to the web what augmented reality is to the physical world: to layer relevant content/layout/navigation over the existing web to improve the user experience. From this perspective, WA is not as powerful as web personalization since its scope is limited to the surface of the web. However, it permits this surface to be tuned by developers other than the sites’ webmasters. This opens up the web to third parties who might come up with imaginative ways of adapting the web surface for their own purposes. Its success is backed up by millions of downloads. This work looks at this phenomenon, delving into the “what,” the “why,” and the “what for” of WA, and surveys the challenges ahead for WA to thrive. To this end, we appraise the most downloaded 45 WA extensions for Mozilla Firefox and Google Chrome as well as conduct a systematic literature review to identify what quality issues received the most attention in the literature. The aim is to raise awareness about WA as a key enabler of the personal web and point out research directions.

International audience

Web augmentation is to the Web what augmented reality is to the physical world: layering relevant content/layout/navigation over the existing Web to customize the user experience. This is achieved through JavaScript (JS) using browser weavers (e.g., Greasemonkey). To date, over 43 million of downloads of Greasemonkey scripts ground the vitality of this movement. However, Web augmentation is hindered by being programming intensive and prone to malware. This prevents end-users from participating as both producers and consumers of scripts: producers need to know JS, consumers need to trust JS. This article aims at promoting end-user participation in both roles. The vision is for end-users to prosume (the act of simultaneously caring for producing and consuming) scripts as easily as they currently prosume their pictures or videos. Encouraging production requires more “natural” and abstract constructs. Promoting consumption calls for augmentation scripts to be easier to understand, share, and trust upon. To this end, we explore the use of Domain-Specific Languages (DSLs) by introducing Sticklet . Sticklet is an internal DSL on JS, where JS generality is reduced for the sake of learnability and reliability. Specifically, Web augmentation is conceived as fixing in existing web sites (i.e., the wall ) HTML fragments extracted from either other sites or Web services (i.e., the stickers ). Sticklet targets hobby programmers as producers, and computer literates as consumers. From a producer perspective, benefits are threefold. As a restricted grammar on top of JS, Sticklet expressions are domain oriented and more declarative than their JS counterparts, hence speeding up development. As syntactically correct JS expressions, Sticklet scripts can be installed as traditional scripts and hence, programmers can continue using existing JS tools. As declarative expressions, they are easier to maintain, and amenable for optimization. From a consumer perspective, domain specificity brings understandability (due to declarativeness), reliability (due to built-in security), and “consumability” (i.e., installation/enactment/sharing of Sticklet expressions are tuned to the shortage of time and skills of the target audience). Preliminary evaluations indicate that 77% of the subjects were able to develop new Sticklet scripts in less than thirty minutes while 84% were able to consume these scripts in less than ten minutes. Sticklet is available to download as a Mozilla add-on.

Aligning the software process and the documentation process is a recipe for having both software and documentation in synchrony where changes in software seamlessly ripple along its documentation counterpart. This paper focuses on documentation for Software Product Lines (SPLs). A SPL is not intended to build one application, but a number of them: a product family. In contrast to single-software product development, SPL development is based on the idea that the distinct products of the family share a significant amount of assets. This forces a change in the software process. Likewise, software documentation development should now mimic their code counterpart: product documentation should also be produced out of a common set of assets. Specifically, the paper shows how DITA process and documents are recasted using a feature-oriented approach, a realization mechanism for SPLs. In so doing, documentation artifacts are produced at the same pace and using similar variability mechanisms that those used for code artifacts. This accounts for three main advantages: uniformity, separation of concerns, and timely and accurate delivery of the documentation.

Traditionally, Web applications have had great limitations in the usability and interactivity of their user interfaces. To overcome these limitations, a new type of Web applications called Rich Internet Applications (RIAs) has recently appeared providing richer and more efficient graphical components similar to desktop applications. However, RIAs are rather complex and their development requires the designing and implementation tasks which are time-consuming and error-prone. Moreover, RIA development is a new challenge for the Web engineering methodologies requiring their modification and the introduction of other concerns. In this context, we propose a new approach called OOH4RIA which proposes a model-driven development process that extends OOH methodology. It introduces new structural and behavioural models in order to represent a complete RIA and to apply transformations that reduce the effort and accelerate its development. This RIA will be implemented on the promising Google Web Toolkit (GWT) framework.

Promptness, efficiency and stickiness are among the advantages exhibited by the new crop of Rich Internet Applications (RIAs). These advantages came at the cost of increasing the complexity of development. Additionally, the plethora of RIA frameworks can lock this code into a specific platform. This scenario advises for using model-driven development (MDD). This paper focuses on interactionrich RIAs by addressing two issues: (1) interaction dependencies among widgets, and (2) grouping of widgets into Ajax pages. These concerns are captured in the Orchestration Model. MDD wise, OO-H metamodels accounts for the PIMs whereas Google Web Toolkit is the selected PSM. During transformation, a "message broker" pattern is introduced to decouple widgets from their dependencies. When Ajax pages are generated, heuristics are introduced to find a balance between communication overhead, presentation readiness and maintainability. A running example is used throughout.

Client scripting permits end users to customize content, layout or style of their favourite websites. But current scripting suffers from a tight coupling with the website. If the page changes, all the scripting can fall apart. The problem is that websites are reckoned to evolve frequently, and this can jeopardize all the scripting efforts. To avoid this situation, this work enriches websites with a "modding interface" in an attempt to decouple layman's script from website upgrades. From the website viewpoint, this interface ensures safe scripting, i.e. scripts that do not break the page. From a scripter perspective, this interface limits tuning but increases change resilience. The approach tries to find a balance between openness (scripter free inspection) and modularity (scripter isolation from website design decisions) that permits scripting to scale up as a mature software practice. The approach is realized for Greasemonkey scripts.

Portlets strive to play at the front end the same role that Web services currently enjoy at the back end, namely, enablers of application through reusable services. However, it is well-known in the component community that, the larger the component, the more reduced the reuse. Hence, the coarse-grained nature of (they encapsulate also the presentation layer) can jeopardize this vision of as reusable services. To avoid this situation, this work proposes a perspective shift in portlet development by introducing the notion of Consumer Profile. While the user profile characterizes the end user (e.g. age, name, etc), the Consumer Profile captures the idiosyncrasies of the organization through which the portlet is being delivered (e.g. the portal owner) as far as the portlet functionality is concerned. The user profile can be dynamic and hence, requires the portlet to be customized at runtime. By contrast, the Consumer Profile is known at registration time, and it is not always appropriate/possible to consider it at runtime. Rather, it is better to customize the code at development time, and produce an organization-specific portlet which built-in, custom functionality. In this scenario, we no longer have a portlet but a of portlets, and the portlet provider becomes the assembly line of this family. This work promotes this vision by introducing an organization-aware, WSRPcompliant architecture that let portlet consumers registry and handle family portlets in the same way that traditional portlets. In so doing, are nearer to become truly reusable services.

Portlets (i.e. multi-step, user-facing applications to be syndicated within a portal) are currently supported by most portal frameworks. However, there is not yet a definitive answer to portlet interoperation whereby data flows smoothly from one portlet to a neighbouring one. Both data-based and API-based approaches exhibit some drawbacks in either the limitation of the sharing scope or the standardization effort required. We argue that these limitations can be overcome by using deep annotation techniques. By providing additional markup about the background services, deep annotation strives to interact with these underlying services rather than with the HTML surface that conveys the markup. In this way, the portlet producer can extend a portlet markup, a fragment, with data about the processes whose rendering this fragment supports. Then, the portlet consumer (e.g. a portal) can use deep annotation to map an output process in fragment A to an input process in fragment B. This mapping results in fragment B having its input form (or other "input" widget) filled up. We consider deep annotation as particularly valid for portlet interoperation due to the controlled and cooperative environment that characterizes the portal setting.