This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

NISTIR 8003

Design and Testing of a Mobile 

Touchscreen Interface for 

Multi-Modal Biometric Capture

Kristen K. Greene

Ross J. Micheals

Kayee Kwong

Gregory P. Fiumara

http://dx.doi.org/10.6028/NIST.IR.8003
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

NISTIR 8003

Design and Testing of a Mobile 

Touchscreen Interface for 

Multi-Modal Biometric Capture

Kristen K. Greene

Ross J. Micheals

Kayee Kwong

Gregory P. Fiumara

Information Access Division

Information Technology Laboratory

This publication is available free of charge from:

http://dx.doi.org/10.6028/NIST.IR.8003

May 2014

U.S. Department of Commerce 

Penny Pritzker, Secretary

National Institute of Standards and Technology 

Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and Director 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

ii

DISCLAIMER

Certain commercial entities, equipment, or materials may be identified in this document 

in order to describe an experimental procedure or concept adequately. Such identification 

is not intended to imply recommendation or endorsement by the National Institute of 

Standards and Technology, nor is it intended to imply that the entities, materials, or 

equipment are necessarily the best available for the purpose.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

iii

EXECUTIVE SUMMARY

In this report, we describe in detail the design and usability testing of a 

touchscreen interface for multimodal biometric capture, an application called WSABI, 

Web Services for Acquiring Biometric Information. The application code is publicly 

available online at https://github.com/NIST-BWS/wsabi2. The interface is a tablet-based 

reference application for the Web Services for Biometric Devices (WS-BD) protocol. Just 

as WS-BD specifies a method of communication between client and sensors (i.e., 

machine-to-machine communication), WSABI provides a consistent and modalityindependent method of interaction between human operators and sensors (i.e., human-tomachine communication). The interface’s common capture cards look and function the 

same across all modalities and all sensors; regardless of the biometric modality or sensor, 

users perform the same actions to capture, annotate, clear, and retake biometric data.

Similarly, users perform the same method of sensor setup regardless of the biometric 

modality or sensor. Most importantly, this design and functionality has been tested and 

found successful with real users, participants ranging in age, education, and tablet 

experience, who were unfamiliar with biometrics and given no training on the 

application. Given the success of the user-centered WSABI design, the National Institute 

of Standards and Technology (NIST) recommends that requirements for new systems 

include the guidelines in the “Design Recommendations” section of this document; 

including requirements will yield a more effective and efficient user interface for 

biometric operators, saving both time and money on operator training. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

iv

CONTENTS

List of Figures.................................................................................................................... vi

Introduction......................................................................................................................... 1

Direct Manipulation............................................................................................................ 4

No Training......................................................................................................................... 5

Study 1 ................................................................................................................................ 6

Method ............................................................................................................................ 6

Participants.................................................................................................................. 6

Materials and Procedure ............................................................................................. 7

Tasks........................................................................................................................... 9

Operator tasks ............................................................................................................. 9

Manager tasks ........................................................................................................... 10

WSABI Interface .......................................................................................................... 10

Results........................................................................................................................... 16

Operator Tasks.............................................................................................................. 16

Multi-modal capture.................................................................................................. 16

Retaking .................................................................................................................... 16

Annotating................................................................................................................. 17

Browsing results........................................................................................................ 18

Manager Tasks.............................................................................................................. 19

Creating a new workflow.......................................................................................... 19

Naming a new workflow........................................................................................... 20

Adding items to a new workflow.............................................................................. 20

Rearranging items within a new workflow............................................................... 21

WSABI redesign ............................................................................................................... 22

Study 2 .............................................................................................................................. 28

Method .......................................................................................................................... 28

Participants................................................................................................................ 28

Materials and Procedure ........................................................................................... 29

Tasks......................................................................................................................... 29

Manager Tasks.......................................................................................................... 29

Basic employee template .......................................................................................... 30

Guard template.......................................................................................................... 37

Operator Tasks.......................................................................................................... 38
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

v

“Alice” tasks ............................................................................................................. 39

Biographical information entry................................................................................. 39

Capturing................................................................................................................... 40

Clearing and retaking................................................................................................ 41

Annotating................................................................................................................. 41

“Bob” tasks ............................................................................................................... 42

“John” tasks .............................................................................................................. 43

Deleting an item........................................................................................................ 43

Deleting a record....................................................................................................... 44

Results........................................................................................................................... 45

Manager Tasks.............................................................................................................. 45

Basic new employee template................................................................................... 45

Left slap setup........................................................................................................... 45

Right slap setup......................................................................................................... 46

Face setup.................................................................................................................. 47

Rearranging icons ..................................................................................................... 47

Guard template.......................................................................................................... 48

Thumbs setup............................................................................................................ 48

Operator Tasks.............................................................................................................. 49

Biographical information entry................................................................................. 49

Multi-modal capture.................................................................................................. 50

Retaking and annotating ........................................................................................... 51

Deleting items and records........................................................................................ 51

Across manager and operator tasks............................................................................... 52

Saving ....................................................................................................................... 52

Discussion and Conclusions ............................................................................................. 53

Design recommendations.............................................................................................. 54

Future Directions .............................................................................................................. 56

Acknowledgements........................................................................................................... 60

References......................................................................................................................... 61

Appendices........................................................................................................................ 62
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

vi

LIST OF FIGURES

Figure 1. WSABI main screen, common capture card highlighted. ................................. 11

Figure 2. Partial screenshots, common capture card(s). ................................................... 12

Figure 3. Reverse side of a capture card (not to scale). .................................................... 13

Figure 4. Operator task, incorrectly completed. ............................................................... 13

Figure 5. Partial screenshot, operator task, correctly completed. ..................................... 14

Figure 6. Graphical workflow builder. ............................................................................. 14

Figure 7. Sensor popover in workflow builder. ................................................................ 15

Figure 8. Manager task, completed................................................................................... 15

Figure 9. Collections in non-editable (left) and editable states (right). ............................ 18

Figure 10. Manager task, create new workflow................................................................ 19

Figure 11. Scrollable list within a workflow item. ........................................................... 22

Figure 12. Front and back of common capture card in WSABI redesign......................... 22

Figure 13. Partial screenshot of biographical information section. .................................. 23

Figure 14. Multiple records, named record, and icons in redesigned WSABI. ................ 24

Figure 15. Common capture card popover, connected to compact representation of its 

associated biometric data item.................................................................................. 25

Figure 16. WSABI start screen for manager tasks in Study 2. ......................................... 30

Figure 17. First and second screens of sensor walkthrough: modality (left) and 

submodality (right) selection. ................................................................................... 31

Figure 18. Third screen of sensor walkthrough: add a new sensor................................... 32

Figure 19. Fourth and final screen of sensor walkthrough: sensor information. .............. 33

Figure 20. Active person record, after configuring a new sensor to capture a left slap. .. 34

Figure 21. Recent sensors list on third screen of sensor walkthrough.............................. 34

Figure 22. Partial fourth screen of sensor walkthrough during right slap setup............... 35

Figure 23. Active person record, after right slap setup..................................................... 36

Figure 24. Face submodality selection on second screen of sensor walkthrough. ........... 36

Figure 25. Active person record, after configuration of face capture............................... 37

Figure 26. Multiple records............................................................................................... 38

Figure 27. Biographical information task completed. ...................................................... 40

Figure 28. “Waiting for sensor” message during capture. ................................................ 40

Figure 29. Clearing an image............................................................................................ 41

Figure 30. Annotations...................................................................................................... 42

Figure 31. Delete-item task, editable (top) and non-editable (bottom) states................... 44

Figure 32. Delete-record task............................................................................................ 44

Figure 33. Edit/Done buttons and modal states for collection-deletion in Study 1 (top) 

versus item-deletion in Study 2 (bottom).................................................................. 52
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

1

INTRODUCTION

Currently, biometric devices are typically operated by proprietary software and 

drivers. Two problems arise from each device having its own vendor-specific software. 

First, operators require substantial training on each device, with software training for a 

single device ranging from four to six hours per operator (R. Bowlen, FBI, personal 

communication, November 30, 2012). With hundreds of devices, this adds up to 

significant money and time spent on operator training for the software alone, not 

including training on how to take proper prints and troubleshoot devices. Switching 

vendors means retraining those operators, even though their actual task has not changed. 

Second, capturing a multi-modal series of biometrics (e.g., fingerprints, iris, face) is a 

difficult task even for experienced operators, as they must interact with a different piece 

of software to control each device. These software differences mean that even when 

operator tasks (e.g., capture data, annotate, clear, retake) are conceptually identical across 

modalities and sensors, they can be procedurally quite different. The expense of having to 

train and retrain operators to complete differing procedures for identical tasks might be 

greatly reduced by making sensors interoperable. While there are obviously costs 

associated with creating interoperable frameworks, the long-term benefits outweigh the 

up-front costs.

Until recently, interoperable frameworks for biometric capture were virtually nonexistent. In 2006, the National Science and Technology Council Subcommittee on 

Biometrics began the National Biometric Challenge to develop middleware techniques

and standards to address the interoperability shortcoming. In response, the NIST 

Biometric Clients Lab developed MBARK, the Multimodal Biometric Application 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

2

