a touch screen interface for point-of-sale … touch screen interface for point-of-sale applications...

A Touch Screen Interface for Point-Of-Sale Applications

in Retail Stores

Master’s Thesis in Computing Science, 20 credits

Samuel Sjöberg [email protected]

Abstract

iii

Abstract

This thesis describes the development of a touch screen prototype for a Point-Of-Sale (POS) application. POS is a demanding environment that re-quires the interface to be responsive, accurate and easy to use. This, in com-bination with the special needs that arise from touch screen interaction, makes it a prime candidate for design driven by findings in human-computer interaction.

A theoretic walkthrough of touch screen specific problems was conducted to clarify why a touch screen Graphical User Interface (GUI) requires special attention. Touch screen problem areas include handedness, finger resolution and lack of tactile feedback. The theoretical findings are made more concrete with a set of 14 guidelines for designing touch screen GUIs. The guidelines are specifically made for POS applications where the users are experts.

The guidelines were used to design the touch screen prototype that was based on an existing Java POS application and therefore fully functional. The concrete guidelines answer the question of how to design a touch screen GUI. Results from informal evaluations of the prototype imply that the guidelines have been useful and that the recommendations they provide are valid.

Keywords

Touch screen, Point-Of-Sale, interaction design, human-computer interac-tion.

Preface

v

Preface

When I first came to Extenda, the subject of my thesis and the goal of the project were unspecified. The only thing both parts knew, was that I should do something that would be a challenge for me and useful to Extenda.

I had initially contacted Extenda with a proposal to improve their POS sys-tem, which I had been using as a cashier for several years. They liked my idea, but thought I would be more useful in some other project. The question was which one.

After an initial meeting, we decided that I should work on a touch screen prototype that was due to be presented before the end of the year. This, being a big challenge, made me feel both excited and a bit worried about the high expectations. Due to some unfortunate events I also became the only person involved in the project.

Now, four months later, I have crossed the finish line. When the project started, I never thought it would be possible to finish in time, but here I am, writing this preface with the prototype running on a touch screen monitor a few meters away.

Stockholm, December 2005

Table of Contents

vii

Table of Contents

1. Introduction ......................................................................... 9 1.1. Touch Screen Technology...............................................................................9 1.2. POS Terminology...............................................................................................9 1.3. A Usage Scenario .............................................................................................11 1.4. Thesis Outline ..................................................................................................12

2. Goal and Method .............................................................. 13 2.1. Project Requirements......................................................................................13 2.2. Iterative Design Method ................................................................................14

2.2.1. Prototype Evaluation...............................................................................14 2.3. Resources ...........................................................................................................15

3. Characteristics of Touch Screen Interfaces ..................... 16 3.1. Why Use a Touch Screen?.............................................................................16 3.2. Design Considerations ...................................................................................17

3.2.1. Target Size .................................................................................................18 3.2.2. Pointing Strategy......................................................................................19 3.2.3. Software Keyboard Layout .....................................................................20 3.2.4. Viewing Angle and Operation Angle ..................................................22 3.2.5. Scrolling Strategy .....................................................................................23 3.2.6. Hand and Arm Movement ....................................................................24 3.2.7. Obstruction of Screen Real Estate .......................................................25 3.2.8. Feedback......................................................................................................26

4. Guidelines for a Touch Screen POS Interface.................. 28

5. Design of the Prototype User Interface ............................ 32 5.1. Existing GUI .....................................................................................................32

5.1.1. Main Features ...........................................................................................32 5.2. Basic Design Ideas............................................................................................32

5.2.1. Use of Colors.............................................................................................34 5.3. Low-Fidelity Prototypes ..................................................................................34

5.3.1. Paper Prototype ........................................................................................35 5.3.2. Interactive Flash Prototype....................................................................36

5.4. Implemented Java GUI ...................................................................................36

6. System Description........................................................... 40 6.1. Component Framework..................................................................................40

6.1.1. Applications...............................................................................................40 6.1.2. Modules ......................................................................................................42 6.1.3. Components ..............................................................................................42

6.2. Configuration ...................................................................................................43

Samuel Sjöberg

viii

6.3. Touch Screen Components .......................................................................... 44 6.3.1. Event Dispatching................................................................................... 46 6.3.2. Floating Icon Implementation .............................................................. 47 6.3.3. Framework Limitations.......................................................................... 48

7. Evaluation..........................................................................49 7.1. Paper Prototype................................................................................................ 49 7.2. Interactive Prototype ...................................................................................... 49 7.3. Touch Screen GUI .......................................................................................... 50

8. Discussion .........................................................................52 8.1. Impact of Enterprise POS.............................................................................. 52

8.1.1. Optimization of the Prototype.............................................................. 53 8.2. Evaluation of Guidelines................................................................................ 53 8.3. Future Work..................................................................................................... 54

Acknowledgements...............................................................55

References ............................................................................56

Chapter 1. Introduction

9

Chapter 1.

Introduction

Extenda delivers Point-Of-Sale (POS) solutions to companies such as ICA, Axfood, H&M and Stadium. A POS application is used to register sales and handle bank transactions. The application must perform in real-time to meet the demands of both cashiers (in need of a responsive system) and customers (demanding fast and accurate service).

Touch screens are becoming more common in POS solutions and Extenda is therefore developing a touch screen interface for their POS application. An early prototype, made before this project began, was based on the already ex-isting keyboard-based interface and not completely redesigned for the touch screen. The touch screen interface will eventually be a part of Extenda’s stan-dard POS and will be designed for retail and grocery stores.

This project was formed to help Extenda create a touch screen interface based on research and theories in human-computer interaction. With knowl-edge of touch screen interaction, unnecessary design mistakes can be avoided. This will help making the product more competitive on the market.

1.1. Touch Screen Technology

Touch screens are direct-pointing devices that let the user interact directly with the objects displayed on the screen. This differs from the indirect-pointing offered by a mouse or trackball (Shneiderman and Plaisant, 2005). A direct-pointing device eliminates the need to map a physical manipulation into a virtual representation of the same manipulation. It is possible to act directly on the subject (e.g., a virtual button), without the need of a pointing device to mediate the action. This simplifies interaction and lets the user in-teract in an intuitive way with the system.

There are mainly four types of touch screen sensor technologies in use to-day: resistive, surface wave, capacitive and infrared. An in-depth description of the technologies is out of this thesis’ scope, but a comparison of their characteristics is found in table 1.1.

1.2. POS Terminology

This section describes some POS specific terms and concepts that are used throughout the thesis.

A transaction is a list of items that the cashier has registered. To clarify in which state the transaction is, the term ongoing transaction is sometimes used. A transaction that is finished and paid for is finalized.

Samuel Sjöberg

10

Resistive Surface

Wave Capacitive Infrared

Input flexibility

Excellent Gloves, pens and credit cards.

Good Gloves.

Poor Only finger touch.

Excellent Gloves, pens and credit cards.

Calibration stability

Good Excellent Poor Excellent

Transparency Good 87,5% transpar-ency

Excellent Only one layer of extra glass

Excellent One layer of conductively coated glass.

Excellent No extra layers.

Environmental tolerance

Excellent Poor Affected by dirt, noise and mois-ture.

Poor Will not operate in moisture and high humidity.

Excellent

Durability Good 3+ million touches

Excellent Good Excellent

Table 1.1. A comparison of four common touch screen sensor technologies (Elo Touch Systems, 2005c; Protouch Manufacturing Ltd., 2004).

Order is a term that is used in some cases that also referrers to the transac-tion. One can think of an order as a finished (i.e., all items are registered), but unpaid transaction. A restaurant is an example of where this procedure seems natural. An order is first placed, then served and finally paid for.

A receipt is the physical, printed paper-copy of the finalized transaction. It usually lists all the bought items, how they were paid for and the different taxes.

Another term for deleting a registered item from the transaction is to void the item. This term is used because the item is not sold and charged for, but remains visible in the transaction.

A Price Look-Up (PLU) list is used to look up the price of an item that has no barcode, for example fruits and vegetables. Usually, the cashier has memorized the major part of the list, but it is still an essential part of the ap-plication. An alternative to incorporating the PLU list into the POS applica-tion is to have a regular file index that the cashier consults.

A pending items list contains registered items, for example vouchers, that need some requirement to be fulfilled before they are permanently added to the transaction.

A tender type is some kind of payment. There exists a multitude of possible tender types, for example cash, credit cards, vouchers and bank checks.

Chapter 1. Introduction

11

1.3. A Usage Scenario

To make it easier to understand the context in which a POS application is used, the following scenario was created. It takes place in a checkout lane in a grocery store.

It is Friday afternoon and Maria has 15 minutes left on her two-hour shift in the store’s checkout. The lines keep growing longer and the customers are frustrated because they want to get home quickly to start enjoying their weekend.

Maria says “hi” to the next customer, a man in the mid-forties, and starts to register the groceries he has already unpacked. She can hear the scanner register each of the 6 milk packages she shuffles through the checkout. As she scans the next item, she also looks at the transaction on the screen to make sure that all six milk packages were registered. A closer look tells her that only five milks were registered, but she can fix this easy by selecting the entry with the milk and multiply it by six instead of five.

Maria is keeping a high pace and must wait for the scale to stabilize after she has entered the Price Look-Up (PLU) number for cucumber. The customer has now unpacked all his groceries and picks up his credit card. When he swipes it in the card terminal, it will not register and Maria, still moving gro-ceries through the checkout, gives a helping hand. Because Maria is occu-pied with helping the customer, she fails to notice a dialog box that appears on the screen, telling her that the scanned item could not be found. The only feedback Maria perceives is the reassuring “beep” that the scanner make each time it encounters a barcode.

After a few more groceries have passed by, Maria looks at the screen and no-tices the dialog box. “When did this happen?” is Maria’s first thought. After the confusion has settled, she investigates the ongoing transaction to find the last registered item. Then, she needs to collect the items that were not registered and scan them again.

