Basic Concepts
In order to get a good understanding of LogUI, we think it is important that you have a decent understanding of the thinking behind the system. This short Wiki page should help improve your understanding of the overall system, and the thought process that has gone into it.
Think of LogUI as a service that you can use whenever you need to track interactions on webpages. While currently focused on tracking the interactions on a single webpage (such as a results page, for example), LogUI can of course be adapted to cover multiple pages. You just need to tell LogUI what pages should be considered, and what interactions on each of those pages should be considered. Over time, we hope to develop LogUI to encompass a multi-page web application, covering fine-grained user interactions across pages with different layouts.
Deploying an instance of LogUI server at your university's infrastructure will provide you with the ability to log interactions across a variety of different applications. For example, one instance of LogUI server can be used to capture interactions for the experiments of several research groups. In order to understand the thinking behind this, you need to think in terms of applications, flights, and sessions.
When logging interactions with LogUI, you need to understand the concepts of applications, flights, and sessions. These are the three overarching concepts for how we store interaction data in LogUI.
Put simply, an application is some service that you offer to your clients/participants that you want to track interactions on. For example, the Lambda Lab at Delft University of Technology has developed experimental search application called SearchX. This application has been used as the basis for a number of experiments published by the lab. If we wish to track interactions on SearchX, we can create an application to track in LogUI called SearchX.
Each application that you define in LogUI may have one or more configurations — or even different pages/interfaces that individuals will use. With these variations, we need a way to be able to delineate between them, yet still keep them under the umbrella of the same application. We call these variations flights in LogUI.
As an example, let's say we are using SearchX to run one of the experiments that the Lambda Lab presented at ACM CHIIR 2021. There are four conditions in this experiment, each of which requires a different variation of the SearchX infrastructure (deployed on separate servers). To address this, we can simply create a flight for each condition.
-
CHIIR2021-Baselinehosted atsearchx1.someorg.tudelft.nl -
CHIIR2021-Notehosted atsearchx2.someorg.tudelft.nl -
CHIIR2021-Highlighthosted atsearch3.someorg.tudelft.nl -
CHIIR2021-Bothhosted atsearchx4.someorg.tudelft.nl
These flights correlate to one of the four conditions we trialled. We named them as such to ensure that we don't conflict with the names of any other experiments that we run using the SearchX application. We specify a hostname for each condition (which could all be run on the same host!) to add a layer of security, ensuring that interactions are only logged from an application residing on the hostname that you specify. This information prevents malicious actors from hijacking LogUI and recording nonsense to throw you off.
Finally, there is the concept of a session. Associated with a specific application and flight, a session is just what the name says — a session on your specific application flight undertaken by a user. This user begins their interactions, and completes their time on your application, rounding off the session. You can use these unique sessions to identify unique users, and separate out their interactions from others.
As an aside, we've implemented the idea of an authentication token in conjunction with requiring a hostname for flights. Both these measures are an attempt to reduce the likelihood of individuals hijacking and flooding your interaction logs with junk.
When creating a new flight, you'll be given an authentication token that you should include in the client that is logging interactions on behalf of that flight. This authentication token is sent to the LogUI server when connecting, to ensure that the client is reporting for the correct application and flight. As the information is encrypted, it is exceedingly difficult to spoof your application!