Resource Kit (http://mbark.nist.gov). MBARK allowed different devices to talk to the 

same “middleman,” codifying a workflow structure for performing a series of captures. 

With MBARK, operators no longer had to switch between different pieces of software: 

the same user interface controlled a variety of sensors from a single desktop PC. While 

MBARK offered a unifying solution to the problem for Microsoft Windows desktop PCs, 

technology trends have since shifted away from the desktop environment and toward 

mobile touchscreen computing. For example, Apple has already sold twice as many iOS 

devices (i.e., iPads, iPhones, and iPod Touches) as all desktop Macs in history (Dediu, 

2012).

To address the widespread shift towards mobile computing, the NIST Biometric 

Clients Lab began work on a standard protocol, known as Web Services for Biometric 

Devices (WS-BD), to allow interoperable communication between software running on 

nearly any platform and nearly any kind of biometric device. Crucially, the protocol 

allows for both driver-free and wireless communication – both important factors in the 

world of mobile computing devices. WS-BD makes use of existing web technologies 

(HTTP, REST-style interaction, and basic XML) to enable this communication. Any 

device that can “talk the web” can control a WS-BD-enabled device. WS-BD was 

published as NIST Special Publication 500-288, and work is ongoing to make it an 

international standard through the International Organization for Standardization (ISO)

and the Organization for the Advancement of Structured Information Standards (OASIS).

The WS-BD protocol is platform- and operating-system agnostic, providing a common 

communication that allows physical separation between the client and sensors. The NIST 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

3

Biometric Clients Lab designed an iPad1application, called WSABI (Web Services for 

Acquiring Biometric Information) to exercise the WS-BD protocol in a reference 

application. WSABI allows the user to wirelessly control different sensors and capture 

biometrics from multiple devices. Just as WS-BD specifies a common communication 

protocol between client and sensor, WSABI gives the user a common interface to those 

sensors. We designed the interface with two main goals in mind: to leverage the inherent 

direct manipulation of a touchscreen device, and as much as possible, to require no 

training with the interface—even for novice users with no prior iPad or biometric 

experience. To determine whether these design goals were indeed realized, we conducted 

formative usability testing of the WSABI interface. Based on our first round of usability 

testing, we significantly redesigned the interface and conducted a smaller second round 

of testing with the new interface; the original interface and redesign are described in 

Study 1 and Study 2 Method sections, respectively. The focus of this work was testing 

the usability of the WSABI reference application for acquiring multi-modal biometrics; 

the sensors themselves were not tested, nor did we test the biometric data submission 

process. We focused on usability for the operator during the acquisition process. While 

previous work (Theofanos, Stanton, and Wolfson, 2008) has focused largely on usability 

for the end users whose biometrics are being captured, there are additional users who

must also be considered, such as those operating the various biometric sensors during the 

capture process. Our work contributes to the biometrics community specifically by 

addressing this user group, while also contributing to the larger HCI (human-computer 

interaction) field by informing general design of mobile touchscreen interfaces. Our work 

 

1 Note that although the WSABI reference application was designed for an iPad, any 

good tablet would work.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

4

complements existing best practice recommendations for capture, use, security, and 

transmission of mobile identification data (Orandi and McCabe, 2009) by adding user 

interface guidelines for touch-and-gesture-based biometric clients; our guidelines are 

based on formative usability testing results of the WSABI reference application. The 

application code is publicly available online at https://github.com/NIST-BWS/wsabi2.

DIRECT MANIPULATION

Touchscreen devices support direct manipulation by removing multiple levels of 

abstraction from user-device interactions. In a desktop paradigm, users operate a separate 

physical device (e.g., mouse, trackpad, head-tracker, eye-tracker) to control a 

representation of their hand on the screen (i.e., the mouse pointer). In contrast, the 

touchscreen paradigm removes this representational abstraction: users interact directly 

with the touchscreen via their own hands. A more subtle way in which touchscreens 

remove abstraction is by allowing users to act directly on an object rather than asking the 

system to perform the action for them. For example, touchscreens support using 

pinch/reverse pinch to directly resize an image, rather than selecting an image and using 

menu options or icons to then resize the image. The touchscreen interaction paradigm 

makes frequent use of gestures that parallel the physical world, such as picking up and 

moving an object (drag and drop), and pushing something out of the way or pulling

something towards you (natural scrolling). While other touchscreen gestures do not 

necessarily parallel the physical world (e.g., swipe to enable delete options or press-andhold to activate a contextual menu), they are motorically simple to execute and easy to 

remember once learned. Gestures that parallel the physical world are implemented 

similarly across a wide variety of touchscreen devices, whereas actions without such realworld parallelism are more likely to be platform- or device-specific. Well-designed 

touchscreen user interfaces take advantage of the years of natural control and experience 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

5

people have using their hands to physically interact with—i.e., directly manipulate—the 

world around them. This makes them more intuitive for all users, and less intimidating 

for novice users especially, regardless of age or previous computer expertise. 

NO TRAINING

The very nature of direct manipulation can drastically reduce the amount of user 

training required. This is especially true for touchscreen-native operating systems (e.g., 

iOS and Android), as opposed to those systems that simply shrink a previous desktop 

application to fit upon the reduced screen real estate of a smaller touchscreen device. 

Using a touchscreen-optimized operating system, iOS, is one way in which WSABI 

supported reduced user training. By leveraging the iPad’s inherent direct manipulation 

style, little—if any—training on basic interaction gestures is needed. However, simply 

moving to a touchscreen user interface is insufficient to guarantee zero user training will 

be necessary. The application and interface must be appropriately designed to truly 

leverage direct manipulation’s intuitiveness and consistency. To this end, we designed 

WSABI as a common capture interface that would be accessible to a novice. Multimodal 

capture is difficult to implement technically, but from a user’s perspective, all biometric 

captures should involve fundamentally the same actions. WSABI’s design revolved 

around this idea that users should not have to learn a new user interface per sensor or 

modality. By designing a capture interface that was consistent across sensors and 

modalities (see figures in Method section below), we hoped to further reduce user 

training requirements. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

6

STUDY 1

Method

Participants

Participants consisted of 16 NIST employees, primarily administrative personnel 

recruited via email. Participants volunteered their time for the half-hour usability study. 

The only eligibility requirement was a limited prior knowledge of biometrics. Note that it 

was not possible to recruit participants with zero biometric experience, as Personal 

Identification Verification (PIV) badge enrollment requires NIST employees to give a 

full set of prints. iPad familiarity was not required.

Of the 16 total participants, four were pilot participants (two male, two female), 

whose data are not included in the following results due to extensive prior experience 

with biometrics and/or user interface design and testing. All 12 remaining participants 

were female. Participants were fairly diverse in terms of age, education, and prior 

touchscreen experience. Age ranged from (30 to 39) to (60 to 79) years; education ranged 

from high school to Bachelor of Arts/Bachelor of Science (BA/BS) and Master of 

Arts/Master of Science (MA/MS); and touchscreen experience ranged from novice to 

expert. Using a Likert scale ranging from 1 to 5, with 1 being “not at all familiar” and 5 

being “very familiar”, participants were asked to rate their familiarity with using 

touchscreens to interact with a computer or phone. 

Table 1. Participant ages.

Number of participants Age range (years)

1 30-39

6 40-49

3 50-59

1 60-79

1 no response
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

7

Table 2. Participant education.

Number of participants Education

4 high school

4 BA/BS

3 MA/MS

1 no response

Table 3. Participant touchscreen familiarity (1=not at all familiar, 5=very familiar).

Number of participants Familiarity

1 2

5 3

5 4

1 no response

Materials and Procedure

The study was conducted in the Biometric Clients Lab (BCL) at the NIST 

Gaithersburg campus. A second generation Apple iPad running iOS 5 was connected via 

Wi-fi to multiple sensors that “spoke” WS-BD (Crossmatch Guardian fingerprint 

scanner, Logitech webcam), which were connected via Universal Serial Bus (USB) to a 

desktop PC running the WS-BD service on Windows XP. The WS-BD service was 

written by NIST BCL employees. The WS-BD specification enabled a standard 

communication between the collection device (iPad 2 running the WSABI application) 

and the sensors, and allowed the sensors to be physically separate from the device. A 

Panasonic HDC-TM900, 1080p video camera was mounted on a tripod and used to 

capture video recordings of the testing sessions. The tripod and camera were positioned 

behind and to the left of participants such that the camera focus was on the tablet and 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

8

sensors; participant faces were not recorded. Backup audio recordings were captured 

using the iTalk application by Griffin, installed on an iPhone 4, located on a table (180

cm x 60 cm) in front of participants. Audio and video recordings were supplemented by 

researcher notes, taken both during and after each study session. There was one active 

researcher and one observer. The former interacted directly with participants, while the 

latter sat at the back of the room (out of participant sight) to observe and take additional 

notes. The observer did not interact with participants, although they were informed of his 

presence. The researcher was seated to the right of participants; a line of black electrical 

tape divided the shared table into roughly equal halves. The sensors were located on the 

right side of the table, in front of the researcher, while the iPad was located on the left 

side of the table, in front of participants. The sensor platen and iPad were both cleaned 

before the arrival of each new participant.

Upon arrival, participants were greeted and shown to the table, where they sat for 

the remainder of the study session. After completing the informed consent procedure, 

they were given a short paper-based demographic questionnaire (Appendices 1 and 2, 

respectively). The researcher then gave a verbal overview of the study. Participants who 

had not previously used an iPad or similar device were shown a short general iPad video 

collage created specifically for this study. (Since the video contained only “novice” 

gestures, it was not shown to experienced participants.) The one minute video comprised 

Apple video clips (available from www.apple.com) showing basic gestures like tapping, 

flicking, scrolling, and zooming. This was done to provide all participants—even those 

with zero iPad experience—some level of familiarity with basic touchscreen interaction. 

This allowed us to better differentiate between usability of the WSABI application versus 

that of the iPad itself; while in some cases the two may be inextricably intertwined, we 

wanted to disentangle the effects as much as possible. 

After the study overview and iPad video, the researcher defined the terms 

biometric, sensor, and workflow (see Study 1 Scripts, Appendices 4 and 5), then showed 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

9

participants the two sensors (fingerprint scanner and webcam). The researcher

demonstrated different types of fingerprints—flat, rolled, both thumbs, single finger, 

slap—on the fingerprint scanner. Particular emphasis was given to the slap (all four 

fingerprints from a given hand, taken simultaneously), as it was used repeatedly in the 

testing tasks. Just prior to beginning the tasks, the researcher turned the iPad on, launched 

the WSABI application, and handed participants the device. The iPad’s orientation lock 

was on and all participants used the iPad in portrait mode. 

Tasks

All participants used the same iPad to complete two sets of tasks, “operator” and 

“manager” tasks. Task order was counterbalanced: half of participants completed the 

operator tasks first, while the other half completed the manager tasks first. The researcher

followed a script (Appendices 4 and 5) for each task set. Aside from explicitly defined 

terms (biometric, sensor, slap, and workflow), the testing script was written to avoid 

domain-specific technical terms where possible. However, note that for ease of 

discussion, such terms appear here. 

Operator tasks

For the operator tasks, participants played the role of an operator responsible for 

taking employees’ biometrics. The researcher played the role of presenter, acting as two 

employees, Alice and Bob. (“Presentation” is defined as the display of biometric 

characteristics to a sensor. Micheals, Stanton, Theofanos, & Orandi, 2006.) Participants 

were asked to use the CrossMatch scanner to collect Alice’s left slap print, then retake 

her left slap. Next, they were asked to use the webcam to collect Alice’s face image, 

followed by the CrossMatch to collect her right slap print. They were interrupted during 

the collection of the right slap, and asked to retake Alice’s face image. Finally, they were 

asked to mark Alice’s left slap print to indicate the index fingerprint could not be 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

10

acquired (Alice was wearing a bandage). Participants then captured Bob’s left slap and 

face image, without being asked to retake anything. However, during the capture of 

Bob’s right slap, participants were told Bob was not feeling well and could not continue, 

then asked what they would do in this situation. After Bob’s biometrics had been 

recorded, participants were asked to look at the results they had taken in more detail. In 

this final part of the operator task set, they were asked to open a left slap image in 

WSABI’s full-screen image viewer, zoom in to see it larger, browse to the next image, 

return to the previous image, then return to the main interface. 

Manager tasks

For the manager tasks, participants played the role of a manager, setting up the 

system so others could collect data. They were asked to make a new workflow, then call 

the workflow “Test Number [their participant number]”. They were asked to set up the 

workflow so that it used, in this order: 1) the CrossMatch sensor to capture a left slap, 2) 