When all the groceries have been registered, the customer asks for 50 SEK extra to be charged to his credit card. Maria does so and the customer accepts the amount and, in the stressed state he is in, completely forgets to wait for the money. Maria, already greeting the next customer, also forgets to give him the money, but remembers to tear of the printed receipt and place it among the groceries.

As the previous customer is about to leave, he looks at his receipt and realizes that he did not get his change. He walks up to Maria and asks for it. Maria, suddenly remembering the 50 SEK, apologizes sincerely and gives him the money. Luckily, the customer did not get upset.

There is nothing extra-ordinary happening in this scenario. Everything that is described is part of the everyday tasks of a grocery store cashier. Stressed customers that want to be served quickly in combination with long shifts and divided attention makes it hard to concentrate on the screen. A good POS application supports the cashier by reducing possible mistakes and does not rely on full attention to be operable.

Samuel Sjöberg

12

1.4. Thesis Outline

The structure of the thesis is a reflection of the order in which the project was executed. The design of the prototype was based on a theoretical study conducted before any of the prototypes were developed.

First, the goal and method of the project is described. Then, a theoretical background on touch screen characteristics is given in chapter 3. The char-acteristics are then used to form design guidelines in the following chapter. The guidelines were used when developing the prototypes.

Chapter 5 describes the design of the current interface, as well as the devel-oped prototypes. The following chapter gives a technical description of the underlying POS system and the implemented Java prototype.

Chapter 7 is dedicated to the evaluation of the prototypes and describes the outcome of the informal evaluation sessions. Finally, chapter 8 is a discus-sion of the outcome of the project. An evaluation of the usefulness of the guidelines together with a comment on future work is given.

Chapter 2. Goal and Method

13

Chapter 2.

Goal and Method

The goal of the project was to investigate how a touch screen POS application used in a retail store should be designed for best performance and usability. To accomplish this, a prototype based on theories on touch screen interac-tion was developed. Central questions in the project were:

• What problems arise from the use of touch screens? • How can the design of the Graphical User Interface (GUI) reduce the

impact of these problems?

To identify possible problems, a theoretical study was conducted. The find-ings from the study were then used to establish a set of guidelines for touch screen POS applications. These guidelines were later applied when the GUI was designed.

2.1. Project Requirements

The final prototype was to be built upon Extenda’s current Java POS system (also referred to as Enterprise POS). This limited the possibility to reinvent parts of the interaction, but this was ignored during the early design phase.

Extenda’s POS platform requires each component of the interface to be highly configurable. Configuration is done with Extensible Markup Lan-guage (XML) and includes for example paths to images, the graphical layout of the GUI and the structure of menu items.

Another requirement was that the prototype must be easy to learn. One of Extenda’s main selling arguments is the small amount of time needed to train a cashier1. A touch screen POS will occasionally be used by users that already are familiar with Extenda’s keyboard solution (e.g., in a customer service desk at a supermarket). Ideally, no training would therefore be re-quired.

A final requirement was that the solution should be hardware independent. This means that the system cannot be designed for a specific screen size, re-quire arm wrist support, or demand cutting edge hardware. However, rec-ommendations on suitable hardware and supporting tools can be given as long as they are not required.

1 The average training time at H&M is for example 28 minutes (Peder Lindencrona, per-sonal conversation).

Samuel Sjöberg

14

Figure 2.1. An iterative design process. Adapted from Preece, Rogers and Sharp (2002).

2.2. Iterative Design Method

The prototype was developed with an iterative design method. Figure 2.1 shows a simple model of an iterative design process. Requirements and needs are first gathered. Then a design is created and often implemented into some kind of prototype. The prototype is then evaluated and the results can be used either to gather more requirements or to alter the design (Preece, Rogers and Sharp, 2002).

Figure 2.1 is a simplification of the design process. The process is not or-dered and the states in the figure can relate to each other in more ways. It is for example possible to evaluate a design without making a prototype or de-cide to gather requirements based on findings in the design state.

Löwgren and Stolterman (2004) emphasize that a designer starts to design as soon as the assignment is presented. Even if the designer begins to gather requirements a design has already started to take form in the back of the head. This is a good example of the non-linearity of the design process. No matter how structured the process is, the designer will still move between different states without any clear boundaries.

2.2.1. Prototype Evaluation

The prototypes were evaluated in informal sessions where the subjects tested the prototype and talked about how they perceived it. The subjects were en-couraged to suggest alternative solutions and to criticize solutions they found bad.

In addition to talking with the subjects about the prototypes, some behavior was observed without commenting. In some situations, subjects might think they are using a control correctly, but in fact they are not. These situations are especially interesting because it indicates that the task is designed poorly.

Chapter 2. Goal and Method

15

The evaluation focused on the touch screen GUI and not on the parts of the interaction that was inherited from the Enterprise POS.

2.3. Resources

All computer graphics were made with Photoshop CS and Illustrator CS. The flash-based prototype (see section 5.3.2) was developed with an evalua-tion copy of Flash 82.

Sim Daltonism3 is a free color-blindness simulator that was used to deter-mine appropriate colors and how they should be used in the GUI.

The Java prototype was developed with Java 1.4.2_08 Standard Edition using the Eclipse SDK4 with the following plug-ins installed:

• P4Eclipse - Adds support for team repository with Perforce5. http://sourceforge.net/projects/p4eclipse/

• Quantum DB - Adds a SQL editor and shows tables and data in a tree view. http://sourceforge.net/projects/quantum/

• XmlBuddy - XML editor and DTD validation. http://www.xmlbuddy.com/

The prototype was tested on an IBM SurePOS 700 running a Linux distribu-tion. It had a 2.4 GHz processor and 512 MB RAM. It featured a 15” flat LCD monitor with an infrared touch screen running in 800 × 600 pixels resolu-tion.

2 http://www.macromedia.com/flash8/ 3 http://www.michelf.com/projects/sim-daltonism/ 4 http://www.eclipse.org/ 5 http://www.perforce.com/

Samuel Sjöberg

16

Chapter 3.

Characteristics of Touch Screen Interfaces

In this chapter, design considerations related to touch screen GUI design are discussed. Based on these considerations, guidelines for touch screen POS interfaces will be formulated. But first, an important question needs to be addressed: Why should a touch screen be used?

3.1. Why Use a Touch Screen?

Touch screens are traditionally used in public, harsh environments (e.g., air-ports, train stations and shopping malls) and users are usually novices. Touch screens are therefore designed to be straightforward to use and diffi-cult to misuse (i.e., to misunderstand). A wizard-like interface (see figure 3.1), where the user is guided through the interactive process is the standard solution6. The reason touch screen technology is used in this kind of de-manding environments is its intuitive interaction form (see section 1.1 re-garding direct manipulation) and the durability of the hardware.

Figure 3.1. A simple example of a wizard interface. When users choose to make a room reservation, they are guided through the process. Each state includes only one action that needs to be fulfilled before going to the next state.

6 Examples of wizard-like solutions are: SJ’s ticket sales kiosk, SAS’ self-service check in and Arlanda Express’ ticket sales kiosk.

Chapter 3. Characteristics of Touch Screen Interfaces

17

Pros Cons

Durable. No moving parts that can break of be misplaced.

No tactile feedback. The result is a higher demand on visual attention.

Easy to maintain. The system consists of a computer and a touch screen.

Risk of arm fatigue. More hand movement than with indirect-pointing solutions.

Straightforward interaction. A point and click interface.

Pointing biases and improper work posi-tions can reduce pointing accuracy.

Table 3.1. A listing of the pros and cons of touch screen technology.

The efficiency of touch screens has been investigated in numerous experi-ments (Hall et al., 1988; Sears, 1991; Sears and Shneiderman, 1991) and they have proven to be faster than a regular mouse in selection tasks (Sears and Shneiderman, 1991). However, the direct interaction offered by touch screens comes with one big limitation: the lack of tactile feedback.

The durability of touch screens makes them suitable for demanding envi-ronments. If something breaks, there are fewer parts to examine than with a keyboard and mouse solution, where the keyboard and mouse can break in addition to the computer and the monitor. This makes maintenance easy and affordable. Because the screen is the only input device, touch screens occupy less workspace than, for example, a keyboard solution.

POS systems are typically used in busy, dirty environments with demand on quick, accurate operation (both from customers and management). A touch screen is suitable in this sense, because it is easy to maintain and occupies less workspace. The lack of tactile feedback could become a problem, but if feedback is given in other modalities it might be manageable. The expert user base allows for more advanced solutions than the previously mentioned wiz-ards, but also introduces problems with ergonomics. Improper mountings of touch screens, or badly designed interfaces with respect to hand movement, can make arm fatigue a major problem.

In table 3.1, pros and cons for touch screens are listed. If enough effort can be put into designing the interface so that the pros outweighs the cons, a touch screen solution might be applicable.

3.2. Design Considerations

The interaction form offered by touch screens introduces new challenges to the designer. This section presents eight areas worth giving special attention during the design process. One of the objectives with this section is to show that a desktop computer GUI cannot be directly ported into a touch screen GUI. The other objective is to give a survey of areas worth considering and then, in chapter 4, use them to formulate guidelines for a specific touch screen use case: a POS application.

Samuel Sjöberg

18

Figure 3.2. Shifting of active button area as proposed by Sears (1991).

3.2.1. Target Size

A major difference between touch screen GUIs and indirect-control GUIs is the limitations introduced by physical constraints. With an indirect pointing device, such as a mouse, precision pointing (e.g., selecting a 1-pixel target) impose no problem, but the resolution of our fingertips, or even the sharp-est stylus, compared to the digital mouse pointer makes this task an issue with direct-control pointing. Andersson and Zhai state that “the human fin-ger as a pointing device has very low ‘resolution’. It is difficult to point at tar-gets that are smaller than the finger width” (Andersson and Zhai, 2003, p. 105).

In addition to the low resolution of our fingertips, biases are introduced that makes it even harder to point at small targets. These biases are “consistent differences between the location users want to touch, and where they actually touch” (Sears, 1991, p. 253). Biases vary depending on the users location rela-tive to the screen and have been identified for both the vertical and the hori-zontal axis (Hall et al., 1988; Sears, 1991).

