Interface Engineering for UX Professionals

Abstract

This paper describes a small unit for teaching interface implementation to user experience (UX) designers. Where human–computer interaction (HCI) textbooks and courses include aspects of user interface engineering, they are usually focused towards computer science students. The unit described here is part of a larger online HCI course where the majority of learners are UX professionals, who found it hard to understand why they needed to learn about implementation. The paper explains why the author felt it important to include aspects that help the UX designer understand the behavioural and practical implications of ‘low level’ coding, and also the elements included in the unit. The resulting unit includes many concrete examples linking user behaviour to internal structure and having produced the material, it seems that this may also be a good way to introduce the topic to more technical students before digging into lower level details.

A Appendix: Unit Content – Implementation for UX

This material is just a single unit of the IxDF HCI course, which corresponds roughly to the material one might present in a few hours lectures in a week of a face-to-face course.

1.1 A.1 Introduction

This part is about orienting and motivating the learner as to why they should have some understanding of underlying implementation details.

Human roles in delivering systems to users – The unit starts by looking widely at the various human roles in the design and delivery of a computer system. This includes designers, implementors, sales, maintainers and of course the users themselves. It also discusses how these human roles interact at different stages from project management and requirements gathering through design, deployment, maintenance and support. The aim is to give a wide angle view beyond the design and development stages that are often the focus for UX and also to reinforce the value of each of the human roles (Fig. 5).

Fig. 5.

Sample slides from “Introduction”.

Three use words – This wide angle view is reiterated using the three use words for a system that had been introduced at the beginning of the whole HCI course: useful, usable and used. This leads into a discussion of the way a product has to meet user needs, be able to be delivered technically and also have a route to market. If any fails, they all fail, but the precise order might vary from project to project.

Do I need to know how it’s put together? – Hopefully by this stage the learner accepts that the process of creating and delivering a product is a multi-faceted where the UX design is critical, but only one part. This last part of the introduction seeks to demonstrate that the implementation of the system is not only important, but also important to understand – it cannot be dismissed as mere ‘implementation details’.

This includes describing how the final system must be possible to deliver given current technology and the time available, how the tools chosen may influence the kinds of systems created and how ‘the bits leak out’, the underlying architecture, toolkits and coding methods will have an impact on user experience.

The final message is “you don’t need to code, but you do need to understand its constraints and potential” – and indeed that creating given this understanding is the essence of good design.

1.2 A.2 Understanding States and Events

The idea of system states and events transforming them are fundamental to both implementing and understanding any interactive system.

Continuity – This part start by using Zeno’s hare and tortoise to discuss continuity: how the physical world is largely continuous, but the digital world is discrete operating usually in time steps, albeit often so fast that the distinction may be hard to observe. In particular, the learner is introduced to status-status mappings such as the relation between a finger position on a touchscreen and an object being dragged. The user sees continuous motion, the computer a series of discrete changes, but the designer needs to be aware of both.

Events – The focus then moves into more detail about events including the way there may be events at different levels of abstraction from raw touch/mouse events, through widget events such as ‘button pressed’ and higher-level compound events such as ‘file saved’.

Buxton’s three state model [1] is used to explore the way different device might have hover states for tooltips, whilst others do not. The learner is also introduced to the fact that event orders may differ between platforms and that there are many kinds of system and network-initiated events as well as user-initiated ones leading to the potential for race conditions.

State – State is introduced as the holder of memory from the past for the future. Inspiration is drawn from different forms of state in the physical human world including memory, books and physical arrangements. The various forms of computer memory are then discussed including where it resides in the system: local device, web browser, server, or cloud and how this affects properties such as longevity, access speed, availability and reliability.

Building on the earlier discussion of status-status mappings issues of consistency are discussed including synchronisation issues between multiple devices and constraint maintenance within the interface (Fig. 6).

Fig. 6.

Sample slides from “Understanding states and events”

1.3 A.3 Network-Based Interaction

This topic could be a whole course in itself! Nearly every application now-a-days involves some sort of network. This part covers a few of the ways this affects user interaction and experience.

Network properties and issues – Critical network properties and metrics are introduced: bandwidth, latency and jitter. These are discussed initially in relation to media delivery including the way buffering can reduce jitter at the cost of additional latency. This leads to the problem of ‘glitches’, short breaks in connectivity, that are longer than can be regarded as jitter, but shorter than full periods of disconnection. This in turn is used to motivate ‘network aware’ design, interactions that are resilient to different forms of network effects.

Case study: race conditions in mute-wars – A practical case study is to reinforce the messages in this part. One assumes that the memory of long days full of Zoom/Teams meetings will not be forgotten quickly. The case study explains the race conditions that give rise to ‘mute wars’, the way meetings chair and participants can accidentally lead to simultaneous unmute/mute events (Fig. 7).

Fig. 7.

Sample slides from “Network-based interaction”

1.4 A.4 Digging Below the Application

The original implementation unit included material on windowing systems which was both quite low level and also rather desktop oriented. This short part starts with the way that operating systems and windowing systems abstract away from details of particular devices and effectively share the fixed physical resources (screen, keyboard, etc.) between multiple applications. Examples are given of different ways to share screen real-estate such as scrollable vertical tiled layouts such in side bars, and overlapping windows on the desktop. This part also briefly discusses non-screen resources such as power and network access, and inter-application management issues including consistency, the clipboard and changing the active app (Fig. 8).

Fig. 8.

Sample slides from “Digging below the application”

1.5 A.5 Architecture

Software architectural design is a major influence on many aspects of systems, some are immediately obvious in the interface behaviour, but others, possibly more critical, only become apparent once a system has been deployed including reliability and ease of maintenance.

Overview – This introduces the idea of software architecture. It uses the analogy of cities and buildings: the way they have structure at different levels, and flows of vehicles and people between them.

Seeheim – The Seeheim model is described first in terms of its historic role, but also in the way that it gives a language to think both of the internal construction of a user interface, but also the structure of the interface itself. A save/delete dialog box is used to illustrate the levels of presentation, dialog and functionality.

Model–View–Controller – The MVC model is presented both in relation to the Seeheim model and in terms of its strengths in separation of concerns, reuse, and offering multiple views for the same underlying state. The original ‘pure’ MVC is described first followed by an explanation of how many systems that describe themselves as ‘MVC’ actually amalgamate the view and controller as a single component.

The Reality – more of a Hydra model – The save/delete dialog box introduced earlier is used to illustrate how components at different levels each have appearance, behaviour, interaction state and persistent state, forming a structure rather like the mythical Hydra (Fig. 9).

Fig. 9.

Sample slides from “Architecture”