Low-fidelity prototyping: HTML / Flash prototypes

This subsection discusses a case study based on a HTML-prototype and lessons learned from the usage of such prototypes. HTML or Flash low-fidelity prototypes are similar to the previously discussed paper prototypes, but they show a realistic interface that can run on a real mobile device. This subsection focuses on very simple prototypes that merely show different screens that are linked via hyperlinks.

5.2.2.1 Case Study

This HTML prototype represented an application for automatic form filling on mobile devices [Rukzio et al. 2004c]. The goal was to figure out whether people like such an application that automatically fills in forms with their personal data like name, address and city. A Sony Ericsson P800 with the internet browser Opera for Smartphone/PDA was used. In addition, two versions of a HTML-based hotel reservation service were developed. In the first version (see Figure 42a and Figure 42b) the user has to fill in every form field by herself whereby in the other version (see Figure 42c and Figure 42d) the fields where already filled out with user data.

In the second version, two errors were integrated (wrong address and credit card number) that the tester had to identify and to correct. In both versions, the first name, last name, address, city, ZIP, phone number, e-mail address, method of payment, card number and expiration date have to be filled in, accepted or corrected.

The HTML prototype was tested by 8 users (colleagues from the department) whereby all where familiar with web forms and the concept of mobile services but all of them used a Sony Ericsson P800 for the first time.

5 Development Process of Physical Mobile Applications

a b c d

Figure 42: Screenshots of the HTML prototype.

The following Figure 43 shows the durations for filling in the data in the empty forms and the completion time for pre-filled forms. Additionally, it shows the average times the testers needed in a first, second and third run.

0 50 100 150 200 250 300 1 2 3 runs se co n d s

Empty forms Pre-filled forms

Figure 43: Average input times over all users. The users were asked to perform several runs.

The most important result was that the testers needed about four times longer to fill the empty form compared to the pre-filled form which needed corrections. Furthermore it was recognized that the testers learned quit fast to use the virtual keyboard and the styles of the Sony Ericsson P800. But still, the factor four exists after three runs. From this it was concluded that a form filling application would be extremely helpful and would if intensively used, support the further dissemination of mobile services.

Beside these numeric results it was recognized that most users where frustrated when they used the stylus of the smart phone for inserting text. It was thus concluded that it is very important that the user has to type in as few text as possible.

5 Development Process of Physical Mobile Applications

At the beginning of every test the tester were told the intention of the different forms. Furthermore they were told that in the second version there is an intelligent assistant which tries to fill out all fields based on the user data stored on the mobile phone. After this explanation many testers said they do not want to give their personal data away. From this the requirement was derived that all data has to be stored on a physical device that is owned by the user herself. The users liked to be in control and wanted to see what data is filled in the different fields such that she has the possibility to delete or change the automatically inserted data. This approach provides the user an overview where and when data is transmitted and what data is given to which service.

5.2.2.2 Lessons Learned and Best Practices

Realistic user experience: The big advantage of a low-fidelity prototype developed with HTML or Flash is its realism. Many testers using such a prototype might think that they use matured product. Therefore the experience of the users and their feedback is much better when comparing it with a user study based on a paper prototype. Furthermore the testers have to imagine how some aspects look like when using a paper prototype which is not the case when using such a realistic prototype.

Quick and easy: Such prototypes can be built easily and in a quick way when having the knowledge to implement HTML pages or Flash applications. One needs only design the screens and define the hyperlinks between them.

Limited functionality: When using a paper prototype, new functions can be added on demand by creating a new paper based interface. This is not possible when using an HTML or Flash based prototype because it takes some time till a new screen is defined. Although this might be done in 5-10 minutes, this is a too long a break within the evaluation of the prototype by a user. Such a prototype also only has limited interactivity, so it is hard to simulate interactions which react on written user input or to show personalized pages. One solution for the latter problem is to define what the users have to type in and by this it is also possible to simulate interactive applications.

Unrealistic physical mobile interactions: The physicality of physical mobile interactions can not be expressed by such prototypes. It not possible to access the camera or to react to NFC events. Such functionality can only be added by Wizard of Oz methods [Dahlbäck et al. 1993] or through the support of a person who supervises the test. This person can say things like you did not touch the NFC tag correctly or the processing of this action will

now take 3 seconds.