Vindras et al. (1998) showed in an experiment that “errors in pointing movements reflect biased estimations of the hand starting position” (Vindras et al., 1998, p. 3290). If the user’s attention is not directed at the pointing ac-tion, this bias could be a contributing factor to pointing errors.

The low resolution of the fingertips in combination with biases introduced by parallax (due to the space between the touch screen and the display), re-sults in 99.2% accuracy for targets with the size 26 mm. If targets are re-duced to 20 mm, an accuracy of 95.6% is recorded (Hall et al., 1988).

Sears (1991) attempts to reduce the target size by shifting the active area to a point that corresponds to the estimated error introduced by biases (see figure 3.2). As a result of the shift, Sears could reduce targets from 26.1 mm to 22.7 mm and keep the mean error rate below 1%.

Since the time when the referred experiments (Hall et al., 1988; Potter, Weldon and Shneiderman, 1988; Sears, 1991; Sears and Shneiderman, 1991) were performed, the technical situation has improved dramatically. Today, touch screens have higher resolution, allowing for more accurate capture of input. For example, the touch screen used by Sears (1991) had a touch reso-lution of 1024 x 1024 pixels, compared to current touch technology that of-


19

fers 4096 x 4096 pixels resolution (Elo Touch Systems, 2005a; Troll Systems, 2004). Further enhancement of precision can be made with flat LCD moni-tors. They reduce the effect of parallax that was introduced by the curved glass of CRT monitors (Hall et al., 1988).

3.2.2. Pointing Strategy

Related to target size is the touch screen pointing strategy. Just as there are different ways of triggering events with a mouse (e.g., click, hover or drag) there are different techniques for triggering a “touch”. Depending on the need for precision or speed, and desired manipulation techniques, different strategies are available.

Potter, Weldon and Shneiderman (1988) presented three different pointing strategies, allowing for different kind of precision. Land-on is the simplest strategy that simply registers the initial touch. First-contact refines land-on by allowing the user to drag its finger onto a target, meaning that the landing point can be moved if the target is missed. The final strategy, take-off, uses a cursor placed above the finger and registers the position where the finger is lifted from the screen. Their hypothesis was that it would be easier to hit tar-gets by dragging a cursor placed slightly above the finger, than by simply “touching” it. The results of the study showed significantly better results with take-off than with other strategies. It also showed that land-on was the fastest, but most error-prone strategy.

A disadvantage with take-off is the introduction of the cursor that displaces the touched position and the targeted position. This leads to a reduction of the directness in the interaction, resulting in longer selection times (Potter, Weldon and Shneiderman, 1988). In Elo Touch Systems’ (2005b) guidelines for touch screen interfaces it is explicitly stated that the cursor should be hidden to make the user focus on the whole screen and not the cursor. This implies that the direct interaction form is the motivation for using touch screens, thus disqualifying take-off as a useful strategy.

Albinsson and Zhai (2003) present advanced techniques for fine-tuning an initial touch to select 1-pixel targets on maps. Their work is a good example of techniques to provide high precision on touch screen displays. However, high-precision techniques lead to longer selection time (Albinsson and Zhai, 2003; Potter, Weldon and Shneiderman, 1988).

Another aspect worth considering when choosing pointing strategy is what kind of manipulation that is possible. In Touchscreens Now Offering Compel-ling Uses, Shneiderman (1991) demonstrates how dragging of widgets (e.g., scrolling with scrollbars) can be achieved with a lift-off strategy. Lift-off regis-ters when the user lifts the finger from the screen and is similar, or identical, to take-off.

Samuel Sjöberg

20

Figure 3.3. Two examples of soft keyboards in touch screen applications. To the left is a photo of SAS’ stand-by check-in at Arlanda, where a full name is entered on the Qwerty keyboard. To the right is a touch screen scale for vegetables at ICA Maxi Umeå. To find a vegetable or fruit the first letter in the name should be typed. The scale features a variant of an ABC keyboard layout.

3.2.3. Software Keyboard Layout

Many touch systems require some kind of text input from its users. Because no physical keyboard is available, alternative solutions are necessary. One is to use character recognition, as available for stylus-controlled PDAs. An-other solution is to display some kind of keyboard on the screen (see figure 3.3). This is referred to as using a “soft keyboard” (Mackenzie, Zhang and Soukoreff, 1999).

Mackenzie, Zhang and Soukoreff (1999) compared different soft keyboards (see figure 3.4) to determine the most efficient layout. Their study consists of a theoretical prediction of text entry speed for numerous layouts and a user study to verify the calculated values. Figure 3.5 summarizes parts of their findings. Note that the Qwerty layout scores much better for novice users than predicted. The authors explain this as a consequence of users not being novices to the standardized Qwerty layout. The telephone layout, with disambiguation enabled, offers an interesting alternative to traditional full-blown layouts, especially in a POS application where alphanumeric input could be useful.

Sears (1991) compared a soft keyboard Qwerty layout with a standard key-board and mouse. The devices scored 25.4, 58.2 and 17.1 words per minute (WPM) respectively. A standard keyboard, where both hands can be used, is evidently faster than its touch screen counterpart. The mouse was slowest and Sears concludes that this probably had to do with the indirectness of the device.


21

Figure 3.4. Examples of different keyboard layouts. a) the ABC keyboard layout. b) the Qwerty layout. c) The telephone layout used by Mackenzie, Zhang and Soukoreff (1999). d) The more common distribution of characters on the telephone layout (Pavlovych and Stuerlinger, 2004). In c), the zero-key is used to disambiguate the input.

Figure 3.5. A comparison between three keyboard layouts regarding their efficiency. An interpretation of the results is that 1) all layouts are equally bad for beginners and 2) The predicted efficiency for experts is more or less equal. The result of the quick user test is skewed due to users being non-novices to the standard Qwerty layout. This suggests that Qwerty is a good design choice for situations where users must get started fast and easy. Adapted from Mackenzie, Zhang and Soukoreff (1999).

Samuel Sjöberg

22

With a new model for text entry speeds on cellular phones, Pavolovych and Stuerlinger (2004) predicts that a novice enters 7.58 WPM with a disam-biguation function. This is close to the results found and predicted for nov-ices by Mackenzie, Zhang and Soukoreff (1999). Pavlovych and Stuerlinger also recalculate predictions made with older models for comparison with their model and estimations of expert speed varies between 24.97 and 40.6 WPM (for details, see; Pavlovych and Stuerlinger, 2004).

When choosing the layout of a soft keyboard, available screen area, expected input length (a few characters or full sentences) and user experience are con-siderable factors. If users are novices and a Qwerty keyboard can be fitted onto the screen, it should allow for easy usage. If users are experts or will use the system frequently, they will learn to use the keyboard layout, thus screen area and efficiency are more important. For example, Mackenzie, Zhang and Soukoreff (1999) predict that the telephone layout is marginally faster than Qwerty when the users are experts.

3.2.4. Viewing Angle and Operation Angle

To minimize problems with parallax, touch biases and arm fatigue, the view-ing angle and operation angle of the touch screen is important to incorporate into the design of the touch screen application.

Touch biases introduce errors when users are not standing directly perpen-dicular to the screen. Depending on whether the user is left-, or right-handed, pointing accuracy may even vary between users (Hall et al., 1988). In the same way, users’ height affects the accuracy of touch and also the pre-ferred viewing angle with regards to neck and eye fatigue (Shultz, Batten and Sluchak, 1998).

Figure 3.6. Relation between screen angle and table. Shultz, Batten and Sluchak (1998) found that the interval 30° and 55° covers most users’ preferences. The screen in the figure is adjusted to 45°.


23

User studies have been made to determine appropriate screen adjustment and Sears (1991) found that 30° was the preferred screen angle for sitting subjects. Shultz, Batten and Sluchak (1998) studied standing subjects at a POS desk and found that most subjects adjusted the screen to be between 30° and 55° (see figure 3.6). “While 92% of the subjects adjusted the display to an angle between 30° and 55°, almost half (46%) adjust it between 44° and 49°” (Shultz, Batten and Sluchak, 1998, p. 347).

Shultz, Batten and Sluchak (1998) emphasize the need for adjustable touch screens when they are used in POS. Monitors are often mounted to a fixed-sized desk at a fixed distance from the edge of the desk. Users of different height must be able to adjust the screen to a comfortable viewing angle to reduce arm and eye fatigue as well as reflections on the screen.

3.2.5. Scrolling Strategy

The need to scroll is a consequence of the limited screen real estate that is available on today’s displays. Different display techniques might eliminate, or fundamentally change the way scrolling is performed. For example, the “pads” presented by Weiser (1991) could serve as digital papers with shared infor-mation, allowing them to be spread over the desktop just like papers, reduc-ing the need to scroll.

To make scrolling more efficient, innovations such as the scroll wheel and the touchpad scroll zone are used. By removing the need to locate the scrollbar and interact directly with it, or the buttons associated with it, scroll-ing is reduced to a single finger movement.

The need to scroll exists also on touch screens. Because no peripherals, such as a mouse or keyboard, are available, touch-controlled scrolling is the only solution. Dragging a scrollbar is not suitable for touch screens because it re-quires precision and could impose a problem with hands obscuring the screen. Touching a button to move the content up or down is another possi-ble solution. However, this solution is inefficient, requiring repetitive touches on the screen.

There are very few experiments examining scrolling on touch screen dis-plays. Johnson (1995) examines horizontal panning of a virtual room, but never address vertical scrolling. Shneiderman (1991) mentions dragging as a possible manipulation on touch screen, but never address scrolling.

Johnson (1995) found that subjects preferred to drag the background in the panning direction, thus if users wanted the scene to shift left, they swiped their hand in the left direction. This is the opposite of panning the view, which is used on desktop computers. If users think of the scrolling action as commanding their head to move (or pushing the camera), Johnson’s results are the natural response, but if the users believe they grab the background and then drag it, the traditional approach is correct. Unfortunately Johnson

Samuel Sjöberg

24

only tested panning in the horizontal plane and only with a realistic 3D image of a living room as the object to pan. His findings might not be valid for ver-tical text since the convention to move the viewable area is ubiquitous in computer applications.