the CrossMatch sensor to capture a right slap, and 3) the webcam sensor to capture a face 

image. Next, participants were asked to rearrange the steps inside the workflow so that 

the face image would be captured before the right slap. 

After participants completed both sets of tasks, they were asked four exit survey 

questions (Appendix 3). Time permitting, the researcher also discussed any additional 

interface characteristics that seemed problematic during the study session.

WSABI Interface

The main WSABI screen was divided horizontally into two distinct areas, the top 

area for capturing and annotating biometrics, and the bottom area for creating and editing 

new biometric collections (Fig. 1). 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

11

Figure 1. WSABI main screen, common capture card highlighted.

Operator tasks were designed primarily to test the effectiveness of WSABI’s 

“common capture card” (Fig.1 and Fig. 2). Capture cards used action icons (an animated 

hand to indicate “touch here to start capture” and a [static] pencil to indicate “edit”) that 

were consistent across modalities and sensors. Only the area immediately below the 

capture area could differ between cards (e.g., “Left Slap, Crossmatch” versus “Face, 

webcam”).
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

12

Figure 2. Partial screenshots, common capture card(s).

Just as the WS-BD standard specifies a common communication protocol between 

client device and sensors, WSABI’s capture cards were designed to support consistent 

interactions between the user and device: users execute the same actions regardless of 

sensor or modality. Always tap where indicated by the animated hand to start a capture; 

always tap the pencil icon to edit. More specifically, tapping on the pencil “edit” button 

in the upper right corner flips the card over (Fig. 3) to allow users to clear results or 

annotate individual prints or face images. This “flip” animation is common across a 

variety of iOS applications (e.g., to show track information within the Music app), and 

illustrates two important design concepts: 1) leveraging the use of animation styles and 

design elements consistent with other iOS applications, and 2) supporting direct 

manipulation of objects, in this case by mimicking people’s real-world experience with 

turning over a physical artifact, such as a photo to annotate the date taken on the back. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

13

Figure 3. Reverse side of a capture card (not to scale).

After biometrics were recorded, the operator task screen would have two 

collections, one row each for Alice and Bob (Figs. 4 and 5). 

 

Figure 4. Operator task, incorrectly completed.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

14

Figure 5. Partial screenshot, operator task, correctly completed.

The manager task set was designed to test the WSABI graphical workflow builder 

(Fig. 6). Although the concept of a workflow was present in the Multimodal Biometric 

Application Resource Kit (MBARK), building workflows there was a complicated 

textual task that required editing raw .xml files; this was accomplished using the 

Biometrics Client Configuration Language, or BiCCL, a domain-specific language for 

formally describing biometric client configurations and desired workflows (Aronoff and 

Micheals, NIST IR 7531). Aside from the change from text-based to GUI-based 

workflow building, workflows in WSABI are conceptually similar to those in MBARK, 

i.e., both implement the concept of a “workflow as container.”

Figure 6. Graphical workflow builder.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

15

Users could add items to a workflow in two different ways: 1) press and hold to 

drag a sensor from the shared sensor list on the left to the workflow area on the right, or 

2) tap a sensor in the shared sensor list and select “Add to workflow” from the resulting 

popover (Fig. 7). 

Figure 7. Sensor popover in workflow builder.

Once the manager task set was completed, the empty boxes in the workflow builder 

area (previous Fig. 6) would then appear as shown in Figure 8.

Figure 8. Manager task, completed.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

16

Results

Operator Tasks

Multi-modal capture

Perhaps the single most important result was the success of WSABI common 

capture cards. Using these capture primitives, all participants were able to record multimodal biometrics from different sensors; no modality was easier or more difficult than 

another. In some cases, participants instructed the researcher (in the role of Alice) to 

place her hand on the sensor before starting the capture. When no image appeared on the 

iPad, participants then realized an action was necessary on their part; they then tapped 

where indicated by the animated hand on the iPad to start capturing. Some participants 

initially tapped the small fingerprint icon (in the lower left corner of the capture card) 

before tapping on the animated hand. Nonetheless, in all cases users successfully 

recorded biometrics. 

Retaking

Initially, retaking prints and images was accomplished simply by tapping the 

animated hand a second time. After testing with only a single participant, the destructive 

nature of this implementation was clearly evident. When a user tapped the icon, it started 

a new capture immediately, which instantly overwrote existing data. Since this issue was 

both severe and easily addressed, it was fixed prior to testing with the remaining 

participants. The issue was addressed by implementing an explicit clearing action before 

retaking was allowed. Once an image was acquired, the animated hand icon disappeared. 

To retake an image, the user had to tap the pencil edit button in the top right of the 

capture card, and select the “clear result” option from the resulting popover. After 

clearing the existing result, the hand icon would reappear to allow a new capture. The 

new implementation worked well, preventing users from accidentally overwriting data, 

while still allowing them to easily clear and recapture data.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

17

Annotating

Using a button containing a pencil icon to initiate annotation was successful 

overall, but there was some confusion over the wording of the annotation choices. For 

example, many users hesitated to select “unprintable” to indicate that Alice’s left index 

fingerprint could not be acquired (recall that “Alice was wearing a bandaid”). Even in 

cases where participants expressed this uncertainty, they still correctly selected 

“unprintable” rather than “amputated.” More interesting was the unintended annotation 

task for Bob’s right slap. Partway through Bob’s right slap collection, participants were 

told that he was sick and could not continue. This was intended to prompt use of the 

“cancel” action. Overwhelmingly, participants attempted to annotate this capture card, 

explicitly expecting a “notes” field or some other method to indicate why the print was 

not taken. In several cases, participants marked all four of Bob’s fingers as unprintable as 

a work-around. 

The annotation task also illustrated conceptual issues with the Edit and Done 

buttons on the collection row. Edit and Done are modal: the same button holds both 

functions. As soon as the Edit button is tapped, items are put in an editable state and the 

button label changes to “Done”. As soon as the Done button is tapped, items are no 

longer editable and the button label reverts back to “Edit”. The modal Edit/Done or 

Edit/Cancel concept is consistent with the iOS Human Interface Guidelines (HIG) 

(Apple, 2014). In some cases, participants would tap the Edit button next to the active 

collection (on the bottom half of the screen), then complete the annotation task on the 

capture card (on the top half of the screen). Tapping the collection’s Edit button was 

intended to allow deletion of that entire collection, and it remained in this “editable” state 

(with the standard iOS red deletion circles present, Fig. 9) until the Done button was 

tapped. 

 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

18

Figure 9. Collections in non-editable (left) and editable states (right).

Some participants tapped the Done button immediately after annotation, whereas others 

did not tap Done until they were completely “done” with Alice and Bob’s capture tasks. 

The more general desire to indicate “done-ness” by explicitly saving data was common.

This is not surprising given that the need to save is deeply ingrained in the traditional 

desktop paradigm. The saving issue was not unique to the annotation tasks, and also arose 

during workflow building.

Browsing results

When asked to open a left slap image full-screen, some participants double-tapped 

the image and others reverse-pinched. Since WSABI supported multiple interaction 

gestures, in both cases users successfully opened the image in full-screen mode, 

regardless of whether they double-tapped or reverse-pinched. Note that if a given result 

was zoomed in beyond the bounds of the screen, the user could not browse to the next 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

19

image without first zooming out or scrolling to the edge of the zoomed-in image. Several 

users tried to move to the next image without initially realizing they had to zoom out 

from the current image view. Some users swiped to browse between captured images, 

whereas others tapped on the white arrows at the bottom of the screen. Again, since 

multiple methods were supported, users were successful either way. In contrast, returning 

to the main interface posed a difficulty for many users. After several seconds of 

inactivity, the done button and navigation arrows “fade out”. Not realizing that they could 

tap to make the controls reappear, many users pressed the physical iPad home button. 

While this is an interesting result, it does not seem to be specific to the WSABI interface. 

The iOS Photos application operates in a similar way, and in fact, the “fade away” and 

“tap to make reappear” actions were shown briefly in the iPad video. 

Manager Tasks

Creating a new workflow

In order to access the workflow builder screen, participants had to tap the 

“Workflows” button on the main operator screen. From the resulting popover, they then 

had to tap the plus button (Fig. 10).

