Keywords

1 Introduction

Contemporary web applications are complex and ubiquitous [17]. At their heart, a series of manipulations are undertaken on the Document Object Model (DOM)Footnote 1, where HTML elements are created and modified during the lifespan of a webpage. Web-based experimental apparatus is commonplace within the IIR community to examine an interface’s usability and the behaviours exhibited by those who use it. Vital to these studies is the concept of logging user interactions. Interaction logs are generated by capturing and recording a user’s interactions (or events) with webpage(s) during a search and/or browsing session.

Researchers often work on their own web-based apparatus, including their own logging infrastructure. Anecdotal observations highlight that logging is often achieved in a piecemeal fashion, often considered to be an afterthought leading on from the implementation of the main system. However, this is undesirable. Infrastructure can be complex to implement [1], with researchers forgetting to log key events, or misunderstanding implementation nuances. This can lead to low quality logs, with missing and/or noisy data—with the potential for post-hoc frustrations when interpreting the data. While attempts have been made to develop logging infrastructure over the years (refer to Sect. 2), we have failed to find an easy-to-use (and affordable) solution that considers the necessary complexities to generate clean logs—and is able to exploit contemporary web technologies.

As such, we present in this paper the LogUI framework. The framework can capture and record high-quality, fine-grained user interaction data over the course of a search and/or browsing session. It can be easily integrated within any existing web application that is run on a contemporary web browser/framework, meaning support on both desktop and mobile platforms is possible.

2 Existing Approaches

While a large number of IIR studies report measures such as click depths (on Search Engine Result Pages (SERPs)), mouse trails and movements, dwell times, keypresses, and so forth, descriptions about how the underlying data are captured are seldom provided. Indeed, logging apparatus is often implemented in situ within the wider experimental system. A number of logging tools (and associated literature) exist. Phillips and Dumas [16] presented a number of criteria that effective logging infrastructure must comply with.

The mid-2000s to the mid-2010s saw a shift in focus from platform-specific [14, 16, 21] to web-based experimental apparatus, including interaction logging infrastructure that focused on examining the DOM. Examples of solutions from this period included MLogger [10], PooDLE [5], Search-Logger [18], Wrapper [13], UsaProxy [3, 4], the framework by Hall and Toms [11], WHOSE [12], and YASFIIRE [20]. Some of these solutions required additional software to be installed (such as browser toolbars), while others made use of an intermediary proxy server to inject logging code, as used in subsequent studies [2, 6, 7, 15].

Despite advancements, these approaches were less than ideal [8]. A second browser war led to a rise in prominence for client-side scripting (i.e., ECMAScript, or JavaScript), and in turn increased the capabilities of browsers. Existing solutions became redundant, with new, JavaScript-only solutions such as ALF [9]. In the commercial space, tools such as Google Analytics, Hotjar, Matomo, and eTracker Analytics are available. While useful, these tools offer either coarse-grained logging (for SEO); are prohibitively expensive; are not designed to be loosely coupled (leading to integration difficulties); or use outdated technologies. A more recent solution is UXJs [19], but it may still have issues when integrating with modern web applications using frameworks such as React. These modern frameworks use JavaScript to ‘draw’ elements on a webpage; the fine-grained logging solutions mentioned above do not cater for elements drawn after the page initially loads. We believe that there is therefore a pertinent need for logging apparatus supported by researchers within the IIR community.

3 The LogUI Framework

With a high-level overview of LogUI shown in Fig. 1, we now present a brief discussion of the framework’s architecture, highlighting the main components. This includes: the client; what can be logged; the server; and ease of integration. Note that all circled numbers (e.g., ) pertain to the component highlighted with the same number as in Fig. 1.

Fig. 1.
figure 1

Architecture diagram of the LogUI framework. Refer to Sect. 3 for a detailed explanation, along with descriptions of the eight highlighted components.

Full size image

LogUI Client Library: The LogUI client is a JavaScript library that provides advanced functionality for the tracking of events associated with a specific element on a webpage, or associated with the webpage as a whole. To clarify, an event pertains to a specific action—such as the click of a user’s mouse—on a specific element—such as a snippet as presented on a SERP. Events pertaining to the page as a whole could be, for example, the resizing of the web browser’s viewport, tracking mouse movements, the scrolling of the page, or the web browser no longer being the user’s active window (losing focus). As previously mentioned, LogUI can be used in a contemporary web browserFootnote 2; web-based application frameworks such as Electron are also supported if required.

Given an existing web application (such as experimental apparatus) where fine-grained event logging is required , one can integrate LogUI by including the compiled LogUI client library . A configuration object must be supplied to LogUI . This tells the client library what elements on the page should be logged—and for what events (see below). When an event occurs , the LogUI client then packages up the data for the event (along with any specified metadata, see below) , and sends the packaged data down the established Websocket connection to the listening LogUI server worker process .Footnote 3

Loggable Elements and Events: Standardised CSS Selectors are used in the configuration object to allow for the selection of any element within the DOM. Any standardised DOM events can also be used (such as mouseover or keyup). As mentioned, page-wide events can also be logged. Changes to the DOM are also incorporated, with LogUI watching for new elements matching a given CSS selector, and applying the necessary events.Footnote 4 We also include so-called grouping, where one or more events can be chained together to act as a single, managable event (e.g., mouseover and mouseout events would constitute a grouped hover event). This means that additional logic can be added to avoid logging noisy events, such as when scrolling. This is a novel and non-trivial feature, and while it affords additional complexity, it results in cleaner logs.

Metadata: One or more pieces of metadata may be required to be packaged with a logged event.Footnote 5 LogUI provides numerous metadata sourcers, allowing for the extraction of data from different locations (e.g., the attribute of the element, or localstorage). We also include sourcers for frameworks like React, allowing one to extract a prop or state value from the associated component.

LogUI Server: The server authenticates a LogUI client, and receives the packaged event data . It is then placed in backing storage (with session IDs, allowing for filtering/merging). Captured data for search/browsing sessions can be then downloaded and used for data analysis . The server is implemented within a containerised environment to aid portability.

Integration with Web Applications: LogUI can be seamlessly integrated within existing web applications. As it examines the DOM only, it is framework agnostic. The client is self-contained, meaning it does not interfere with other libraries. Logging is as easy as 1-2-3: (1) include the client library within the web application; (2) specify what elements and events to log; and (3) start a server instance to receive the logged events. The framework provides support for web applications on a single webpage, or over multiple webpages. Interactions over multiple pages can therefore be counted as a single session. A simple API is also provided to start and stop the library, or reset the session as required.

Availability: Code is open source and available from GitHub. The client is accessible at https://github.com/logui-framework/client/, with server code at https://github.com/logui-framework/server/. Documentation for both components are also available in the respective repository.

4 Summary

We have described our new logging framework, LogUI. The complexity that the framework handles (along with the relative simplicity of using it) will provide a powerful new tool for researchers to deploy when logging user interactions as part of IIR experiments. We aim to continue developing the framework to support more advanced featuresFootnote 6, and will promote its use in a wide variety of experimental apparatus, leading to increased productivity for researchers.