Wherry (2003) compared the performance of a touchpad scroll zone, a touchpad scroll ring and a mouse scroll wheel (see figure 3.7). The results showed that “the touchpad scroll ring significantly outperforms the touch-pad scroll zone and mouse scroll wheel … [and] though the scroll ring’s cir-cular mapping caused some initial confusion, subjects quickly learned the circular mapping” (Wherry, 2003, p. 759). The users favored the scroll ring over the other devices, because it offered the ability to scroll with one con-tinuous movement and allowed for quick and accurate operation.

Both the touchpad scroll zone and the touchpad scroll ring could be imple-mented on a touch screen. The scroll ring is an interesting alternative to ver-tical scrolling since it has proven efficient (Wherry, 2003) and requires very little hand-movement.

Touching the background to move it with direct manipulation is an appeal-ing solution, but as Johnson (1995) points out, there could be a problem with the hand obstructing the screen.

3.2.6. Hand and Arm Movement

To make the touch screen GUI efficient to use, unnecessary hand movement should be avoided. Unnecessary hand movement results in two things: in-creased response time and obstruction of screen real estate. Obstruction of screen real estate is covered in the next section. Here, ideas on how to limit movement will be presented.

To avoid unnecessary hand movement, controls that are used in combina-tion can be grouped. Fitts’ law (for an overview, see; Mackenzie, 1992) is one tool that can be used to determine an efficient layout of components.

Figure 3.7. Two solutions to ease scrolling when a mouse is not used. To the left is a touch-pad with two scroll zones found on Dell Computers’ XPS M170 laptops. To the right, a touch sensitive scroll ring found on Apple Computers’ iPod.


25

Kabbash, Buxton and Sellen (1994) investigated how two-handed input af-fected the task completion time when using a mouse and a trackball. They found that two-handed input reduced task completion time with two out of three interaction techniques. Their conclusion was that using two-hands to overlap operations does not necessarily increase efficiency. It depends on the nature of the task. If the operations performed by each hand are too unre-lated, the cognitive load will increase, which in turn affects the completion time. However, one benefit with two-handed interaction is that hand move-ment can be reduced, because hands can be independently centered at the designated task.

In addition to interface usability, hand movement also affects the workstation ergonomic. Ergonomics is, however, out of this thesis’ scope. In the area of POS, workplace conditions can seldom be controlled (discussed also in; Shultz, Batten and Sluchak, 1998). Different suppliers can, for example de-liver the counters, chairs, lights and computer hardware. To minimize the GUI’s impact on physical work conditions, movement can be designed to be non-monotonic and to avoid unnecessary repetitive steps.

3.2.7. Obstruction of Screen Real Estate

With the hand as a pointing device, the fact that the hand partly covers the display must be considered. The important thing is to realize this and design an interface that can be partly obscured and still mediate what is critical.

There is no solution to the problem with obstruction other than designing for it. Many of the areas presented in this section deals with this problem, either by trying to reduce hand-movement, thus the possibility to obstruct the screen, or by trying to minimize the consequences of screen obstruction. For example, both scrolling strategy and button positions affect how much hand-movement is needed. By carefully designing how much screen area that needs to be crossed to reach one function from another, obstruction can be reduced.

Figure 3.8. Handedness is important to consider. In this example, the left-handed user cannot see the numbers as they are typed because handedness was not incorporated into the design. A right-handed user has no problem to see what is on the screen.

Samuel Sjöberg

26

Designing for handedness can also lessen obstruction (e.g., personalization of keyboard layout; Himberg et al., 2003). A keyboard should for example be positioned to the right if the user is right-handed and to the left if the person is left-handed (see figure 3.8).

3.2.8. Feedback

A problem with touch screens is the lack of tactile feedback. When using a physical keyboard, physical feedback is provided. Users can feel and hear when a button is pressed. They can also feel where the fingers are positioned with help of the physical form of the keys. These mechanical and tactile cues are all missing on a touch screen. To know that a button is pressed, the user is dependent on software-triggered feedback.

To interact with the world, we need to know what is possible to do and what has been done. Norman (1988) refers to the problem of knowing this as the “gulf of execution” and the “gulf of evaluation”. The gulf of execution is the gap between the user’s intentions and the allowable actions of the system. It must be clear what is possible and not. The gulf of evaluation is the gap be-tween the perceived system state and the actual state. The user must clearly be able to understand the consequences of an operation. Thus, the gulf of evaluation can be bridged with instant feedback.

A touch screen relies on vision and sound as feedback channels. A short-coming of touch screens is therefore the increased demand of visual atten-tion, compared to using a physical keyboard. In a comment on the project weblog7, Anders Markstedt pointed out that the demand on visual attention could be a significant drawback when users are experts. When users are ex-perts and tasks become automated, a substantial amount of visual attention will still be required to operate the system. A possible, positive spin-off effect is that increased visual attention from the users of a POS application could result in less erroneous item registrations (e.g., a cucumber being registered as a carrot).

The use of sound can help reduce the need of visual attention. Different sounds, for different functions, could replace the need for a visual confirma-tion for some tasks. Sound should also be used to warn the user in critical situations, where it is not sufficient to rely on the visual attention of the user. In a POS application, this could, for example be necessary when a scanned item is not found in the database.

Obstruction of the screen should also be considered when designing feed-back. A small button being pressed might be partly or fully covered by the

7 Permanent link to Anders’ comment: http://thesis.samuelsjoberg.com/archive/2005/09/areas-worth-paying-attention-to#c4


27

hand. In that case, it is appropriate to give feedback in an additional location (besides on the pressed button), showing, for example the generated input.

Samuel Sjöberg

28

Chapter 4.

Guidelines for a Touch Screen POS Interface

A POS application differs from many other touch screen applications because its users are experts. In addition to this is the well-defined context of use. These factors make POS a special case in the touch screen GUI family and motivate the need for guidelines.

The areas from chapter 3 will serve as a foundation for the guidelines that will be presented here. The guidelines are formed with a touch screen POS interface in mind, but can also be applied on other touch screen systems where the users are experts.

1. Keep targets at reasonable size. Depending on the type of target, the size might vary, but targets smaller than a fingertip requires precision, which affects the input speed. When a miss causes a sequencing error, the size should be expanded. This applies to the numeric keypad, where a miss results in a different interpretation of the input (e.g., 4011 turning into 411). If the consequence of a miss is restricted to the erroneous action (i.e., the effect is to try again), smaller targets might be applicable. However, keep in mind that smaller targets affect efficiency and that frequent misses are annoying.

2. Use an intuitive pointing strategy. If the target is a keyboard, it is natu-ral to response to a press action (referred to as on-land in; Potter, Weldon and Shneiderman, 1988). However, a release response might be more appro-priate for the rest of the system. Use a strategy that seems natural and at the same time best suited for the task. Do not mix strategies more than neces-sary. A strategy based on release is preferred because it allows for slight ad-justment of the touch on a near miss.

3. Use one event type for each target. Do not mix event types to make the interface richer. If a button is both touchable and movable, the low precision of the finger in combination with divided attention from a stressed user might invoke the wrong (i.e., the unintended) action. At the same time, do not resort to click-only interfaces. Utilize the full potential of the touch screen, but when designing for example scrolling, make sure it is obvious how to use the function and that the user’s actions will not be misinter-preted.

4. Design for handedness. To avoid screen obstruction and arm fatigue the interface should allow operations with both left and right hand. This means that a system designed for right-handedness should be mirrored when a left-handed user logs on.

Chapter 4. Guidelines for a Touch Screen POS Interface

29

5. Use bimanual input with caution. Do not design the interface to be effi-cient only with two hands. Personal preferences, or working conditions, might make it hard to utilize both hands. If two hands are used, make sure they are not in they way of each other and that the two tasks are related.

6. Use an economic keyboard layout. An economic keyboard layout is a layout chosen with respect to its users’ experience, the expected input length and the screen space it occupies. Do not use a Qwerty layout just because it is standard. Qwerty loses efficiency when users must resort to single-tap. When users are experts, the keyboard layout is learnt. It is therefore better to choose the keyboard depending on available screen space and expected input length. The telephone layout is an attractive alternative that scores well when compared to Qwerty (Mackenzie, Zhang and Soukoreff, 1999; Pavlovych and Stuerzlinger, 2004). Its usage in text messaging (SMS) also results in famili-arity among users. However, when users are experts, the choice of layout is arbitrary, since it will be learnt. Choose an economic layout that is efficient, occupies no more space than necessary and reduces visual scanning and hand movement.

7. Match users’ expectations when scrolling. Johnson’s (1995) experi-ment shows that scrolling can be expected to work differently on a touch screen, depending on the task and the user’s mental model of the system. Make scrolling intuitive and at the same time efficient. Ultimately, scrolling should be performed with one continuous movement, similar to dragging an object in real-life. Also make sure that the user can scroll the view without obstructing the content with the hands. Make sure scrolling works for both left and right-handed users.

8. Provide feedback in multiple locations. Do not solely rely on a 3D-effect that makes the button appear pressed. The button is partly obstructed by the finger, reducing the effect. In addition to button-effects, provide feed-back of what is fed into the system. If the user enters numbers, show the numbers in a way that cannot be missed, in a place most likely not blocked by the hand.

9. Provide feedback for all modalities. The lack of tactile feedback raises the need for visual attention. To reduce the immediate need for visual atten-tion, use sound as a complement. Our attention is easier divided between dif-ferent modalities than between, for example two visual stimuli (Wickens and Holland, 2000). Whenever something critical happens, when the user must make an active choice, use all available modalities. To flash the whole screen is a drastic, yet efficient way to gain visual attention (compared to a plain dia-log box) and sound can attract the attention when the user is looking in an-other direction. Sound can however drown in the background noise of the environment.

Samuel Sjöberg

30

Figure 4.1. Information should be displayed where the user is likely to have its attention. This is a screenshot of the Enterprise POS standard GUI. The large ellipse contains the dynamic information that constantly changes while the small ellipse contains informa-tion about what to do. The information messages are easy to miss because they are located in an area that is not in focus.