Figure 10. Manager task, create new workflow.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

20

The workflow button itself was often difficult for participants to find, and once found, the 

embedded plus button posed even greater difficulty. Within the workflow popover, 

participants often tapped on the edit button and/or one of the other menu items, which 

would launch a previous workflow rather than creating a new one. Simply getting to the 

workflow builder often posed a significant issue and required additional researcher

prompting. 

Naming a new workflow

Initially, one could set the title of a new workflow by tapping the title bar within the 

graphical workflow builder, which would bring up the onscreen virtual keyboard. The 

first few participants did not notice the “Press to set workflow name” prompt on the title 

bar, and created a nameless workflow. This was partially addressed by automatically 

highlighting the title text and bringing the keyboard up as soon as the workflow builder 

screen was accessed. However, some users still experienced difficulty due to overlooking 

the virtual keyboard at the bottom of the screen.

Adding items to a new workflow

As previously described, there were two different ways that items could be added to 

a new workflow. Each method posed unique difficulties for participants. The first 

method, drag and drop, suffered from timing implementation issues. The “press and 

hold” time required to make a sensor “draggable” was too long. Several participants 

attempted this method using the correct interaction technique, but tried moving the sensor 

too quickly, i.e., before it was in a “draggable” state. When participants tried this method 

multiple times without success, the researcher explained the timing lag. If the drag and 

drop method failed participants yet again, the researcher explained that there was an 

alternative method, and suggested they try tapping on the sensor. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

21

The second method, tap and select, gave rise to the most severe errors. As shown in

previous Fig. 7, tapping a sensor displayed a popover with two options, “Add to 

workflow” and “Edit properties.” Many participants chose “Edit properties” rather than 

“Add to workflow,” which was the target option. Of those participants, upon reaching the 

sensor properties menu, a few hit “cancel” and backed out immediately. Others 

proceeded to unintentionally edit shared sensor properties or even delete a sensor 

entirely, rather than adding the shared sensor to the workflow they were building. Editing 

properties belonging to a shared sensor, or deleting a shared sensor, had severe and 

lasting consequences for any existing workflows using that same sensor. As workflows 

contain permanent shared representations of sensors, deletion or modification of shared 

sensors can irreparably break multiple workflows. Finally, in attempting to add an item to 

the workflow builder, several participants added an entirely new sensor by tapping the 

plus on the shared sensor list (previous Fig. 7). Even without entering a valid IP address, 

they were able to add a new sensor to WSABI’s shared sensor list.

Rearranging items within a new workflow

Rearranging items within a workflow was much less problematic than adding them. 

Participants clearly understood the rearranging task and attempted the appropriate 

interaction gestures to accomplish it. However, two interface issues prevented many 

participants from completing the task on their first try: 1) a long drag and drop timing 

delay, and 2) accidental activation of a scrollable area within the card. As with the drag 

and drop to add task, the “press and hold” time required to make an item “draggable” was 

too long. Several participants attempted to rearrange the items using the correct gesture, 

but tried moving an item too quickly, i.e., before it was in a “draggable” state. In some 

cases, the gesture resulted in moving a scrollable list within the item itself (Fig. 11). This 

scrolling list was intended to support recording additional information in the future, i.e., 

more information than could be displayed in the current item. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

22

Figure 11. Scrollable list within a workflow item.

WSABI REDESIGN

There were two primary goals when redesigning the WSABI interface to 

incorporate Study 1 user testing results: keep what worked well, and fix what didn’t. For 

the operator task set, WSABI’s original common capture card and annotation interface 

worked extremely well. The redesign kept capture and annotation intact as part of a 

single object, again representing a capture card as an analog of a directly manipulable 

physical object with a front and a back (Fig. 12). 

Figure 12. Front and back of common capture card in WSABI redesign.

The redesign implemented a biographical record section (Fig. 13) with specific 

fields and option choices, such as name, gender, age, hair color, and eye color. The 

capability to record biographical data—and thereby identify a collection by name or other 

biographical characteristic—was not previously present. A free-form notes field was also 

added in the WSABI redesign, in order to address participants’ desire to note specifically 

why a biometric wasn’t captured (i.e., Bob wasn’t feeling well and will return tomorrow). 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

23

Figure 13. Partial screenshot of biographical information section.

For the manager task set, the redesign sought to address shortcomings found in the 

workflow creation task. Based on the difficulty and severity of errors found during user 

testing, the concept of a workflow clearly needed revising. In WSABI’s original 

conceptual model, the workflow was a static “container” for particular sequences of 

biometric data (e.g., a left slap followed by a right slap followed by a face image). The 

consequences of a static container model were problematic: any workflow that contained

data could not be restructured, because the data already in the container would become 

invalid. This approach was significantly at odds with the hands-on nature of the 

touchscreen interface, as well as with user expectations. Consequently, the conceptual 

approach to capturing multiple biometrics changed significantly in the redesigned 

interface. In the WSABI redesign, the canonical object became the “person,” rather than 

the “workflow.” Each person could then have any sequence of associated biometric data,

and each item in that sequence had all the necessary information to communicate with a 

relevant biometric sensor. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

24

Simplifying the conceptual model allowed us to map the user interface more closely 

to that model, as well as to bring direct manipulation philosophies to bear upon the 

weaknesses of the previous design. In the WSABI redesign, each person was represented 

by a single row (Fig. 14). All information related to that person was contained in that 

row. For example, the new biographical information area was available as a selfcontained entry area accessible from a button in the top left; that button’s text comprised 

the name contained in the biographical information area. Each biometric data item 

appeared as part of a grid within the cell. The compact representations of biometric items 

from the previous design were reused with one small modification to the finger icon: it 

was now angled slightly to discourage people from trying to place their thumb there. 

Recall that while the compact representations largely worked well during user testing, 

there were several instances where participants erroneously pressed their thumb on the 

fingerprint icon. 

Figure 14. Multiple records, named record, and icons in redesigned WSABI.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

25

Tapping the compact representation displayed the common capture card within a 

popover connected to that representation, so that contextual information about the 

relationship between the capture card and the biometric item was more readily available 

(Fig. 15). The biometric modality and submodality, as well as the associated sensor, are 

shown in breadcrumb bars (the arrow-shaped buttons labeled “Right Slap” and “Finger 

Sensor” in Fig. 15) within the common capture card.

Figure 15. Common capture card popover, connected to compact representation of 

its associated biometric data item.

With the exception of removing the concept of a static workflow, by far the most 

significant change in the redesigned WSABI was the new sensor setup walkthrough. The 

concept of a static workflow made the original interface sensor-centric, requiring users to 

know names and technical capabilities of a sensor in order to select it from a sensor list 

(as in previous Fig. 7). If an operator’s task is to collect a fingerprint, why show them any 

sensors that cannot capture fingerprint data? In sharp contrast to the exhaustive list of 

sensors ever-present in the original interface (i.e., sensor-centric), the redesigned sensor 

setup process was user- and task-centric, walking users through the process based on 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

26

what biometric information they were trying to collect, and showing only sensors with 

the capability to collect that type of biometric data. Sensor setup was not tested at all in 

Study 1; with the original interface, all sensors were set up before testing and participants 

had to select them from a list on the separate workflow builder screen. In Study 2, the 

sensor setup process was a primary focus of usability testing; participants had to set up 

multiple sensors from scratch (described in the Study 2 Task section). 

The substantial changes to the user interface and conceptual model meant 

analogous changes for the underlying iOS code and data model. Whereas the original 

WSABI data model required a stand-alone, persistent representation of a sensor, the new 

interface did not. Additional code changes included those necessary to update WSABI to 

the latest iOS version (at the time, iOS 6.1), as well as the instrumentation of touchlogging. Touch-logging capabilities were added during the WSABI redesign to help 

capture more fine-grained data, which in turn informed computational cognitive 

modeling efforts (Greene, Tamborello, and Micheals, 2013; Greene and Tamborello, 

2013). To make touch analysis easier and enable potential future automation of analysis, 

information about the user's interaction with the device was also recorded. A file 

containing a readable account of the WSABI usage could be offloaded after the 

participant's session had concluded.

This interaction log was made possible by features inherent to most user interface 

elements in the iOS software development kit (SDK), specifically by leveraging the iOS 

responder chain. Many human interactions with a device running iOS create "usergenerated events" in the operating system. Almost any interaction, such as a swipe, 

touch, or shake, can be considered an event (Apple, 2013). Apple has continued to add 

new classifications of events with newer versions of their hardware and software. When a 

user-generated event occurs, the operating system follows a simple path to alert interested 

parties that the event has taken place, known as traversing the responder chain.

Consider this (extremely simplified) example of touching a button on the screen, 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

27

starting in software. The operating system notifies the currently running application that a 

touch event occurred at a specific coordinate. That application then traverses the various 

user interface elements currently displayed on the screen at that coordinate, alerting the 

backing object that the event has occurred. This starts with the "first responder," which is 

typically the user interface element most in the foreground of the application. From there, 

the object may respond to the event, or forward the event to the next interested party.

Under normal circumstances, a developer may very well never have to interact with 

the responder chains. This is because all iOS SDK user-interface elements handle the 

standard user-generated events in a predicable way, making possible common-day 

"event-driven programming." In the case of WSABI, there were certain touch-based 

interactions we wanted to record in order to enhance the user interface of the application. 

For the user interface elements and user-generated events we were interested in, a simple 

line of text was recorded as the responder chain traversed the object. This line would 

include a description of the user interface element on which the event was triggered, the 

coordinates of the event in terms of the user interface object and the device, and any other 

pertinent information depending on the interaction type. Where possible, a gesture 

recognizer was used for the logging, so as to not have to predict whether or not the usergenerated event should be canceled, dealt with, or forwarded. This critical task was 

instead left to the SDK element's default value. Gesture recognizers have a property in 

which they can be simultaneously notified of an event along with their containing object. 

In the case of the person list, this meant that we could continue to scroll the list while 

recording the change in position of the list and inferring the user's finger movement, all 

