Sv-lncs

Long-Term Experiences with an Iterative Design of a
QR-Code-Based Payment System for Beverages
Max-Emanuel Maurer, Alexander De Luca, Alina Hang, Doris Hausen, Fabian Hennecke, Sebastian Loehmann, Henri Palleis, Hendrik Richter, Simon Stusak, Aurélien Tabard, Sarah Tausch, Emanuel von Zezschwitz, Franziska Schwamb, University of Munich (LMU), Institute for Informatics, Munich, Germany Abstract. We report on the design and long-term use of a digital tracking sys-
tem for the consumption and payment tracing of beverages, called “Barkeeper”.
It is based on tags wearing QR-codes and its design was not primarily guided
by efficiency, but rather everyday use during the last three years in our lab. In
this trusted environment, we collected extensive usage data, making this a seri-
ous long-term field deployment of UbiComp technology. We present the sys-
tem, its iterative design evolution, the users’ views on it and insights gained by
daily usage. We argue that QR-code interaction, when implemented in a very
pragmatic way, can be not only a cheap but also a very powerful interaction
technique. Based on our experience we propose a set of general rules, which
make QR-code-based interaction practical and often superior to other interac-
tion techniques.
Keywords: visual markers, QR-codes, ubicomp, payment system.
Introduction
Caffeine is an essential part of every (good) computer science lab. A number of stud-ies proved the positive effect of caffeine on performan. As in many places, members of our group have to pay for their office consumptions introducing the need to track the expenses of each coworker. Motivated by practical issues with existing systems, we developed and tested a number of (technology-mediated) solutions over the past years to keep track of beverage consumption and share the cost. Our starting point was a shared paper tally list next to the coffee machine where consumers marked their consumption. The tally list proved to be error prone and gen-erated an increased workload as the group grew larger. An open money jar was in-compatible with the public nature of our lab, with many students and unknown people passing by. Through an iterative process driven by our own needs and everyday use, we developed a digital payment system: the Barkeeper. It has been used daily for over three years and is well accepted by all members of the group. When designing the system, we originally considered touch screens, RFID NF or even sensing cups, but we finally settled for a visual marker, i.e. QR-code, scanner for interacting with the system. QR-codes are (i) cheap, (ii) robust (in particular if coated with transparent plastic), (iii) suited to make the system highly scalable (e.g., when adding people), and (iv) easy to use. In comparison to other sys-tems, the Barkeeper does not require users to actively take pictures, which is a com-mon approach. Instead, our users place their tags under a fixed camera. To pay for an item, users scan two tags consecutively in any order: one representing the user identi-ty (see figure 1), the other representing the product. We present the results from three years of everyday interaction with this system in our lab. To our knowledge, there is no work in which visual markers were evaluated over such a long period of time in a real-world deployment. We discuss the reasons why the system is so well accepted and in particular the advantages of using QR-codes in the way our system does. We also report insights from different user perspec-tives. This includes highly personalized strategies of the payment system (e.g., differ-ent ways to scan and store visual markers) and effects on social interaction within the lab. We will also draw conclusions that are generalizable beyond the scope of our coffee kitchen. For instance, we found that spatial proximity highly influences the use or non-use of such a system, even if the difference is only a few meters. Fig. 1. Interactions performed with the Barkeeper when buying a drink. After consecutively
scanning a user and a product tag (or vice versa),sound feedback indicates the successful trans- action with additional feedback sent via email. The “Barkeeper” System
The driving idea behind the system was to improve compliance by having users pay as they take a drink, while decreasing the accounting and management load. The Bar-keeper is composed of a webcam-based scanning application on a thin client talking to a webserver. The application waits for a user to scan two tags consecutively (one person and one product tag). Once both types of tags have been scanned, the transac-tion is recorded. A simple auditory feedback indicates whether a scanning action was 1 You can find a video presentation of the system online at successful or not (e.g., system resets due to a time constraint or submission failure). As additional feedback, users receive an email after every purchase. We decided to avoid visual feedback through a monitor since the system is installed in a kitchen (prone to dirt and moisture problems). Charging user accounts is done through an administrative web interface. The everyday usage of the Barkeeper led to many suggestions for improvements. While exploring the design of a payment system, we found that using the system our-selves also gave us a better sense of what mattered and pushed us to consider how the Barkeeper integrated in the lab’s life, as we describe below by outlining the evolu-tion of the Barkeeper. The first change happened only after a few days: to save time we introduced so- called “combi-tags”, a single tag combining a user id and a product id. This enables users to print combi-tags for their favorite beverages. After a few months we intro-duced “group tags”: a special kind of person tag serving as an alias for a project or group of people whose consumption is usually covered by project funds. We also introduced a guest tag whose drinks are paid for by the entire lab. Further enhancements include a transaction feature to transfer money between ac- counts. For example, if two colleagues went to lunch together and one of them paid for both, the money can afterwards be paid back via the Barkeeper. We also adjusted the auditory feedback and replaced the original horn-like sounds by more natural ones. Successful scanning is now indicated by the call of a cuckoo and an error by the cark of a crow. These sounds are distinct enough to function as signals for the actual user and at the same time unobtrusive enough to not distract colleagues Besides an online frontend to check the balance, print combi-tags, transfer money, and change several settings we also developed an Android app to purchase drinks, make financial transactions and check our balance. Living with the Barkeeper
Today, our group consists of 18 members and is spread out over three of the six floors in the building. Thus, depending on the location of their office, people have to cross different distances between zero and four floors to get a beverage. To manage this particularity, our heterogeneous group of users developed several unique strategies. Using an online survey and semi-structured interviews we gained insights into these individual strategies. User Perspective: Daily Life with QR-Codes
A survey with 21 current and former users (six female; 31 years avg.) yielded results about usage patterns. 62% of the participants stated that they used the system daily, 77% of these even multiple times a day. The preferred interface for buying drinks is 2 As a subtle side effect, one user reported being now irritated when hearing a crow in nature, the tag-based payment, which is used frequently by the majority (81%). Nearly all (95%) hardly ever use the web interface and only two (10%) use the mobile app. Sev-eral styles of tag usage for payment have emerged: most users (38%) search for both – person tag and product tag – first and then place them under the camera consecutive-ly. Others (19%) find one tag, place it under the camera and use the scanning time for finding the second tag. One user notes: “I always kind of conceived it as a game: do I succeed in finding the second tag before the purchase would fail due to a timeout?” Seven participants (33%) speed up the process using at least one combi-tag. Five participants (24%) reported other methods such as attaching a small flag to their name tag or changing the location of their personal tag (e.g., sticking it onto the kitchen cabinet or storing it at one’s office desk). Furthermore, people print tags on colored paper to make them more easily distinguishable. People even started to optimize their processes in the kitchen according to the Barkeeper paying process (e.g., starting cof-fee brewing before scanning the tags). The Barkeeper can even act as a decision help-er: “Sometimes, the first drink tag I see influences my choice of product.” Fig. 2. Rating of the tag-based payment.
In general, participants are satisfied with the Barkeeper. The tag-based payment is rated as easy-to-use (mode=4 on a five-point Likert scale ranging from 1=strongly disagree to 5=strongly agree), stable and robust (mode=4) as well as fast (mode=4) (see figure 2) with some people speeding up interaction by using combi-tags. Besides the initial barrier of printing these tags manually, there seem to be different reasons for that. Participants apparently differentiate between fetching a quick drink and tak-ing a larger break from work. Although we did not find any significant differences in our questionnaire results, this also seems to correlate with the three different floors people are working on. People on the lower floors (without coffee kitchen) possess less combi-tags as they have to come up three or four floors to get their drinks and mostly seem to do this for larger breaks. Colleagues working on the upper floor (where the kitchen and the Barkeeper are located) do their purchases in between their work and more in a hurry, using combi-tags more often. In terms of efficiency, the Barkeeper introduced the biggest improvement for the administrative staff in our lab. The old tally list required the secretary to take it down, calculate all unpaid amounts and put a new list up every week. The only task now is to accept the money from users, put it in the physical cashbox and add the paid amount to the respective Barkeeper account using the administrative web interface. As one secretary stated, the most complex thing for her while working with the Bar-keeper is “to put the cash into the cashbox”. Security, Privacy, Trust and Social Implications
Obviously, the Barkeeper is not secure against misuse. A photocopy of a tag or the knowledge of its contents is enough to fake tags for malicious purchases. However, security can be easily increased by keeping the tag with oneself. In comparison with a tally list, the system offers much higher security and privacy. Wrong tally marks have been undetectable and occasional incorrect purchases inevitable. Due to the purchase confirmation email as well as an overview with all purchases in the web interface and in the mobile app, wrong bookings are easily detectable. From a social perspective, the daily use of the system influences group behavior. Being used for interpersonal money transfer, the Barkeeper has established a new verb in communication between lab members. “You can just barkeeper that to me” has become a phrase commonly used. The data of the Barkeeper is also used as a means of social pressure to support positive payment behavior. Every 30 days, the lab employee with the highest debt is announced in an email and is forced to buy milk for the coffee for the next 30 days. This caused the cash box to change from being constantly empty to being well filled. Benchmarking
To assess the usability of the different booking methods (tags, web and paper), we measured average interaction times with each of them. Methodology. We measured the average interaction times with single tags, the web
frontend and the tally list of twelve users. The Android app was excluded due to un-
derutilization. Measurements were done with a stopwatch during daily routine to cap-
ture influences like the changing order of tags in the collecting box. Hence the meas-
ured times include searching the right tags as well as successful scanning. The inter-
action with the tally list includes the search for the pen as well as for the right row and
column. Possible personal strategies were recorded.
Results. Average interaction time with the tally list was fastest (m=7s; sd=2s), fol-
lowed by the web frontend (m=15s; sd=3s). The interaction time with the single tags
was slowest (m=22s; sd=7s). Only four participants used combi-tags, although using
them was faster than the tally list (m=6s; sd=1s).
The analysis of the Barkeeper database is in line with the qualitative results. Until December 2012, 11,941 QR-based transactions were performed, while 1,188 web-based transactions (10%) and only 76 transactions using the mobile app (0.6%) were logged. Since its introduction, the Barkeeper was used on 96% of all work days (ex-cluding public holidays) with a total average of 20 transactions per day. During this time, a total of 14,878 € have been transferred. How to Make QR-Codes Work
The benchmark results show that the introduction of the system produced measurable disadvantages for its users in terms of time. However, users accepted the transition, continue to use the system daily and even stick to the slower procedure using two single tags. Hence we have experienced a difference between subjective experience of time and objective interaction time. In the following paragraphs, we will point out a few general findings, which can be applied beyond our special use case. Performance Is Not Always the #1 Priority
In HCI research, interaction speed is one of the most used dependent variables for measuring system quality. However, in some scenarios like our system, this might not be as important as a subjective experience of time. Being offered diverse modalities (tags, app, Internet) and various ways to speed up interaction (e.g. combi-tags) only a fraction of the users adopted those possibilities and preferred using the tags. This is probably due to the integration of the interaction into the process of taking a break and due to the generally playful experience. We argue that systems that are able to “hide” time costly interactions within other processes or through playfulness can still be well accepted even while being objectively slower. A Static Camera Makes QR-Codes More Usable
One of the major differences of our system to the most common usage of visual markers is that users take the visual marker to a fixed camera instead of actively tak-ing a picture with a camera. Based on our results, we argue that usability is greatly improved by this design, since the manual effort spent on taking the picture and prob-lems with resolution and focusing are removed. Issues introduced by this setup, like loss of tags, are easily solved as printing tags is straightforward and cheap. In our exploration, we additionally found that scanning is even stable for old, raddled and dirty tags. Proximity Matters
The most critical issue deciding over use and non-use of the system seems to be the proximity of the scanning station to the desired objects. As long as the scanning sta-tion is next to the coffee machine, users operate the system in parallel to the prepara-tion of beverages, which has a positive influence on paying behavior. At a time when we were forced to rearrange the setup due to the renovation of the kitchen, even people passing the scanning station while returning to their office forgot about paying and later had to make up for it with the help of the web-based interface. This effect appeared even under the condition that the system was still quite close to the beverage preparation place, i.e. within 5 meters distance. We compared purchases from that period with the same period one year earlier. Although the number of aver-age bookings per user stayed nearly constant (M=4.2 adjacent; M=4.3 detached) the average number of tag bookings decreased a lot (M=10.6 adjacent; M=6.6 detached). Hence, proximity ensures a proper integration into the process, which is a key at- tribute according to our three-year deployment. When informally asking why the system was not used when it was slightly farther away, one answer was that taking and paying a drink felt like two different tasks. The subjective feeling of the time required changed and made the overall experience less pleasant. People also started to wait until they had several empty bottles on their desks before making a bulk payment using the web interface. Simple Design Works for Groups with High Internal Trust
We found that the Barkeeper’s rather simple design works because our group has a high level of internal trust and we do not have to care about complex security and privacy issues. Nevertheless, we have experienced ourselves that the system is mature enough for everyday use in the real world. Very simple features of the system like the email notification on purchases introduced enough transparency such that the system never was put into question. The reliable scanning process with an error rate close to zero certainly has also contributed to that. Iterative and Autobiographic Design Works
The success of the system shows that it is a helpful approach to start with a very sim-ple solution, which solves a single key problem experienced in daily life, and to evolve the system only based on concrete user suggestions. The developer is among the user group and enjoys people making suggestions for new features. Some design decisions, which may be seen questionable for an outside user (like the purely audito-ry feedback), evolved in a social process and therefore enjoy strong support by the group, making them a “normal” part of everyday life even for new members. Conclusions
In this paper, we presented a simple but effective system for keeping track of individ-ual beverage consumption within a group. We explained the design evolution and the long-term results of a visual marker-based system for this purpose. We argue that visual markers are well-suited for systems which can integrate their use into the standard work process – in our case scanning the tags while coffee is brewed. Interestingly, although more time-effective alternatives were provided, users preferred to use visual markers. Despite the basic interaction mode being slower than a traditional tally list, users were able to build up own strategies for fast usage. Combined with additional en-hancements such as combi-tags, the marker-based interaction can now even outper-form tally marks in terms of speed. Nevertheless, performance proved to be not the most important factor of every interactive system. Even a slower interaction may be better suited for certain real-life interaction tasks if it integrates well into the usage scenario and is appealing to the user for other reasons. The results of our user study and the qualitative data about the system itself showed that, although the system offers various possibilities for extended user privacy and security, users do not take advantage of those. Providing a mostly error-free and easily recoverable payment system leads to a trust level that is beyond security or privacy worries. We conclude that systems providing a high transparency of their inner workings and data handling are accepted to be more privacy invasive. Our findings can easily be applied to other domains that meet similar conditions of 1) giving individual access to global resources at different points 2) high internal trust within a user group and 3) appropriate space and interaction design that allows inte-grating the scanning interaction. Examples for similar situations where our design could be used are the usage of copy machines, lending out equipment or taking over routine jobs shared in a group. For usage in a public scenario such as a museum, the design is not adequate due to the missing group trust. Nevertheless, the idea of using a scanning station for movable QR-tags can also be reused in a museum (or similar public environment), e.g. by printing the QR-codes on the entrance tickets . As the system’s development has always been inspired by users’ needs and ideas, they will definitely help to enhance it in the future. As we found out that performance is not necessarily a critical factor, features that support the playfulness of the system will most likely be added and improved. Overall, we believe the system can be used as a blueprint for a number of application scenarios in closed user groups, far beyond just keeping track of coffee consumption. Acknowledgements
We want to thank our former colleague Raphael Wimmer for reminding us of im-portant details; Gregor Broll for providing some excellent related work; Alexander Wiethoff for his input at the start of writing this; Anita Szász for inspiring us to create the Barkeeper; Rainer Fink for keeping the server in a good shape; Denso Wave for inventing the QR codes and finally the former members of our lab that participated in the questionnaire. Besides this we want to thank the Barkeeper for being so patient with us and to all of you: QR amazing. References
1. Beigl, M., Gellersen, H.W., Schmidt, A. Mediacups: experience with design and use of computer-augmented everyday artefacts. Computer Networks 35, 4, 401-409 (2001). 2. Jarvis, M.J. Does caffeine intake enhance absolute levels of cognitive performance. Psychopharmacology 110, 1-2, Springer, 45-52 (1993). 3. Neustaedter C. and Sengers P. Autobiographical design in HCI research: designing and learning through use-it-yourself. In Proceedings of the Designing Interactive Systems Con-ference (DIS '12). ACM, New York, NY, USA, 514-523 (2012) 4. Sawers, Paul: With more than 5m visitors so far, Google’s London Web Lab experiments are still going strong. http://thenextweb.com/google/2013/01/13/3-million-visitors-later-googles-chrome-web-lab/ [last accessed 03/22/2013] 5. Want, R. An introduction to RFID technology. Pervasive Computing 5, 1, 25-33 (2006). 6. Want, R., Fishkin, K. P., Gujar, A., Harrison, B. L. Bridging physical and virtual worlds with electronic tags. In Proc. CHI 1999, ACM Press, 370-377. 7. Want, R. Near field communication. Pervasive Computing 10, 3, 4-7 (2011).

Source: http://www.tabard.fr/publications/Interact_Barkeeper.pdf