10. Show information where attention is directed. Display information, especially critical one, where the user’s attention already is directed (see figure 4.1). If most dynamic information is located in the lower half of the screen, non-critical feedback should appear in this area. Otherwise, it is a big chance it will not be noticed.

11. Hide what can be hidden. Show what must be shown. Functions that are used frequently must be quick to access. However, a danger is to reveal too much. On a touch screen, this results in clutter that does not only slow down performance, but also makes it hard to keep the targets large enough. Do not base the layout of the system on the physical predecessor (see figure 4.2). Instead, utilize the dynamics that the computer system offers to make frequently used functions easy to access while hiding unused functions.

12. Use custom widgets. To free the users mind, make the touch screen look different from traditional desktop GUIs. Make users think of the touch screen as an interactive “machine”. If the GUI looks like Microsoft Windows, people expect it to behave the same. Make it obvious that the GUI is designed for a different interaction technique. Run the application in full screen and remove the cursor (Elo Touch Systems, 2005b).

Chapter 4. Guidelines for a Touch Screen POS Interface

31

Figure 4.2. An example of a cluttered interface, likely to be based upon the physical prede-cessor. This particular POS is designed for restaurants and is called Q-Touch (available online; http://www.kassan.nu).

13. Use an adjustable screen. POS applications must run on a wide variety of hardware and it is therefore hard to make the GUI ergonomic. If a touch screen GUI is introduced in a store, it will probably result in an investment in new displays. If so, make an effort to persuade the buyer of the POS sys-tem to use displays that can be adjusted between at least 30° and 55° (for de-tails, see; Shultz, Batten and Sluchak, 1998).

14. Do not underestimate the users. The users are experts so they demand an efficient, flexible system. A touch screen kiosk can limit the users’ possi-bilities because they are novice users. Multiple paths and shortcuts, as used in desktop operating systems, should be available for the experts. The de-mand for fast, accurate response is important, as well as how the system re-covers from errors, both intentional and unintentional. Novices blame themselves for making errors, but experts will blame the system.

Samuel Sjöberg

32

Chapter 5.

Design of the Prototype User Interface

This chapter describes how the design of the prototype evolved. First, an overview of the current GUI is given together with a brief description of its main features. Then, the ideas that laid the foundation for the final GUI will we presented together with a description of two low-fidelity prototypes and the implemented GUI. The evaluation of the prototypes is presented in chapter 8.

5.1. Existing GUI

The standard GUI of the Enterprise POS (depicted to the left in figure 5.1) is a semi-touch interface. The colored buttons to the right can be used either with a keyboard or a touch screen. If a keyboard is used, it usually has a cor-responding row of colored buttons (without labels) that are used to access the menu. It is only the menu panel that responds to touch in the interface.

There existed an old touch screen prototype (the right screenshot in figure 5.1), developed in spring 2005, but it was never completed and not opera-tional when the project started.

5.1.1. Main Features

The main purpose of a POS application is to register items for sale in a trans-action that can be stored. To accomplish this, a rich set of functions exists. It must for example be possible to remove a registered item and accept a wide variety of tender types (e.g., cash, credit card or vouchers).

Functions can roughly be divided into three categories; those who affect the current transaction; those who sometimes affect the transaction and those who do not. This division of functions is available in table 5.1. The listed functions are part of Extenda’s Enterprise POS standard GUI. Many of the functions are used in the scenario in section 1.3.

5.2. Basic Design Ideas

The design of the interface was driven by the special demands of a touch screen interface and much attention was given to the following problems:

• The direction of visual attention when entering items and acting on dialogs.

Chapter 5. Design of the Prototype User Interface

33

Figure 5.1. To the left is the Enterprise POS standard GUI. To the right is a graphical sketch of Extenda’s first touch screen prototype.

Affects Current Transaction

Function Always Some-times Never

Accept multiple tender types √

Cancel the order √

Change price of registered items √

Delete a registered item √

Direct-access registration of frequent items √

Error messages √

Handle refunds for returned item √

Hardware communication √

Log in and log off √

Price inquiry √

Price Look-Up (PLU) √

Register multiple items at once √

Retrieve a suspended order √

Search the order for an already registered item √

Suspend the order for later √

Training mode √

Validation of customer’s age √

Table 5.1. Essential functions in the Enterprise POS standard GUI.

Samuel Sjöberg

34

• The wish to have functions directly accessible without causing infor-mation overflow due to massive clutter.

• The size and position of interactive components (e.g. buttons) as a mean to reduce errors and hand movement.

• The wish to preserve Extenda’s GUI identity and workflow. Ideally, a user should be able to switch between a keyboard and a touch screen interface without the need for additional learning.

In an attempt to avoid clutter and save screen real estate, sliding panels were introduced. A sliding panel is a movable container that can hold for example buttons or a Price Look-Up (PLU) list. In addition to reducing clutter, slid-ing panels introduce smooth, animated changes between states. This is one of the laws of Visual Momentum, which states that smooth transitions should be used when changing representations, or in this case states (Wick-ens and Hollands, 2000).

The main functionality was first divided into three sliding panels based on the functionality analysis in table 5.1. The panels were later to be reorganized, and finally removed from the prototype.

The panels were removed from the final prototype for three reasons: limited scalability, problems with consistency and restrictions in Extenda’s Java framework that caused flicker. The lack of scalability and interface consis-tency became apparent in the project when additional functionality (e.g. mes-saging) needed to be added. The question of where to put new functions and the problem with scrolling being limited to one panel only, made strong ar-guments against a menu separated in different sliding panels.

5.2.1. Use of Colors

A characteristic trade of Extenda’s POS applications is the color-coded, dy-namic menu used to access for example the PLU list. The color-coding makes it possible to apply several context-sensitive functions to the same key. Colors are used in a similar way in the touch screen GUI in an attempt to preserve Extenda’s identity. Even though no dynamic keys are present, a user that is familiar with the keyboard solution would know where to look for a given function because the same color codes are used at the menu top level.

Color-blindness is a factor that needs to be counted for when choosing col-ors. The colors in the Enterprise POS are distributed so that colors that look similar for a color-blind person are separated by a contrasting color.

5.3. Low-Fidelity Prototypes

During the project, several prototypes and interface sketches were produced. These low-fidelity prototypes were used to verify ideas without putting too much effort into making the prototype.


35

Figure 5.2. The paper prototype that was used to determine the size of buttons, position of feedback and the organization and location of the sliding panels.

A low-fidelity prototype is a very simple prototype that is not designed to look like the final product. Low-fidelity prototypes are useful because they are cheap and quick to build. Because they are cheap to build, many prototypes can be developed throughout the iterations of the design cycle. The often in-formal look-and-feel of the prototype also makes users more aware of how the prototype functions and not how it looks (Preece, Rogers and Sharp, 2002).

The developed low-fidelity prototypes were based on the guidelines in chapter 4 and will here be presented in short.

5.3.1. Paper Prototype

A paper prototype, based on the concept of sliding panels, was made early in the project (see figure 5.2). The purpose of developing a paper prototype was to establish the size of components (e.g., buttons or panels) and to find how users preferred to organize different functions.

The components in the prototype could be moved and existed in multiple sizes and shapes to allow the subjects to change its appearance. The size of the prototype was proportional to the Enterprise POS standard GUI when running on a 10” display.

Samuel Sjöberg

36

Figure 5.3. Sliding panels were used in the prototype in an attempt to reduce clutter and utilize that different parts of the screen could be hidden in different state of a transaction. This corresponds to guideline 11.

5.3.2. Interactive Flash Prototype

The flash prototype was an interactive low-fidelity prototype. It was, just like the paper prototype, built with sliding panels. Figure 5.3 shows how clutter is reduced with the previously mentioned sliding panels. The panels were al-lowed to cover the transaction as long as the functions did not affect the transaction directly.

The prototype was implemented with an evaluation copy of Flash 8 and ran in 800 × 600 pixels resolution, which is the same as the Enterprise POS stan-dard GUI. Many of the features in the flash prototype were implemented in the final prototype and will be explained in the following section.

5.4. Implemented Java GUI

A fully functional Java prototype was implemented on top of Extenda’s En-terprise POS system. This section gives an overview of the prototype’s func-tionality and describes how the GUI relates to the guidelines in chapter 4.

Figure 5.4 is a screenshot of the touch screen GUI. The moving panels from the flash prototype were removed in favor of menus more similar to Ex-tenda’s default menu structure. Menus were still allowed to cover the trans-action and so was the PLU list (see figure 5.5). Functions that act directly on the transaction or are used frequently are always visible. To show and hide components depending on the state of the application is recommended in guideline 11.

Screen corners and edges are utilized to make buttons easier to hit. When buttons are placed at the edge of the screen, the button grows infinitely large outside the screen. Fitts’ law (see e.g.; Mackenzie, 1992) tells us that an infi-nitely large target will be easier to hit and takes less time to reach. This is re-lated to guideline 1.

Dialogs are displayed on top of the transaction (see figure 5.6). This is a very dynamic part of the screen where the user is likely to look often. This con-


37

forms to guideline number 10. The dialog also dims the screen to appear more clearly and to affect the screen globally. The large change in illumina-tion could help the user notice the dialog even when attention is not directed directly on the screen.

Dialogs that used to display items in a list are converted into a larger dialog that displays the choices as a grid of buttons instead (see figure 5.7). This eliminates the need to scroll in dialogs.

Figure 5.7 also displays the alphabetic keyboard that shows when alphanu-meric input is supported. The use of a Qwerty keyboard is motivated by res-ervations against alternative keyboard layouts among Extenda’s customers. The recommendations in guideline 6 were therefore not followed.

Direct manipulation of the transaction was enforced with buttons that con-nected to the selected row (see figure 5.8). The buttons in the prototype allow the user to delete the row or change the price of the item.

The rows in the transaction and the PLU list can be selected by touching the row. To scroll the view, users can either use the scrollbar or hold their finger on the last, or first visible row. This activates automatic scrolling that stops when the user moves the finger again.

The transaction also featured an item count notification (see figure 5.8). It is used in an attempt to reduce erroneous registrations of multiple items. This type of error is one of the most commonly encountered and costs money both for the stores (that compensate the customer) and for the customers (that do not notice the error).

Figure 5.4. The touch screen GUI with an ongoing transaction. To the right is the Enter-prise POS standard GUI in a corresponding state.

Samuel Sjöberg

38

Figure 5.5. The PLU list covers the ongoing transaction. If the state of the transaction is changed (e.g., by adding an item) it is immediately displayed again.

Figure 5.6. Dialogs dim the screen to attract attention.

Figure 5.7. The new appearance of dialogs. Multi-choice dialogs are converted from lists to a grid of buttons and when alphanumeric input is used, an alphabetic keyboard appears.


39

Figure 5.8. A detailed screenshot of the transaction in the touch screen GUI.

Samuel Sjöberg

40

Chapter 6.

System Description

Extenda’s Enterprise POS system is built to be modular, flexible and config-urable. At the heart of the system is a component server that assembles and boots the components requested by the starting application.

This chapter gives an overview of how the system is organized and how the touch screen prototype was incorporated into it.

6.1. Component Framework

The description of the component framework is based on Extenda’s Core Developer Guide (Extenda AB, 2004).

The building blocks of an application are components. Figure 6.1 explains how the component server launches components based on an application de-scription. The components are stored in modules and booted as either in-stances or templates. Instances and templates have a context that allows them to refer to other components and to load configuration values. In addition to components, there also exist exported Java classes that can be used outside the module they reside in.

It is important to understand that the component server has no notion of an application. It only cares about components and their relations. An applica-tion exists only in the mind of the developer. This makes it possible to add or replace components in the “standard application” by changing its application description. This also means it is possible to define exactly which compo-nents to use in an application.

Applications, modules and components will now be explained in more detail with examples of how they together form an application.

6.1.1. Applications

An application is defined in an XML file. It determines which modules to load, configuration files to include and components to boot. For flexibility, the application definition can be contained in several files that can be reused when new applications are defined.

Components can be booted in two ways, as templates or instances. A template is a component factory that can create new instances of the component on demand. An instance is a unique instance of a component (Singleton). Each booted component (templates or instances) has a unique name that is used when specifying relationships.

Chapter 6. System Description

41

Figure 6.1. UML diagram of the component framework. Adapted from Extenda’s Core De-veloper Guide (Extenda AB, 2004).

Components can refer to each other either as template references or instance references. All components that are referenced must have been created be-fore they are referred.

Example 6.1 is a simple application description that loads a module and boots four components with different type of references. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE application PUBLIC "" "http://www.extenda.com/dtd/application.dtd"> <application> <modules> <module location=”./subsystems/example/example.jar”/> <module location=”./subsystems/base/posbase.jar”/> </modules> <includes> <include location=”./sybsystems/config/baseconfig.xml”/> <include location=”./subsystems/config/example.xml”/> </includes> <boot> <template name=”CComponent” component=”CComponent”/> <instance name=”Session” component=”Session”/> <template name=”BComponent” component=”BComponent”> <instance-ref name=”Session” instance=”Session”/> <template-ref name=”CFactory” template=”CComponent”/> </template>

Example 6.1. An application description example.

Samuel Sjöberg

42

<extend-instance name=”UIBuilder” component=”UIBuilder”> <component-map name=”GUIComponents”> <component-ref name=”bComponent” template=”BComponent”/> </component-map> </extend-instance> </boot> </application>

Example 6.1 (continued).

6.1.2. Modules

A module is a collection of components and exported Java classes. Modules can be either stand-alone or depend on other modules. A module is typically contained in a Java Archive (JAR) that contains the Java classes and an XML description of the module. The path to the description inside the JAR file should always be /META-INF/module.xml. The description defines the Ap-plication Programming Interface (API) of the module (i.e., the components and exported classes). Example 6.2 shows an excerpt of a module description. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE module PUBLIC "" "http://www.extenda.com/dtd/module.dtd"> <module name=”example” version=”1.0”> <description>This is an example...</description> <exports> <export type=”se.extenda.example.AImpl”/> ... </exports> <component name=”BComponent” code=”se.extenda.example.BImpl”> <instance-ref name=”Session” type=”se.extenda.base.Session”/> <component-ref name=”CFactory” type=”se.extenda.example.C”/> <config name=”/Example/MaxCount” type=”Integer”> <description>Max number of C:s to create.</description> </config> </component> ... </module>

Example 6.2. A module description example.

6.1.3. Components

Components are Java classes. To be a component, a Java class must realize the Component interface in example 6.3. It is only classes that need to be re-placeable or configurable that should be components. If this is not needed, a regular Java class can be used. If it needs to be visible outside the module, it should be exported. public interface Component { void setComponentContext(ComponentContext context); void create() throws ApplicationException; }

Example 6.3. The Component interface that all components must realize.


43

References, defined in the component description (see example 6.2), are ac-cessed through the component’s context that is created by the component server. Example 6.4 shows an implementation of the component named BComponent. The example illustrates how instances and templates are loaded. It also demonstrates how a configuration point is accessed and used to affect the behavior of the component.

To make it easy to replace a component, it is important to use interfaces. In this way, a replacement component can realize the same interface, but add more functionality as well. public class BImpl extends AbstractUIComponent implements B { private static ArrayList list = new ArrayList(); private Session session; private ComponentFactory cFactory; private int maxCount; public void create() throws ApplicationException { session = (Session) getComponentContext().getInstance(“Session”); cFactory = getComponentContext().getComponentFactory(“cFactory”); maxCount = getConfiguration().getInt(“/Example/MaxCount”); } public void makeC() { if (list.size() < maxCount) { C c = (C) cFactory.newInstance(); list.add(c); } } ... }

Example 6.4. An example illustrating how the component context is used to create in-stances of other components.

6.2. Configuration

The configuration is based on an XML structure. If a component should use a configuration point, it is added to the description of the component in its module’s XML file (see example 6.2).

The configuration can handle both standard Java objects (e.g., String, Boo-lean, Integer or URL) and more advanced, custom objects (e.g., menu structures or keyboard layout definitions). If a custom object is used it must be assigned a ValueCodec, responsible for coding and decoding the object. The ValueCodec uses a Simple API for XML (SAX) parser to map the XML structure to an object and vice versa.

Examples of configuration points are fonts in the menus, the size of the screen, whether to support clicking or not and even the layout of the whole GUI. Example 6.5 shows a short configuration file.

Samuel Sjöberg

44

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE config PUBLIC "" "http://www.extenda.com/dtd/config.dtd"> <config version="@version@"> <group name=”Configuration”> <group name=”Example”> <value name=”MaxCount” type=”Integer” modifier=”default”> 20 </value> </group> </group> </config>

Example 6.5. A configuration file example.

6.3. Touch Screen Components

The components developed for the touch screen prototype were added to the standardgui module that holds the standard GUI components. The addi-tional classes were mainly contained in separate packages, but some changes were also made to existing classes (e.g., the active receipt that represents the ongoing transaction). Among the changes that are available also without touch screen are:

• The new, more sophisticated event dispatching that allows mouse tracking.

• A bug fix that solved a problem with the event dispatching when a dialog was touched and received focus.

• The appearance of the ongoing transaction now supports: floating icons, inverted text color, minimum row height, strikethrough on de-leted rows and quantity notification.

The prototype was developed in Java SE 1.4.2_8 and is a Swing GUI. It runs in 800 × 600 pixels resolution, which is the same as the Enterprise POS stan-dard GUI.

The components that are booted in addition to the standard Enterprise POS components are depicted in figure 6.2. The extra components are required to add touch screen capacity to existing components. Some of the most impor-tant components will be described in short. Key concepts are also described in detail in the following sections.

The AlphabeticKeyboardComponent is the alphabetic soft keyboard (see Figure 5.7, p. 38). It is displayed by the TouchSwingPrompter, which is an implementation of touchable dialogs, when alphabetic input is allowed. The keyboard layout is defined in the configuration and since it is a custom XML structure, a KeyboardValueCodec is used to convert it into an array of keyboard rows. The XML structure makes the layout highly configurable, making it possible to change the number of rows in the keyboard and the or-der of buttons as well as their labels and key codes.


45

Figure 6.2. An overview of the components that are added to the standard POS application by the touch screen prototype. The most important relations (solid lines) and underlying classes are also displayed.

The TouchSwingPrompter replaces the default dialog handler and adds buttons to the dialogs. Multi-choice dialogs, where the user previously se-lected items from a list, now uses a grid of buttons. This eliminates the need for a scrollbar.

The BreakApartCommandComponent alters the functionality of the menu (the colored buttons to the right in figure 5.1, p. 33). The menu is divided into two components, the root (in BreakApartCommandComponent) and the submenu (in SubMenuComponent). The two menus are synchronized with the MenuMediator. The different MenuRenderers that are used by the components is the view (i.e., the graphical appearance) in the Model-

Samuel Sjöberg

46

View-Controllers (MVC) pattern (for more information on MVC patterns and Swing, see e.g.; Wigglesworth and McMillan, 2004).

The TouchPLUComponent adds touch sensitivity to the items in the PLU list (depicted in figure 5.5, p. 38). It supports scrolling both with the scrollbars and by holding the finger on the last or first visible item. The TouchPendingItemsComponent is essentially the same component, but with a different model and controller.

The ScrollButtonComponent implements the scrollbar that controls the transaction, the PLU list and the pending items. Users drag their finger on the scrollbar to control the scroll speed. Thus, the scrollbar utilizes dragging and not touch to control its behavior.

6.3.1. Event Dispatching

Key and mouse events are not dispatched directly from the Swing event thread to the components in the GUI. Instead, a transparent glass pane is laid on top of the GUI to forward events to the components. This solution is necessary because it must be possible to map key events from one key to an-other event. For example, a POS keyboard’s escape button might be inappro-priately placed and therefore remapped to another key event (e.g., backspace).

The existing mouse mapping was limited to only registering press events. This meant that as soon as the user placed the finger on the screen, the event fired. If the target was missed, the user had to lift the finger and try again. This is analog to a land-on strategy, which is error-prone but fast (Potter, Weldon and Schneiderman, 1988).

Figure 6.3. Events are dispatched to the GUI components by a glass pane that controls all input. This allows keys to be dynamically mapped to different actions. Mouse events are dispatched to the first component that is found at the selected coordinate.


47

function mousePressed(mouseEvent) : component := getComponentFor(mouseEvent) location := getLocationOf(mouseEvent) if component != null : if component realize TouchableSwingComponent : component.handlePress(location) listeners.add(component) else if component realize ClickableSwingComponent : component.handleClick(location) end function mouseReleased(mouseEvent) : component := getComponentFor(mouseEvent) location := getLocationOf(mouseEvent) if component != null : if component realize TouchableSwingComponent : component.handleRelease(location) listeners.remove(component) notifyListeners(location) end function mouseDrag(mouseEvent) : component := getComponentFor(mouseEvent) location := getLocationOf(mouseEvent) if component = null : notifyListeners(location) return if component realize TouchableSwingComponent : if listeners contains component : notifyListeners(location) listeners.add(component) else if listeners.last() = component : component.handleDrag(location) end function notifyListeners(location) : for each component in listeners : component.handleDragOut(location) listeners := {} end

Figure 6.4. The algorithm that is used to dispatch mouse events to GUI components.

A new glass pane was developed to allow for better feedback and more elabo-rate touch control. It enabled components to register press, release and drag events. Components also became aware of when the mouse entered or exited while being dragged. Figure 6.3 shows how the new mapping is backwards compatible with the old and figure 6.4 describes the algorithm that is used to trigger events. Backwards compatibility is achieved by checking which inter-face that is implemented. If the component only can handle the click event it becomes unaware of the extra functionality.

6.3.2. Floating Icon Implementation

Figure 6.5 shows how the positions and visibility of the buttons that connect to the select row are updated via a mediator. The OffscreenActiveRe-ceipt is the representation of the ongoing transaction.

Samuel Sjöberg

48

Each time an item is added, or a new row is selected in the transaction, the new coordinates of the icons are passed to the mediator, which in turn for-wards the information to the icons. A mediator is needed because templates cannot be shared by multiple components and all GUI components must be templates. The mediator is therefore a component instance that lets Float-ingIconListeners register as listeners and OffscreenActiveReceipt to trigger changes in the model.

6.3.3. Framework Limitations

The GUI is implemented as a prototype and this means that some shortcuts have been taken to be able to prove a concept and in some cases, even finish before deadline.

The GUI builder in the component framework introduced limited possibili-ties to move components on screen. The GUI builder stores the initial layout of the interface and repaints it whenever needed. A component that has been moved will therefore flicker between its new, updated position and the origi-nal location. This also limits the possibility to mirror the interface at runtime to compensate for handedness.

To implement touchable dialogs, the underlying framework had to be up-dated. This was done during the project to allow replacing the standard dia-logs with a touchable version. Because the base classes were in the locked framework, the touch screen dialogs contain redundant code that compen-sates for private methods that had to be accessed in the new components. The redundancy can be reduced in the future, especially if the dialogs should have more advanced functionality to, for example highlight the default action in a context sensitive way.

Figure 6.5. The floating icons are realized by using a mediator to pass the coordinates of the selected row in the transaction to the floating icon component(s).

Chapter 7. Evaluation

49

Chapter 7.

Evaluation

The results of the prototype evaluations will be presented in this chapter. The prototypes were evaluated in a quick-and-dirty fashion to get a fast re-sponse due to the limited time frame of the project.

7.1. Paper Prototype

The paper prototype (shown in figure 5.2, p. 35) consisted of three numeric keyboards. Two of different size and one that was mirrored and had the enter button to the left. The two upper-right panels were made in two different versions, allowing the users to switch their locations. The location of feed-back and a dialog box was also adjustable in an attempt to determine where feedback should be located.

Two male and two female subjects, in the age of 17 to 24, tested the proto-type. One subject had experience as a supermarket cashier.

All subjects agreed that the larger button set should be used and that the en-ter button should be positioned to the right, in the screen corner. Three out of four wanted the feedback to be positioned above the numeric keyboard. The subjects felt that it was easier for the eyes to gaze above the keyboard than to the side.

The reaction to the panels differed among all subjects, but all agreed that ten-der types (the rightmost panel in figure 5.2, p. 35) should not be on the side. One subject proposed that the tender type panel could be moved below the numeric keys.

A result of the evaluation was that the panels needed to be rearranged. One subject suggested that the tender type panel (that differs in functionality compared to the other two) should have a different look.

Another suggestion given during the tests was that functions that only are available when a row in the transaction is selected should be directly con-nected to that row.

7.2. Interactive Prototype

The interactive flash prototype was available online and tested by six subjects, three male and three female. All three female participants had previous expe-rience with a POS application from Extenda.

Samuel Sjöberg

50

Figure 7.1. The direct-access buttons, on the edge of the PLU panel, was noted to intro-duce ambiguity when seen together with the PLU index.

To begin with, the PLU panel was noted to have problems with ambiguity. The buttons on the edge of the panel, that was intended to function as di-rect-access buttons to the most frequent PLU categories, were confusing since they reappeared in the PLU index (see figure 7.1). One subject sug-gested that the index button should be located on the edge of the panel in-stead.

Another comment on the PLU list was that PLU items could be hard to se-lect correctly. If the wrong selection is made, the cashier needs to remove the added item and the reopen the PLU list. It is worth nothing that the proto-type used a land-on strategy that did not allow for corrections of the initial selection. Land-on selection was not used in the implemented prototype.

The highlighting of items in a row (see figure 5.8, p. 39) was highly appreci-ated by the three cashiers. It is a common error to mistakenly register multi-ple items and the cashiers wished for this feature to be implemented in all Extenda’s solutions.

7.3. Touch Screen GUI

The touch screen GUI described in section 5.4 was tested on an IBM Sure-POS 700 with an infrared 15” touch screen at 800 × 600 pixels resolution.

The prototype was tested by employees at Extenda that commented on the functionality and the look-and-feel of the prototype. They also suggested ad-

Chapter 7. Evaluation

51

ditional features that they or a customer would want to add to a future prod-uct from Extenda.

By observing how the touch screen was used, it could be determined that the scrollbar was misinterpreted. Subjects tended to tap the scrollbar instead of holding the finger down and move it. A longer scrollbar could help clarify the intended use, but also introduce a bigger hand movement.

In contrary to the scrollbar, subjects immediately understood that they could drag the finger over the transaction to select a row. Except for with the scrollbar, pointing strategies seemed natural and nobody commented on how touch was interpreted. This suggests that the promotion of release as the most appropriate trigger in guideline 2 is valid also for soft keyboards.

Another observation was that the buttons on the dialogs were used as in-tended in most cases. The buttons contain a shortcut description that states that the button can be activated by clicking another button (e.g., “OK <Enter>”). This enables users to hit the enter button after a numerical input instead of reaching for the OK button in the dialog.

Both the floating icons and the item notification got positive responses. The floating icons were so popular that it even was suggested to add more within a popup menu.

The height of the rows in the transaction was believed to be too large. Nar-rower rows allow for more rows to be browsed at the same time but are also harder to select. However, since the row is selected when the finger is lifted, users could easily adjust the selection by dragging the finger (instant feed-back is given). The PLU list received similar comments.

The height of the rows can be changed in the configuration. In fact, the ap-pearance and functionally of the touch screen can be almost completely changed from the configuration.

Another comment was that the backspace button, which had been removed, would have been useful. It was suggested that the clear button (labeled “C” in figure 5.4, p. 37) could be replaced with backspace since it is used mainly in dialogs (and to clear all input) and dialogs already have a cancel button. How-ever, removing the clear button introduces a motion that must be performed to cancel the dialog.

Context sensitivity was discussed as a feature that could enhance the use of screen real estate. If the quick-access buttons changed depending on the state of the transaction users would have to use the menus less. There could how-ever be a danger in doing this if users become disorientated or the state is misinterpreted (i.e., bad context sensitivity).

Samuel Sjöberg

52

Chapter 8.

Discussion

The goal of the project was to point out the problems and challenges that arise from using a touch screen as input device in a POS application. To ac-complish this, a prototype, based on theoretical guidelines, was developed. This chapter discusses the outcome of the project and the applicability and usefulness of the theoretical guidelines.

Touch screens are starting to appear in POS environments, both in retail and grocery stores and an important question is how they improve the work-ing situation of the employee. The direct manipulation offered by touch screens increase the risk of hand and arm fatigue. This makes it questionable whether touch screens should be used in POS where much manual input is needed. Touch screens might be more suitable for in-store stations, such as customer service desks and fast food areas, than for supermarket checkout lanes. The in-store stations offer less monotonic work than the checkouts and benefit from the extra space that is cleared by the touch screen (by re-moving the keyboard).

8.1. Impact of Enterprise POS

The fact that the prototype was based on Extenda’s Enterprise POS applica-tion introduced a couple of limitations. To begin with, the underlying workflow could only be affected to a smaller extent. It was the functionality of the GUI, not the whole application that could be altered. This meant that, for example, dialogs and menus would appear and function in the same way as in the standard GUI. In addition to this, the limited time frame and the demand on full functionality limited the possibility to search for alternative solutions and to evaluate the ideas thoroughly. More limitations, introduced by the Java framework, are discussed in section 6.3.3.

The inability to change the workflow affected evaluation. The touch screen issues became the focus of evaluation, not the overall efficiency of the appli-cation. Evaluation was based on the subjective opinions of the participants and not empirical data that can be verified. This is a shortcoming that should be compensated for in the continued work. A comparison between a touch screen GUI and a traditional keyboard GUI would for example have been use-ful to conclude when the touch screen is economic to use. This was however never performed due to the limited time frame of the project. Instead, evalua-tion focused on the understanding of the concepts in use and how the theo-rized solutions (i.e., the guidelines) worked in real life.

Chapter 8. Discussion

53

Demands from potential customers, in addition to the Enterprise POS, also affected the design of the prototype. The incorporation of a Qwerty keyboard in the prototype is a result of this. Guideline 6 clearly states that the keyboard should be chosen with respect to efficiency, screen real estate and area of use and this makes the telephone layout interesting in this case. Hopefully, the reservation against alternative keyboard layouts will disappear as touch screens become more commonly used in POS environments.

8.1.1. Optimization of the Prototype

The memory footprint of the prototype is larger than the standard GUI’s. The prototype demands more computing power and more runtime memory. The standard GUI can run with a 40 MB runtime memory footprint while the touch screen prototype demands 256 MB. The larger footprint is caused by the extensive use of images, but also by the fact that more components are needed in the GUI. The use of images can be reduced and optimized, but the extra controls (e.g., the numeric keyboard and scrollbar) are still needed.

The prototype contains duplicate GUI components that can enlarge the foot-print of the application. Multiple copies of the scrollbar are for example used to control the transaction, the PLU list and the pending items list. If the lay-out is altered and tweaked, it might be possible to remove the duplicates and reduce the footprint.

When the prototype ran on the IBM SurePOS 700, a problem with graphic performance was encountered. Dialogs were sometimes only painted in half and the floating icons caused a notable delay when dialogs were painted on top. The problem was not noted on a machine with corresponding hardware specifications, running Microsoft Windows. This suggests that the problem is related to the performance of X (i.e., the graphic environment) on Linux.

8.2. Evaluation of Guidelines

The guidelines in chapter 4 were formed in an attempt to point designers of touch screen GUIs for experts in the right direction. Another reason for forming the guidelines was to make the theory in chapter 3, that covered problems with using touch screens, more concrete. The guidelines answer the question of how to develop a touch screen GUI for best performance.

The guidelines were of most use when the two low-fidelity prototypes were developed (see section 5.3). The guidelines summarize the problems from chapter 3 and suggest solutions in a straightforward fashion that made it easy to check whether a problem was addressed or not. However, it is hard to tell how useful the guidelines are for a person that has no knowledge of the theoretic background given in chapter 3. The guidelines were formed with the intention that they should be useful without any extensive knowledge of touch screens, but it remains to see if they are useful in any other project. General knowledge in human-computer interaction should hopefully be suf-

Samuel Sjöberg

54

ficient to develop an easy-to-use and efficient GUI with help of the guide-lines.

The guidelines differ in concreteness and to make them more definitive it would be possible to remove or rewrite guidelines that are a bit subjective or non-specific (e.g., guideline 3, 7, 8 and 14). These guidelines are however kept because they encourage the designer to think about the design and why a solution is chosen. The purpose of the guidelines is also to sometimes state the obvious, just to make sure it is not overlooked or neglected.

Some of the guidelines could not be followed during the development. The keyboard for example, had to be a Qwerty keyboard to conform to customer’s expectations and a mirrored GUI for handedness could not be realized.

8.3. Future Work

Future work includes a thoroughly evaluation of the Java prototype. The lim-ited time frame of the project and the demand on a functional prototype lim-ited the time that could be used to evaluate the prototype. A comparison of efficiency between the touch screen GUI and the standard GUI would also be interesting, both from a design perspective and from a marketing perspec-tive. If the operation speed were the same when items are registered with a scanner, it would be a strong selling argument.

A test setting were cashiers use the prototype in a real life situation would be useful. This kind of pilot test would help discovering the performance bot-tlenecks and eventual ergonomic shortcomings. Questionnaires and observa-tions of the cashiers would help to determine how well the conceptual model is interpreted (i.e., if it is clear how controls should be used and how they af-fect each other).

The bugs that have been noted, for example the graphic problems on Linux, should be fixed. An overall optimization to reduce the memory footprint is also needed.

Future work also includes possible changes in the underlying Java frame-work. Today’s dialog handler does not include any information of which choice that is the preferred or safe path to choose. Sometimes, “yes” is the preferred answer, other times it is “no”. By highlighting the safe, default choice the user will know which button to press to cancel the dialog. This technique is used in for example both Microsoft Windows and Mac OS X.

Acknowledgements

55

Acknowledgements

I would like to begin to thank everyone at Extenda and especially Stefan Täck-dal and Sthefan Renström for the chance to make this project happen and the positive feedback during the whole project. Also, big thank you to Peter Mathsson and Tommy Wassgren for the technical assistance. I would not have finished without the support.

Also, big thanks to my supervisor, Thomas Pederson for the good advises on how to write and structure the report.

Finally, I would like to thank my family for housing me during the project and Lisa for putting out with me during all this time.

Samuel Sjöberg

56

References

ALBINSSON, P. & ZHAI, S. (2003). High Precision Touch Screen Interaction. In Proceedings of the SIGCHI conference on Human factors in computing systems, (pp. 105 - 112).

ELO TOUCH SYSTEMS (2005a). Specification for AccuTouch Five-Wire Resistive Touchscreens. Found on the World Wide Web: http://www.elotouch.com/products/accutec/accuspec.asp Accessed 14 September 2005.

ELO TOUCH SYSTEMS (2005b). Touchscreen Application Tips. Found on the World Wide Web: http://www.elotouch.com/support/10tips.asp Accessed 15 September 2005.

ELO TOUCH SYSTEMS (2005c). Touchscreen Technology Comparison. Found on the World Wide Web: http://www.elotouch.com/pdfs/marcom/comparison.pdf Accessed 20 December 2005.

EXTENDA AB (2004). Developers Guide - Core. Internal documentation.

HALL, A.D., CUNNINGHAM, J.B., ROACHE, R.P. & COX, J.W. (1988). Factors Affecting Performance Using Touch-Entry Systems: Tactual Recognition Fields and System Accurancy. Journal of Applied Psychology, 73 (4), 711 - 720.

HIMBERG, J., HÄKKILÄ, J., KANGAS P., & MÄNTYJÄRVI J. (2003). On-line Per-sonalization of a Touch Screen Based Keyboard. In Proceedings of the 8th International Conference on Intelligent User Interfaces, (pp. 77 - 84).

JOHNSON, J.A. (1995). A Comparision of User Interfaces for Panning on a Touch-Controlled Display. In Proceedings of the SIGCHI conference on Human factors in computing systems, (pp. 218 - 225).

KABBASH, P., BUXTON, W., SELLEN, A. (1994). Two-Handed Input in a Com-pound Task. In Proceedings of the SIGCHI conference on Human factors in computing systems, (pp. 417 - 423).

LÖWGREN J. & STOLTERMAN E. (2004). Design av informationsteknik – mate-rialet utan egenskaper (2nd ed.). Studentlitteratur, Lund, Sweden.

MACKENZIE, S. (1992). Fitts’ Law as a Research and Design Tool in Human-Computer Interaction. Human-Computer Interaction, 7 (1), 91 - 139.

MACKENZIE, S., ZHANG, S.X., SOUKOREFF, W. (1999). Text Entry Using Soft Keyboards. Behaviour and Information Technology, 18 (4), 235 - 244.

NORMAN, D.A. (1988). The Design of Everyday Things. MIT Press, USA.

References

57

PAVLOVYCH A. & STUERZLINGER W. (2004). Model for non-Expert Text En-try Speed on 12-Button Phone Keypads. In Proceedings of the SIGCHI con-ference on Human factors in computing systems, (pp. 351 - 358).

POTTER, R.L., WELDON, L.J. & SHNEIDERMAN, B. (1988). Improving the Ac-curacy of Touch Screens: An Experimental Evaluation of Three Strategies. In Proceedings of the SIGCHI conference on Human factors in computing systems, (pp. 27 - 32).

PREECE J., ROGERS, Y. & SHARP H. (2002). Interaction Design – Beyond Hu-man-Computer Interaction. John Wiley and Sons, USA.

PROTOUCH MANUFACTURING LTD. (2004). Comparative Touch Screen Tech-nologies. Found on the World Wide Wide: http://www.protouch.co.uk /Amazing/AMAZING/comparative_touch_screen_technologies.asp Accessed 20 December 2005.

SCHULTZ, K.L., BATTEN, D.M. & SLUCHAK, T.J. (1998). Optimal Viewing An-gle for Touch-Screen Displays: Is There Such a Thing? International Journal of Industrial Ergonomics, 22, 343 - 350.

SEARS, A. (1991). Improving Touchscreen Keyboards: Design Issues and a Comparision With Other Devices. Interacting With Computers, 3, 251 - 269.

SEARS, A. & SHNEIDERMAN, B. (1991). High Precision Touchscreens: Design Strategies and Comparisons with a Mouse. International Journal of Man-Machine Studies, 34 (4), 593 - 613.

SHNEIDERMAN, B. (1991). Touch Screens Now Offer Compelling Uses. IEEE Software, 8 (2), 93 - 94, 107.

SCHNEIDERMAN B. & PLAISANT P. (2005). Designing the User Interface: Strategies for Effective Human-Computer Interaction (4th ed.). Pearson Education Inc., USA.

TROLL TOUCH (2004). Troll Touch: Technical Specification. Found on the World Wide Web: http://www.trolltouch.com/pdfs/techspec.pdf. Accessed 14 September 2005.

VINDRAS, P., DESMURGET, M., PRABLANC, C. & VIVIANI, P. (1998). Pointing Errors Reflect Biases in the Perception of the Initial Hand Position. The Journal of Neurophysiology, 79 (6), 3290 - 3294.

WEISER, M. (1991). The Computer of the 21st Century. Scientific American, 265 (3), 94 – 104.

WICKENS, C.D. & HOLLANDS, J.G. (2000). Engineering Psychology and Hu-man Performance. Prentice Hall, Upper Saddle River, New Jersey.

Samuel Sjöberg

58

WIGGELSWORTH J. & MCMILLAN P. (2004). Java Programming: Advanced Topics (3rd ed.). Thomson Course Technology, Canada.

a touch screen interface for point-of-sale … touch screen interface for point-of-sale applications...

Documents