without causing any undesired visual conflicts. In the end, this allowed a precise readable 

account of the participant's usage of the application.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

28

STUDY 2

Method

Participants

Unless otherwise noted, Study 2 Method mirrored that of Study 1. Participants 

consisted of seven NIST employees (six females, one male), five of whom participated in 

Study 1. Participants were again fairly diverse in terms of age, education, and prior 

touchscreen experience. Age ranged from 21-29 to 50-59 years; education ranged from 

high school to PhD; and touchscreen experience ranged from average to expert.

Table 4. Participant ages.

Number of participants Age range (years)

2 21-29

1 30-39

2 40-49

2 50-59

Table 5. Participant education.

Number of participants Education

2 high school

3 BA/BS

1 MA/MS

1 PhD

Table 6. Participant touchscreen familiarity (1=not at all familiar, 5=very familiar).

Number of participants Familiarity

3 3

1 4

3 5
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

29

Note that although Study 2 participants rated themselves as slightly more familiar with 

touchscreens than did Study 1 participants, of the three who rated themselves as very 

familiar, only one mentioned being familiar with a tablet.

Materials and Procedure

An iPad 2 with high-resolution display running iOS 6.1 was used in Study 2. While 

a Crossmatch fingerprint sensor was used in Study 1, a Suprema fingerprint sensor was 

used in Study 2. It is important to emphasize that across both studies, we were testing the 

usability of the WSABI interface and not the sensors themselves. Since the WS-BD 

protocol is device-agnostic, it was important to use sensors from different manufacturers. 

In addition to these changes in materials, several modifications were made to the 

procedure in Study 2. There was no longer an observer in the room during testing; other 

than the participant, only the researcher was present. The general iPad video comprised 

of Apple video clips was no longer shown, and the script and background information 

given were even further reduced in Study 2. For example, the explanation of rolled versus 

flat fingerprints was not given; since participants were not asked to take rolled 

fingerprints, this information was superfluous. Manager/operator task roles were no 

longer counterbalanced in Study 2; since one of the primary goals was now testing the 

sensor walkthrough, we wanted participants to configure sensors (i.e., the manager tasks) 

before using them to collect any data (i.e., the operator tasks). In front of both the face 

sensor and the finger sensor were white placards, each with the respective sensor’s 

network address and name printed in black ink. 

Tasks

Manager Tasks

Since the concept of a fixed workflow was removed in the redesigned WSABI, 

rather than using the term “workflow” for manager tasks in Study 2, we used the more 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

30

appropriate term “template.” The manager tasks were to set up two templates, one for a 

“basic employee” enrollment (left slap, right slap, face) and one for a “guard” (same as a 

basic employee, but with the addition of a thumbs slap). This required configuring two 

different sensors, a fingerprint sensor and a face sensor (Suprema and Logitech, 

respectively). While the following sections describe the individual tasks in great detail, it 

is important to emphasize that participants were not given these step-by-step instructions 

(see Appendix 6 for Study 2 Script). They were intentionally given as little information 

as possible. For example, the only instructions they were given for the left slap 

configuration task were: “The first thing you want to set up is the capability to record a 

left slap, from this sensor,” which was accompanied by the researcher pointing at the 

Suprema fingerprint sensor. 

Basic employee template

When participants were handed the iPad at the start of testing, the WSABI 

application only showed a circular plus in the center of the screen (Fig. 16). One must tap 

this button to start the sensor walkthrough. 

Figure 16. WSABI start screen for manager tasks in Study 2.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

31

The next required action is a tap on the finger button to select the capture type (biometric 

modality) on the first screen of the sensor walkthrough, followed by a tap on the left slap 

button to select submodality on the second screen of the sensor walkthrough (Fig. 17).

Figure 17. First and second screens of sensor walkthrough: modality (left) and 

submodality (right) selection.

The previously selected modality appears at the top of the walkthrough, and what 

functions as the “back” button is instead labeled with “Capture Type” to indicate what 

tapping it would navigate back to. Again, note that on both the modality and submodality

menus, the most frequently used options are at the top of the list. The next required 

action is a tap on the “add new sensor” button on the third screen of the sensor 

walkthrough (Fig. 18). Notice the walkthrough is now labeled with the chosen modality 

and submodality, and the “back” button is again labeled with information on what 

tapping it navigates back to. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

32

Figure 18. Third screen of sensor walkthrough: add a new sensor. 

The fourth and final screen of the sensor walkthrough sequence had three subtasks 

(Fig. 19). Notice how the sensor name appears at the top of the walkthrough, and again 

the “back” button is informatively labeled. 

1) Tap in the “Network address” text field to bring up the keyboard and enter a sensor’s 

IP address. We used "test.me/finger" as the address, so that participants did not have to 

change onscreen keyboards to find the numbers that would be required in a typical IP 

address. After a network address is entered, the system automatically tries to connect 

to a sensor located at that address. While checking, the message “Checking” along 

with a moving activity symbol appears. When a sensor is found, a green checkmark 

appears with the message "Found a sensor at this address." If one is not found, the 

message “No sensor found at this address” would appear, along with a button labeled 

“Check again.” 

2) Tap in the “Name” text field to enter the name of the sensor. Note that it is not 

necessary to enter a sensor name per se; a network address is the only critical 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

33

information to enable WSABI to communicate with a sensor. During testing we used 

"Finger Sensor" rather than “Suprema” as the sensor name. By using generic words, 

this allowed users to take advantage of the native iOS autocorrect features.

3) Tap the “Done” button in the upper right corner of the sensor walkthrough to finish the 

process and save entered information. Note that after a network address is entered, the 

Done button changes from gray (inactive) to blue (active). 

Figure 19. Fourth and final screen of sensor walkthrough: sensor information. 

After stepping through setting up a left slap with the sensor walkthrough, a new 

person record is created. It contains a single fingerprint icon with the words “Left Slap” 

underneath (Fig. 20). 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

34

Figure 20. Active person record, after configuring a new sensor to capture a left slap. 

Setting up a right slap was the next manager task. To add a new biometric, start 

with a tap on the square plus button on the left side of the active person record (previous 

Fig. 20). This brings up the sensor walkthrough. As before, tap the “Finger” menu button 

to select capture type/modality on the first screen of the sensor walkthrough (previous 

Fig. 17). On the second sensor walkthrough screen, tap the “Right Slap” button; note that 

it is immediately below the previously selected “Left Slap” button (previous Fig. 17). On 

the third screen, recently created/used sensors are listed under “Recent sensors” at the top 

of the screen. Therefore, instead of tapping the “Add a new sensor” button (previous Fig. 

18), it is only necessary to tap the button with the name of the desired sensor, “Finger 

sensor” in this case (Fig. 21). While multiple sensors are shown for illustrative purposes 

in the screenshot (Fig. 21), during testing only one recent sensor appeared in the list.

Figure 21. Recent sensors list on third screen of sensor walkthrough. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

35

On the fourth screen of the sensor walkthrough, the network address and sensor 

name fields are auto-populated with the information previously entered for the selected 

sensor. Again, the system would automatically check for a sensor at that address (Fig. 

22). Note that the back button (Fig. 22) now says “Right Slap” whereas during setup of a 

left slap (previous Fig. 19), it said “Left Slap”.

Figure 22. Partial fourth screen of sensor walkthrough during right slap setup. 

A green checkmark and the message “Found a sensor at this address” then replace 

the “Checking” message, and a user must tap on the “Done” button to save settings and 

exit the sensor walkthrough (Fig. 22). A second fingerprint icon, with the words “Right 

Slap” underneath, is then added to the same person record created during the left slap 

setup task. The new icon is added to the end of the active person record (Fig. 23). All 

other buttons remain in the same location; for all tasks involving adding a new biometric, 

the user is tapping the same target (the square plus button) in the same location to bring 

up the sensor walkthrough.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

36

Figure 23. Active person record, after right slap setup.

After the right slap configuration task, the next manager task was to set up a face 

image. To add a new biometric, as before, tap the square plus button on the active person 

record to enter the sensor walkthrough. On the first screen of the sensor walkthrough, tap 

the Face button to select the face modality. The Face button is immediately below the 

Finger button; the most frequently used biometric modalities are always at the top of the 

list. On the second screen, tap the face button to select a “regular” two-dimensional (2D) 

face image rather than a three-dimensional (3D) one (Fig. 24). 

Figure 24. Face submodality selection on second screen of sensor walkthrough.

On the third screen, tap the “Add a new sensor” button. Had any face sensors been 

previously configured, they would have been listed under “Recent sensors” on this 

screen. Only sensors relevant for the chosen modality and submodality are displayed to 

the user in the sensor walkthrough. On the fourth screen of the walkthrough, enter 

“test.me/face” in the network address field, and “Face sensor” in the sensor name field. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

37

Again, wait for the green checkmark and “Found a sensor at this address” message to 

appear, then tap the “Done” button. A face icon with the word “Face” underneath is then 

added to the same person record, at the end of the row (Fig. 25).

Figure 25. Active person record, after configuration of face capture.

We then asked participants to organize the screen so that the face was first. All 

biometric data icons within a person record can be rearranged using the “drag and drop” 

method common across most touchscreen devices. Simply press and hold the face icon 

until it wriggles, then drag it to the left of the two fingerprint icons. Release it (drop it) 

and the other icons automatically move to the right to accommodate it. Since biometrics 

can be captured in any order, such rearrangement was not actually necessary; we merely 

wanted to test the direct manipulation affordances of WSABI’s biometric icons. After 

setting up a left slap, right slap, and face, then rearranging the biometric icons, the basic 

employee template creation was completed. 

Guard template

The next manager task was to create a guard template, which is identical to the 

basic employee, with the addition of a thumbs slap. There are multiple ways to do this, 

depending on whether one wishes to create an entirely new template or merely modify 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

38

the existing one. To create a new template, tap the “New Person” button. This creates a 

new person record identical to the previous one, set up to capture face, left slap, and right 

slap (Fig. 26). The new person record is created below the existing one(s), and 

automatically becomes the active row; all other records are grayed out. As before, to add 

to the current template, simply tap the plus button to bring up the sensor walkthrough and 

configure a thumbs slap. Select “Finger” on the first screen; select “Thumbs Slap” on the 

second screen; select “Finger sensor” under recent sensors on the third screen; wait for 

the “Found a sensor at this address” message and tap “Done” on the fourth screen. If 

someone chose to modify the existing template rather than create a new one, the only 

difference in procedure would have been an omitted tap on the “New Person” button. 

Figure 26. Multiple records.

Operator Tasks

As in Study 1, the researcher played the role of different employees, and the participant 

played the role of an operator responsible for taking employees’ biometrics. Before 

starting the operator tasks, the researcher handed the participant a different iPad with a 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

39

single person record on it; that record contained no data, but was configured to capture a 

left slap, face, and right slap. 

“Alice” tasks

First, the researcher again played the role of Alice. As in Study 1, participants were 

to capture a left slap; clear and retake the left slap; capture a face image; start the right 

slap but interrupt to retake the face; return to finish the right slap; annotate the left slap 

due to a bandaid making the left index finger unprintable. An entirely new task 

(biographic information entry) was added to the beginning of the original Alice task 

sequence in order to test the new biographic information fields. 

Biographical information entry

For the new biographical information task, the researcher pulled a badge from her 

NIST badge holder and handed it to the participant. Along with the researcher’s picture, 

the badge contained only three pieces of biographical information, in the following order 

(with similar alignment and spacing): 

Name: Alice. 

DOB: January 1, 1981. 

Gender: Female. 

To enter biographical information, tap on the button labeled “Tap to set name.” 

Then tap on the First Name field to bring up the onscreen keyboard and type Alice. Next, 

tap on the DOB button, scroll to select the appropriate date, and tap Done when finished. 

Tap the Gender button, scroll to select, and tap Done when finished. The DOB and 

gender biographical information wheels, and the completed fields, are shown in Fig. 27. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

40

Figure 27. Biographical information task completed. 

Capturing

To capture a left slap, tap the small left slap icon to bring up the large capture card, then 

tap the animated hand on the capture card to start the capture (previous Fig. 12). The 

presenter (in this case, the researcher) places her left hand upon the sensor, then the slap 

image appears in the capture card on the iPad. A small thumbnail version of the image 

also appears in the previously empty left slap icon. During any delay while the tablet is 

communicating with the sensor, a “Waiting for sensor” message appears in the capture 

card (Fig. 28).

Figure 28. “Waiting for sensor” message during capture. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

41

Clearing and retaking

To clear (or annotate) the image, tap the pencil edit button in the upper right corner of the 

capture card. Options slide up within the capture card: Clear this image, Annotate, or 

Cancel. Tap the “Clear this image” button. Since clearing is a destructive action, a 

confirmation is required. Tap the “Clear” button to confirm. (Clearing and confirmation 

both shown in Fig. 29.)

Figure 29. Clearing an image.

After an image is cleared, the animated hand reappears within the capture card and the 

system is ready to retake an image. Since the process for retaking/taking the other 

biometrics is identical, additional screenshots are not shown here for the right slap and 

face capture tasks. 

Annotating

To annotate the left slap indicating Alice’s index finger could not be acquired due 

to her bandaid, first tap on the small left slap icon to bring up the capture card. Next, tap 

the pencil edit button, tap the “Annotate” button, and the capture card flips over. We 

simplified the annotation options from Study 1, replacing the unprintable versus 

amputated options with a graphical symbol (Fig. 30). Tap on any or all of the fingers 

listed to indicate an issue printing that finger; tap again to remove the symbol. Enter any 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

42

notes, such as “bandaid”, in the free-form notes field. Tap the “Done” button to flip the 

capture card back over. On the front side of the capture card, a blue annotation badge has 

now appeared on the pencil edit button. A matching blue annotation badge has also 

appeared on the small left slap thumbnail in the person row.

Figure 30. Annotations. 

“Bob” tasks

As in Study 1, after playing the role of Alice, the researcher played the role of Bob. 

As before, participants were to create a new record, then capture a left slap, face image, 

and right slap. During the right slap capture, “Bob” said he was not feeling well and 

could not continue. In Study 1, this “not feeling well” scenario was designed to test the 

explicit capture cancel button. In Study 2, there was no longer an explicit capture cancel 

button (simply tap outside the popover to dismiss it, as with most touchscreen popovers). 

However, we kept the scenario, because we were interested in seeing whether people 

would use either of the two new free-form notes fields, one on the back of the capture 

card, and one at the bottom of the biographical information field. The only new task 

during the Bob scenario was the naming task. The participants were told “So we can tell 

the two employees apart, please indicate that this is Bob.” First name was the only 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

43

biographical information entered for Bob.

“John” tasks

The researcher then played the role of another employee, John. These tasks were 

entirely new, as there was no John scenario in Study 1. In this scenario, participants were 

told John was a current employee who just needs a picture for a replacement badge. They 

were to capture his face image, after which they were told “His fingerprints are already 

on file, so please remove the fingerprints from his row.” This was designed to test the 

new delete-item functionality. (Recall that in the original WSABI, one could only delete 

an entire collection; there was no option to delete individual biometric items.) 

Deleting an item

To delete an item, tap the Edit button at the top of the active record. All items are 

now in an editable state, with a red X over the center of each item; in this editable mode, 

the Edit button is changed to a Done button. To delete an individual item, tap on the red 

X in its center, then tap the “Confirm Delete Item” button. The sequence of delete-item 

actions is shown in Fig. 31, with Edit/Done buttons circled. Note that the red Xs are 

located in the center of the icons rather than in their upper right corners. While the latter 

position is common when icons are in an editable state on the iOS home screen, we did 

not want to give the impression that items were rearrangeable in this case. We 

intentionally removed the “drag and drop” affordances by placing the Xs in the center of 

the icons, exactly where people would be most likely to press-and-hold to execute a drag.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

44

Figure 31. Delete-item task, editable (top) and non-editable (bottom) states. 

Deleting a record

To test the delete-record functionality, participants were told that “Your boss calls 

and says John just retired, so please remove his row entirely.” To delete a person record, 

tap the X button in the upper right corner of the active record, then tap “Delete this 

person.” The entire record is covered with a red highlight, over which the buttons 

“Cancel” and “Confirm Delete Person” appear (Fig. 32). Tap “Confirm Delete Person” to 

delete the entire record. 

Figure 32. Delete-record task.

As with the clearing of an image, deleting a biometric item or an entire person record are 

destructive actions, hence an explicit confirmation is required for all. Note that 

technically the delete-person action actually requires a second confirmation, since of the 

various delete functions, it could result in the greater amount of lost data if done 

accidentally. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

45

Results

Manager Tasks

Basic new employee template

Left slap setup

All participants advanced successfully through selecting the finger modality, left 

slap submodality, and selecting “add a new sensor” to make it to the sensor information 

screen of the sensor walkthrough. There was one participant who hesitated over selecting 

the finger modality for the capture type, saying “If it’s not finger, I would try Other”. 

This makes perfect sense for someone with little background in biometrics; we asked for 

a left slap, and left slap is not displayed as an option until the modality selected is finger. 

Interestingly, the greatest difficulty users had during the left slap configuration task 

was typing in the sensor name and network address. Recall that on the placard with the 

sensor information, the sensor name was capitalized as “Finger Sensor.” When typing in 

an empty text field, the first word is automatically capitalized with the default iOS 

keyboard settings, but subsequent words are not (unless they follow a period and a 

space). Therefore, the capitalized second word in the sensor name was slightly 

problematic for users. Almost all participants asked whether the capitalization mattered, 

to which the researcher replied no, it is not case sensitive. Some participants struggled to 

capitalize the second word in the sensor name before asking about it, others asked 

immediately. For those that attempted capitalization, their difficulty was in finding the 

shift key on the onscreen keyboard. Participants also had minor difficulty finding the 

forward slash symbol while typing in the network address. This was not surprising given 

that text entry on touchscreen keyboards is notoriously problematic, both slow and errorprone. Text entry metrics are a popular research area in HCI; research that began with 

many years of transcription studies conducted with typewriters and desktop computers

has now moved into the mobile domain. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

46

Aside from the text entry itself, participants did not have difficulty mapping the 

information from the sensor placard into the appropriate fields in the sensor walkthrough. 

Only one participant did not enter a name for the finger sensor, but as previously 

mentioned, the network address is the only critical sensor information. All participants 

successfully entered the network addresses, which is extremely important, as without a 

valid network address, WSABI cannot communicate with and receive images from a 

sensor. 

Right slap setup

After configuring the first biometric (left slap), setting up any new biometrics 

required pressing the square plus button to bring up the sensor walkthrough. During the 

debriefing, one participant expressed that they weren’t initially sure about using “the edit 

button versus the plus mark to add, because sometimes you can add from within edit,” 

and that they were “trying to decide between new person, plus, and edit.” Despite initial 

uncertainty, the participant was able to complete the task, as were all other participants. 

Once in the sensor walkthrough, picking “Finger sensor” from the list of recent 

sensors meant that the associated information was autofilled, so participants did not have 

to retype the network address and sensor name during the right slap task. For the one 

participant who did not name the finger sensor during the preceding left slap task, the 

sensor appeared with its network address rather than name on the list of recent sensors. 

This participant noted in the debrief “I thought that when adding the sensor, you can find 

it by the name. I don’t think it picked it up, so it threw me off.” It seems likely that they 

were expecting entering the network address to automatically pull up the corresponding 

sensor name within the application. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

47

Face setup

One participant asked “Is this for the same person?” before starting the task. As 

with the right slap task, setting up the face biometric required pressing the square plus 

button to bring up the sensor walkthrough. A different participant tapped the new person 

button two times before trying the plus button. Across participants, there was some 

uncertainty regarding whether to select Face or 3D Face as the submodality during this 

task. When participants asked which to choose, the researcher explained that the sensor 

couldn’t take 3D images, at which point all participants correctly selected Face rather 

than 3D Face. As with the initial left slap task, adding the network address and name for 

the new sensor gave rise to the same text entry issues previously seen. 

Rearranging icons

Recall that in order to drag and drop icons, one must press-and-hold one until they 

are all in a moveable state (i.e., until they start wriggling). While markedly improved 

over the press-and-hold delay issues participants experienced when trying to rearrange 

workflow items in the original WSABI interface, the new delay was not completely 

without issue. All participants attempted the drag and drop appropriately; three 

participants did not initially press-and-hold long enough before attempting to move the 

face icon. As before, the researcher reassured them that they were doing it exactly right, 

and explained the required delay. With this explanation, they were able to successfully 

rearrange the icons. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

48

Guard template

Thumbs setup

The thumbs setup task was particularly interesting because there were multiple 

ways to accomplish it, either of which were correct. Participants could add the 

thumbprints to the existing record or create a new person record, and they could add a 

thumbs slap or add a left and right thumb instead.

Multiple participants were unsure whether to add the new thumb biometric to the 

existing person record (i.e., the basic employee template) or create a new record for the 

guard template. Before starting this task, one participant (the same participant who 

previously asked “Is this for the same person?” during face setup) asked “Can I add onto 

this one or do I have to do a totally new one?”, to which the researcher replied that either 

method was fine. A different participant hesitated over the New Person button, and 

during debriefing commented that “This isn’t a person, this is a template for all people, 

that’s why I didn’t click the new person button. I was trying to decide between new 

person, plus, and edit.” Despite this uncertainty over the New Person button, the same 

participant seemed pleased with its functionality, commenting that “When I added a new 

person during the template it was nice that it did everything for me.”

Note that the script merely said “[guards] also need thumbs recorded”, at which 

point the researcher would demonstrate a thumbs slap. Three participants extrapolated 

from the previously defined term “left slap” and its associated demonstration, and added 

a “thumbs slap” here; two of these explicitly asked whether they should select thumbs

slap upon seeing the submodality options. Rather than adding a thumbs slap, the 

remaining four participants added the left thumb, followed by the right thumb. Adding 

the two thumbs separately was equally as effective as adding a thumbs slap, albeit 

slightly less efficient, as stepping through the walkthrough a second time required five 

extra taps. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

49

Operator Tasks

Biographical information entry

All participants successfully completed the biographical information entry task, 

typing the first name Alice, and using the date and gender selector “wheels” to enter her 

DOB and gender (previous Fig. 27). In contrast to typing the network address and sensor 

name during the preceding manager tasks, participants did not have difficulty typing 

“Alice,” since it was auto-capitalized and did not require any special symbols. Participant 

strategy with the year selector wheel varied in terms of the magnitude of their 

scrolling/flicking gestures. Some participants made small, conservative scrolling gestures 

with the year selector wheel, only advancing it a few years at a time; others used larger 

scrolling gestures with a more aggressive “overshoot then correct” strategy. One 

participant commented that “The spinner is easier” [i.e., the biographical wheels are 

easier than typing], while another noted that they were “fun” to use. There were no issues 

with the gender selector wheel, although several participants seemed to find the 

“unknown” gender option rather humorous. 

Of particular interest were participant comments regarding saving the biographical 

information they just entered. There was actually no need to explicitly save any work. 

There was no “save” or “done” button in the biographical information popover; to 

dismiss the popover, simply tap anywhere outside it. Data is automatically saved as soon 

as it is entered (or captured). Based on Study 1 findings, information about saving was 

added to the script, i.e., “Don’t worry about saving your work; the iPad does that for you 

automatically.” However, participants still seemed concerned about saving, with several 

asking how to save during this task. Debriefing comments such as “Done button might be 

nice for the bio info.” further support these observations.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

50

Multi-modal capture

As in Study 1, all participants successfully performed the multi-modal biometric 

acquisition tasks. The common capture cards again worked well across modalities. As 

before, there were several participants who instructed the researcher (in the role of Alice) 

to place her hand on the sensor, and seemed to expect the image to automatically appear 

on the iPad. As before, when no image appeared, participants realized an action was 

necessary on their part, after which they correctly tapped the animated hand on the 

capture card. One participant commented that they were initially “confused as to who was 

supposed to touch it”, thinking the animated hand indicated an action was required by the 

presenter rather than the operator. In other words, they initially thought that the animated 

hand meant the presenter was supposed to place her hand upon the sensor. However, this 

did not prevent task completion, and the same participant commented that “Once I 

understood I was to touch it, it was easy.” 

During debriefs, there were several questions regarding the “Waiting for sensor” 

message. For example, one participant asked “Is it waiting saying now you should put 

your hand on it, or is it already reading?” and another asked “Does your hand have to be 

on it first and then press the button, or is it ok at the same time?”. Participant uncertainty 

regarding the readiness of the biometric device highlights the need for sensor 

affordances, as described in prior biometric usability work (Theofanos, Stanton, and 

Wolfson, 2008). While sensor interaction was out of scope for the current studies (NIST 

does not test products), real-world deployments of WS-BD systems should consider such 

issues. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

51

Retaking and annotating

As in Study 1, participants were successful at clearing, retaking, and annotating 

images. The pencil edit button again worked well, and with the simplified annotation 

options, participants were no longer uncertain whether to select “unprintable” versus 

“amputated”. The free-form notes field worked extremely well; all participants used it in 

some fashion (notes varied from simply “bandaid” to “Print could not be read properly”). 

In contrast to the notes field on the back of the capture card, participants did not use the 

free-form notes field in the biographical information popover. This may have been 

because it was at the bottom of the biographical information list and not visible without 

scrolling. Unfortunately, it was not possible for all biographical information to be 

simultaneously visible in the current interface, in order to accommodate the onscreen 

keyboard necessary for text entry. 

Deleting items and records

The modal Edit/Done button again posed difficulty, albeit for different reasons and 

to a much lesser degree than in Study 1. In Study 2, the editable state indicators were 

significantly more visually salient than they were in Study 1 (Fig. 33). Furthermore, a tap 

anywhere other than on a red X or blue Done button would automatically change the 

collection back into its default non-editable state in Study 2; in Study 1, a collection 

remained in an editable state unless the Done button was tapped. However, one cannot 

fully compare Edit modes across studies, since the type of deletion enabled during Edit 

mode differed. In Study 1, Edit only allowed deletion of an entire collection, whereas in 

Study 2, it allowed deletion of individual items within a collection. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

52

Figure 33. Edit/Done buttons and modal states for collection-deletion in Study 1 (top) 

versus item-deletion in Study 2 (bottom).

The delete-item and delete-record confirmations seemed superfluous and/or 

confusing to multiple participants. For example, one commented “the confusing part was 

the deleting, I had to push the delete button again to delete.” While it would certainly be 

possible to reduce the number of actions required to delete data, until an undo option is 

implemented, it seems more prudent to err on the side of caution where such destructive 

actions are concerned. 

Across manager and operator tasks

Saving

There were two separate saving issues: one in the biographical information popover 

(operator tasks), and one in the sensor walkthrough (manager tasks). 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

53

Two participants explicitly mentioned looking for a Done button on the biometric 

information popover. Participants searching for a “Done” button in the biographical 

information task is indicative of a general conceptual difference between desktop and 

mobile computing regarding “saving.” In the traditional desktop paradigm, users are 

frequently required (and prompted) to explicitly “save” their work. In the mobile 

computing paradigm, saving is more commonly implicit and handled automatically by 

the system. 

Almost the reverse issue occurred in the sensor walkthrough, where a tap on the 

Done button was required to save the sensor information and dismiss the walkthrough. In 

this case, the button was present and all participants clearly saw it. However, in two 

instances, a missed tap on the Done button resulted in dismissing the walkthrough 

prematurely; this is quite a severe error, as the sensor information just entered was 

dismissed as well. The issue arose due to small variations in human motor movement 

accuracy; the most significant issue with the sensor walkthrough was caused by one of 

the smallest buttons, the “Done” button on the final screen of the walkthrough. 

DISCUSSION AND CONCLUSIONS

The benefits of consistent procedures and interface elements cannot be 

overemphasized. We made numerous significant changes in the WSABI interface from 

Study 1 to Study 2, ranging from functional to merely aesthetic. Yet by keeping core 

features and affordances of the biometric capture cards consistent, novice participants 

were able to successfully complete multimodal capture in both studies, without training. 

In contrast, current software training can take four to six hours per device even for 

experienced operators (R. Bowlen, FBI, personal communication, November 30, 2012). 

The implications of our results are far-reaching. Consider the enormous amount of money 

and time currently spent on training and retraining operators to use different biometric 

devices. Consider the amount of money and time currently spent on updating biometric 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

54

device drivers and software, on addressing interoperability issues between devices and 

clients, on creating a custom “middleman” software solution, etc. Now imagine the 

savings that would be realized by capitalizing on the human cognitive and perceptualmotor benefits that accompany consistent procedures and interfaces. Although biometric 

sensors and mobile computing devices will continue to evolve, that should not 

necessarily require costly user retraining each time technology changes. 

Based on the results of our two small formative usability studies, this seems more 

than feasible. To support reduced user training requirements, there are several general 

guidelines we recommend following when designing touchscreen interfaces for 

multimodal biometric capture (below). While it seems obvious that general HCI 

principles should apply to biometric capture interfaces, it is worth emphasizing that while 

these may be ingrained principles for cognitive scientists and usability professionals, they 

are not necessarily so for software developers.

Design recommendations

• Design biometric acquisition software to be user- rather than sensor-centric. 

• Keep the core capture primitives constant. Taking, clearing, retaking, and 

annotating biometric data are core functions of the capture process; these basic capture 

tasks should require similar actions regardless of biometric modality or sensor.

• Be consistent. E.g., consistent buttons, consistent locations, consistent procedural 

steps, consistent language. 

• Leverage direct manipulation features of touchscreens. Have editing functions near 

the objects in question, e.g., the pencil edit button is on the image it will annotate. 

• Capitalize on affordances. For example, objects that look like buttons will encourage 

people to tap them (e.g., the breadcrumb bar buttons at the bottom of the capture 

cards)
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

55

• Use internationally tested, standardized symbols where possible (e.g., the small 

biometric modality icons)

• Use modal features sparingly and carefully (e.g., Edit/Done mode)

• Be aware of differences between desktop and mobile computing paradigms. Think 

carefully before adding features like Done/Save buttons simply to meet user desktop

expectations. While it may match their desktop paradigm, it is at odds with—and 

unnecessary for—the mobile computing paradigm. Therefore, adding it would add a 

superfluous step and make the task less efficient, especially when scaled up to 

numerous enrollments. Don't assume that what works well in a desktop application 

will necessarily work well on a mobile device without requiring modification (e.g., the 

workflow concept and button). Desktop versus mobile are two different computing 

paradigms.

• Provide useful, informative feedback to the user regarding system status, and 

provide human-readable error messages with recovery options (e.g., the “try again 

button” in sensor walkthrough, or the "waiting for sensor" message on a capture card). 

Furthermore, because error states are often fleeting and can be extremely difficult to 

reproduce, expect that there will be fringe cases that simply won't appear during 

usability testing. It is critical that software developers are knowledgeable about the 

requirements for user-friendly, meaningful system feedback. 

• Don’t assume that users will know features of the native operating system, even if 

they have experience with the device (e.g., the press-and-hold timing; the onscreen 

keyboard). 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

56

FUTURE DIRECTIONS

Both the WS-BD protocol and the WSABI reference implementation already 

support transfer of static images from any compliant sensor (i.e., any sensor that 

conforms to the WS-BD specification). Recent work on both now allows video 

streaming. Adding such live preview functionality is highly beneficial, enabling operators 

to see images before actually capturing them, which is more analogous to the alreadyfamiliar process of taking a picture with a digital camera or smartphone. Additional 

recent work has also incorporated new passport reader technology, so that using a sensor 

to scan a driver’s license or passport automatically transfers appropriate information to 

the client device. These newer features and functionality should undergo formal usability 

testing as well.

As previously mentioned, WS-BD is device and operating-system agnostic. 

Conceptually, WSABI should be as well. To fully test this, it should be implemented on 

additional platforms, such as Android tablets. It should also be implemented on smaller 

devices, such as smartphones and blackberries. To do this will require some redesign, 

such as making better use of screen real estate by reducing the empty spaces between 

icons and buttons, or by making use of disclosure triangles to show/hide information. 

Such redesign should not require retraining users if WSABI’s common capture primitives 

are implemented consistently, but this must be verified experimentally via formal 

usability testing. If WSABI’s existing conceptual model ports well across mobile device 

sizes, then we will have truly achieved a flexible, extensible, consistently designed 

reference implementation that exercises all relevant features of the WS-BD specification. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

57

We intentionally designed WSABI for, and tested with, novice users. This was 

appropriate given our goal of exercising the WS-BD protocol; since WS-BD only deals 

with communication between clients and sensors, we did not implement functionality to 

support certain real-world operator tasks that come before or after biometric capture. For 

example, WSABI does not have built-in support for submission (i.e., an automated 

process for sending images in standard format to query a fingerprint database). 

Researchers and institutions who wish to use the WSABI reference implementation as a 

starting point for larger, real-world biometric systems will need to extend and customize 

our open-source software for their specific needs. Most likely this would include 

addressing issues such as submission and scalability. For example, WSABI is not 

particularly efficient for large numbers of records in its current implementation; too much 

scrolling would be required. To address scaling issues, one might implement various 

searching and sorting functions; with such additional functionality, a user could sort by 

name, by date, by age, etc., or search for a specific record. 

Future WSABI extensions should add new functionality designed for advanced 

users. For new pre-capture functionality, one could add import capabilities that would 

allow an operator to import a database of biographical information for a number of new 

employees simultaneously. Combine this with a script that automates new record creation 

and pulls from the imported database to auto-populate the biographical information fields 

of numerous new records simultaneously. Then during enrollment, an operator would 

only have to complete the biometric capture(s) rather than performing any template setup 

or biographical entry tasks. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

58

Mobile text entry is notoriously slow and error-prone, so entering complete 

biographical information would be agonizingly tedious with an onscreen keyboard. The 

smaller the client device, the more problematic touchscreen-based text entry becomes. To 

at least save users the difficulty of capitalizing the first letter of each word in a text field, 

future work should utilize the iOS option to title case words automatically. For instances 

where heavy text entry may be still be required, a full (physical) QWERTY keyboard 

could be made available to operators; most popular tablets support connected and 

wireless keyboards. As an alternative, the feasibility of implementing dictation 

capabilities to capture voice notes should be investigated; most smartphones already have 

native recording applications, some of which automatically reduce ambient noise. 

Additional advanced features might include making a list of all previously used 

sensors available simultaneously. In the current WSABI implementation, only sensors 

relevant for the currently selected biometric modality are shown, but expert users may 

want to view all sensors regardless of which modality/modalities they support. For 

experienced users, the fingerprint icon should not be angled as it was in Study 2. It should 

be reverted back to its original, non-tilted orientation, as expert users may be bothered by 

the fact that the angled orientation is at odds with the ISO standard on international 

biometric symbols. The annotation options may also need to revert to their original form, 

which enabled users to mark individual fingers as unprintable versus amputated; for 

expert users, supporting the Electronic Biometric Transmission Specification (EBTS)

may be important. 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

59

Regardless of any such minor modifications to WSABI, the critical capture 

primitives should remain roughly unchanged in future work. Using capture cards, 

biometric icons, and annotation features consistently means that WSABI will always be 

poised for new modalities, such as ear and vein. Not only should WSABI undergo formal 

usability testing for new modalities, but also for newer iOS versions. For example, 

buttons in iOS 7 do not appear nearly as “button-like” as they do in iOS 6, which may 

negatively impact some of the affordances we worked so hard to create in our current 

WSABI implementation. Future work on such issues would benefit both our specific 

biometrics research as well as the larger HCI community. Finally, HCI researchers may 

wish to explore other gestures and determine which are universal across touchscreens and 

which are idiosyncratic to a particular device/platform.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

60

ACKNOWLEDGEMENTS

This research was sponsored by the National Institute of Standards and 

Technology (NIST), the Federal Bureau of Investigation (FBI), and the Department of 

Homeland Security (DHS), as part of the Biometric Web Services (BWS) project 

(http://bws.nist.gov). The authors gratefully acknowledge NIST BWS project team

members Kevin Mangold and Karen Marshall, especially for Karen’s thoughtful review; 

Matthew Aronoff, a previous member of the NIST BWS team; Benjamin Long of NIST’s 

Software and Systems Division for his thoughtful review; and all the participants who 

graciously donated their time to further this research.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

61

REFERENCES

Apple. (2014). iOS Human Interface Guidelines. Retrieved from 

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptua

l/MobileHIG/Introduction/Introduction.html. 

Apple. (2013). About Events in iOS. Retrieved from 

https://developer.apple.com/library/ios/DOCUMENTATION/EventHandling/Conc

eptual/EventHandlingiPhoneOS/Introduction/Introduction.html

Aronoff, M., & Micheals, R. J. The Biometric Client Configuration Language. National 

Institute of Standards and Technology Interagency Report (NIST IR) 7531. 

Retrieved from http://www.nist.gov/customcf/get_pdf.cfm?pub_id=33208

Dediu, H. (2012). Apple sold more iOS devices in 2011 than all the Macs it sold in 28 

years. Retrieved from http://www.asymco.com/2012/02/16/ios-devices-in-2011-

vs-macs-sold-it-in-28-years/.

Greene, K. K., & Tamborello, F. P. (2013). Initial ACT-R Extensions for User Modeling 

in the Mobile Touchscreen Domain. Proceedings of the 12th International 

Conference on Cognitive Modeling. Carleton University, Ottawa, Canada.

Greene, K. K., Tamborello, F. P., & Micheals, R. J. (2013). Computational Cognitive 

Modeling of Touch and Gesture on Mobile Multitouch Devices: Applications and 

Challenges for Existing Theory. Proceedings of the 15th International Conference 

on Human-Computer Interaction. Las Vegas, NV.

Micheals, R. J., Mangold, K., Aronoff, M., Kwong, K., & Marshall, K. Specification for 

WS-Biometric Devices (WS-BD) Version 1. National Institute of Standards and 

Technology (NIST) Special Publication 500-288.

Micheals, R. J., Stanton, B., Theofanos M., & Orandi, S. (2006). A Taxonomy of 

Definitions for Usability Studies in Biometrics. National Institute of Standards 

and Technology Interagency Report (NIST IR) 7378. 

National Science and Technology Council Subcommittee on Biometrics. (2006). National 

Biometric Challenge. Retrieved from 

http://www.biometrics.gov/Documents/biochallengedoc.pdf.

Orandi, S., & McCabe, R. M. (2009). Mobile ID Device Best Practice Recommendation. 

National Institute of Standards and Technology (NIST) Special Publication 500-

280. Retrieved from http://www.nist.gov/itl/iad/ig/upload/MobileID-BPRS20090825-V100.pdf.

Theofanos, M., Stanton, B., & Wolfson, C. A. (2008). Usability and Biometrics. Ensuring 

Successful Biometric Systems. National Institute of Standards and Technology 

Interagency Report (NIST IR). Retrieved from 

http://zing.ncsl.nist.gov/biousa/docs/Usability_and_Biometrics_final2.pdf.
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

62

APPENDICES

Appendix 1, Informed Consent Form 
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

63

Appendix 2, Demographic Questionnaire
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

64

Appendix 3, Exit Survey
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

65

Appendix 4, Study 1 Script, Operator Tasks First
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

66
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

67
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

68
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

69
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

70

Appendix 5, Study 1 Script, Manager Tasks First
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

71
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

72
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

73
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

74

Appendix 6, Study 2 Script
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.IR.8003

75