LoFi-Group:The Flash

From Cs160-sp08

Contents 1 Work Distribution 2 Introduction and Mission Statement 2.1 Introduction 2.2 Mission Statement 3 Prototype Description 3.1 Skin 3.2 Highlighting 3.3 Main Screen 3.4 Backgrounds 3.5 Sliders 3.6 Help Menu 3.7 Blinking Speed 3.8 Alarm 4 Method 4.1 Participants 4.2 Environment 4.3 Tasks 4.4 Procedure 4.5 Test Measures 4.5.1 Process Data 4.5.2 Bottom-Line Data 5 Results 5.1 Tables 5.2 Test Subject 001 Result Notes 5.3 Test Subject 002 Result Notes 5.4 Test Subject 003 Result Notes 6 Discussion 7 Appendix 7.1 Informed Consent Form 7.2 Task Instructions 7.3 Observations

Work Distribution

• CHOW, JONATHAN NICHOLAS - Interview Role: Computer
• DHARAWAT, RAVI R. - Interview Role: Note Taker/Observer
• PANG, RANDY JASON - Interview Role: Facilitator
• TRAN, BRIAN TRONG - Interview Role: Greeter

All team members contributed to write up and creation of low-fidelity prototype.

Introduction and Mission Statement

Introduction

The system being evaluated is an interface for an Android flashlight application. This application has a flashlight mode, a blinking mode, a timer/alarm mode, and an ambient mode. Currently, there a number of cellphone features plague users trying to use their cellphone as a source of light. These features include the backlight always dimming and not being able to change the brightness or color of the screen. Our aim is to create an application that is easy to use and includes features that are catered toward the needs of users in the dark.

Mission Statement

The goal of this project is to create a flashlight application for Android that has an intuitive interface and also includes useful features for users in the dark with no other means for a light.

Prototype Description

Skin

We have created a printout of the QVGA-L emulator skin that approximately measures the size of the actual phone. The user "presses" these buttons when interacting with the prototype while saying which button they are pressing to avoid any confusion.

Highlighting

The person who acted as the "computer" uses a pen to point to the option that is currently highlighted.

Main Screen

The user is started from the main screen of the flashlight application, although, an Android home menu was created for users who press the "home" key. By default, the Flashlight mode is highlighted.

Backgrounds

Yellow background with low brightness.

Yellow background with medium brightness.

Yellow background with high brightness.

For each of the modes (flashlight, ambient, and blinking), we use different pieces of paper with colored lines to represent the color and brightness of the screen (multiple close lines represent a brighter screen, while lines far away represent a darkened screen.) Blinking was represented by the "computer" opening and closing his hand. The faster he opens and closes his hand, the faster the screen is supposed to be blinking. A flashlight that is "off" is represented by a screen with an "X" through it.

Sliders

A frame around the background colors was made to represent the color and brightness sliders. For all modes, pressing the "up" or "down" keys changes the brightness, while pressing "left" or "right" changes the color. A small square with the current mode icon was placed on the bottom right corner of the frame. The default brightness is at the very minimum (down is lower brightness). The default color is white.

Help Menu

Two types of help screens were created. The one used for the actual experiment was the one with a sub-menu listing all the different help menus. The testers were asked whether they preferred this help scheme to one where all the mapped buttons were displayed on the same screen. By default, "Flashlight Help" was highlighted.

Blinking Speed

The blinking mode has an overlay showing the speed of the blinking. This "window" was added on top of the background color screen (in the center) when on blinking mode. Black squares were used to fill in the speed boxes describing the speed of the flashing. The more boxes that are filled in, the faster the blinking. The "select" key is used to cycle through the modes. By default, no squares are filled in and the screen is not blinking.

Alarm

This is the alarm starting page. It appears right when the alarm mode was chosen. Individual pieces for each time combination were created to be placed on top of this page. When the page is opened, the cursor is placed on the "ON/OFF" option. Users can change the values by pressing "up" or "down". The options can be selected by moving "left" or "right". Moving "left" from "ON/OFF" or "right" from "AM/PM" brings the user to the start button. The time values can also be entered using the keyboard. The default time option is "ON" and the default time is "12:00 AM".

Method

Participants

All three participants were UC Berkeley college students coming from a variety of different majors: Economics, Molecular Cellular Biology, and Astrophysics. Participants were friends of friends of group members. Participants were selected from different fields to emphasize users with different familiarity towards technology and user interfaces in particular. Even though we had other volunteers willing to participate, our group chose these specific three participants because they were volunteers from non-engineering backgrounds. We wanted to focus on college aged students without a technical major because they are the target user group for our application.

Environment

Our group reserved a study room in Doe Library to hold interviews. Testing environment was controlled and quiet so that the user could focus on tasks and so that the group could observe user remarks and actions. The prototype was in plain view for all group members and user so that everyone could comfortably see the prototype at all times. Prototype was set up on a table in the study room before users arrived. After each user finished, the prototype and room was restored to original state so that the next user would have the exact same experience.

Tasks

These were the written tasks given to the user:

• Task 1: Change color, brightness, and turn it off.

For this task, please imagine yourself in the dark trying to look for something in the dark with your cellphone. Your favorite color is blue, so you want to have your cell phone emit a bright blue light. After you've gotten a bright blue light, you've found what you're looking for and longer need the light, so you want to turn it off to save power.

- Set your cell phone to emit a bright blue light - Turn it off afterwards

• Task 2: Make it blink!

For this task, please imagine yourself in a large crowd. You're trying to make yourself more noticeable and attract the attention of your friend by making your cell phone blink at a high speed. Your friend finds you immediately after you get your phone to blink fast, and you subsequently want to make it stop blinking.

- Make your cell phone blink really fast - Make it stop blinking afterwards

• Task 3: Set an alarm.

For this task, please imagine yourself in a library wanting to set an alarm for 8:15pm, but please keep in mind that silent visual cues (e.g. your cellphone lighting up) is far more preferable in an environment like a library where noise in unacceptable.

- Set an alarm on your cell phone to silently emit light at 8:15pm

• Additional Notes

Although not written on the task sheet, the tasks were ordered in terms of difficulty (e.g. Task 1 was easy, Task 2 was medium, and Task 3 was hard). We didn't want to write the difficulty down because we thought it might subconciously affect the tester and distort the test results.

Procedure

• Greet the user

To begin the test, our greeter greets the test user and situates them in the test area. Afterwards, we introduce ourselves and explain our roles in the test.

• Explain the situation

After we introduced ourselves, the greeter would give a general overview. This was more or less an explanation of what Android is and a description of our flashlight application. At this point, the greeter would give the user the consent form to read over and sign.

• Explain the test

At this point, the facilitator took over for the greeter and explained the test. The facilitator told the user that the test would consist of them walking through three tasks involving our application. The facilitator then explained the notion of "thinking loudly", and urged them to just let us know what was going on in their minds (e.g. if they were having any problems or they didn't quite know what was going on) as they were doing the tasks.

• Walk through an example test

To give the user familiarity with the interface, the facilitator explained and walked the user through our example task, which was navigating to the help menu from the main menu, bringing up a help page, and subsequently navigating back to the main menu with the back button.

• Explain and walk through the tasks

At this point, the facilitator would give the tester the task sheet with all the written tasks, and give a brief oral summary of the current task (more or less what was written on the task sheet). If the tester ever seemed confused, in a state of thought, or was inactive for longer then a few seconds, the facilitator would probe the tester and ask what they were thinking. If the user was clearly in a state of confusion, the facilitator would interject with hints (e.g. . Upon completion of some tasks, the facilitator would interject with an updated scenario (e.g. "great! your friend has just found you and now you want to make it stop blinking". Or "now that you have set the color and brightness, you want to turn the light off to save power."). After the user completed a task, the facilitator would simply congratulate the user and explain the next task with no questions in between.

• Debriefing

After the user had successfully finished all three of our tasks, everyone (though primarily the facilitator) would ask the tester about their thought process during problem issues we noticed (parts where they got stuck or confused), what they thought of the experience and interface in general, and if they had any general feedback, comments, or feature requests. Additionally, as we noticed certain problem issues from the early interviews, we asked the user for their feedback on those particular interfaces (so for example, early on we noticed a big problem with the alarm layout, both the setting interface and post-set functionality [e.g. what did they expect it to do on set]). We also asked users to look at two versions of our help menu and give us their feedback. Finally, we'd all thank the tester for taking the time to participate in our test.

Test Measures

Process Data

"Big Picture" measurements:

• If testers could understand the flow from one screen to the next.
• If testers understand the meaning of the Alarm menu.
• Which of the two versions of the help menu makes more sense.
• If key actions for each mode makes sense to the users.

Bottom-Line Data

Low-Level Data that we measured includes:

• Time for the completion of each task. The time measured included the time the "computer" took to change screens (which was not always take the same amount of time for each tester) and communications that occurred between the tester and interviewer during tasks.
• Number of errors per task. One error consists of the first error and the following button presses to undo that error. For example, if the user tried pressing "Home", although he meant to go "Back", we counted pressing the "Home" key and re-entering the application as 1 error.

Results

Tables

• Test Subject 001

	Number of errors	Time (in minutes)
Task 1	1	5
Task 2	4	10
Task 3	0	8

• Test Subject 002

	Number of errors	Time (in minutes)
Task 1	2	10
Task 2	0	4
Task 3	1	9

• Test Subject 003

	Number of errors	Time (in minutes)
Task 1	2	11
Task 2	0	4
Task 3	3	12

Test Subject 001 Result Notes

• Activity 1 Notes
  • Subject tries to manipulate side buttons first when trying to change brightness

• Activity 2 Notes
  • Subject shows confusion when viewing blinking mode screen
    • Does not know what to do with the blinking level modifier buttons
    • Tries to hit buttons that did not do anything, repeatedly

• Activity 3 Notes
  • Does not realize that there was an extra step to take after pushing start button

• Extra Comments
  • Subject believes changing color and brightness was unnecessary
  • Subject suggests contextual help
    • Scheme would include a persistent help button that brought up information relevant to the current task
  • Subject suggests search
    • Lists topics, clicking on topics heads to topic pages
  • Subject suggests online manual

Test Subject 002 Result Notes

• Activity 1 Notes
  • Trouble adjusting brightness
  • Trouble turning off flashlight (w/o going back to menu)
  • Tried to manipulate help instructions directly

• Activity 2 Notes
  • Task is accomplished without incident

• Activity 3 Notes
  • Confused by alarm screen
  • Thought there was an option for sound, and was confused as to how to reach it
  • Hit middle button to no effect (Was trying to hit start/stop when it wasn't selected)
  • Does not realize he is finished
  • Did not know what switching on to off did

• Extra Comments
  • Subject stated that they generally learned how to use things by trial and error
  • Start/stop button linked to middle button in alarm
  • Expected to go back to the menu after setting alarm

Test Subject 003 Result Notes

• Activity 1 Notes
  • Tries to turn off flashlight by turning brightness all the way down
  • Tries to turn off light by using side buttons

• Activity 2 Notes
  • No incidents

• Activity 3 Notes
  • Has trouble utilizing the alarm menu
  • Is not clear on the operation of the directional buttons
  • Does not know what the on/off button does
  • Thinks the interface unintuitive
  • Does not think the countdown functionality is not useful
  • Would like the option to have sound, but thinks it may add too many levels of clicking

• Extra Comments
  • Maybe rgb color codes?
  • Possibly color choosing by camera
  • Any button press to bring up the menu, but center button should be reserved to turn off/on
  • Wants to utilize side buttons
  • Default flashing mode
  • Scrolling for the side buttons instead of cycling
  • Turn on/off blinking mode? - Yes (if flashlight has it)
  • No off button for flashlight? - Yes
  • Settings should be saved
  • Icon to indicate alarm

Discussion

• Side Buttons
  • One of the first things we noticed was that test subjects really wanted to use the side buttons (usually volume control) for something. Most of the time it was brightness control. In a cross-function sense, this does seem intuitive. Whereas when talking on a phone we are concerned with adjusting sound volume, on a flashlight we are concerned with adjusting the volume of light, both tasks being analogous. However, it does introduce some problems as far as consistency goes. There is no similar side button for adjusting the color. This may not be a problem as one subject questioned the use of having different colors at all, but all things as they are, the interface would use the right/left buttons for changing color and then the volume controls for brightness, as opposed to the up/down buttons that seem more natural given the use of the right/left. This is a question that requires further deliberation, but we have learned that users want to manipulate the volume controls

• Alarm Page
  • The alarm page gave users the most difficulty. A great part of that difficult lay in the fact we called it an alarm, and not what it was, which is a timer. Alarms are off until they need to be on, so when given this metaphor, a user does not understand what changing the following does:

Turn ON at 6:00 a.m.

to this

Turn OFF at 6:00 a.m.

Some believed that it was meant as a mechanism for removing an alarm. The question here then is "is it worth it to have 'night light'

functionality". "Night Light" functionality is the ability to have the light be on for a certain amount of time then turn off. If we were to keep it

it would most likely have to be split into a separate mode to avoid confusion.

• Some users felt that light might not be enough for an alarm, and that sound should be added. This introduces an additional UI difficulty. We cannot have sound be default, since one of the key reasons for a light alarm is that it doesn't wake anyone who cannot see it. This means that we should have some way of toggling the sound on and off. For completeness, we may need to add volume adjusters for the sound (a chance to use the volume buttons!) and different sounds to play. This would add quite a bit more clutter to the interface, so further testing would be required, but it is something to consider.
• The way in which the time is entered into the alarm may have to be reconsidered. One user did have some initial difficulty doing it, and not all realized that they could enter in numbers through the keyboard. A textfield may be a better solution, since sliders imply locked directional movement

• Blinking Page
  • The blinking page presented some problems for users because of the initial screen and feedback. Since none of the indicators showing the blinking rate were selected, there was a bit of confusion as to what to do. One idea that we thought was to use the volume adjusters to change the blinking rate, but this may reduce consistency with other modes.
  • There was also a bit of a problem with having the device not blinking at mode zero. This effectively was the same application as the flashlight. A solution would be to have it set to blink at the slowest rate on start up, or to combine the flashlight and blinking modes.

• Turning Flashlight On/Off
  • Most users were confused about how to turn the flashlight off (they simply went back to the menu). Removal of this feature could possibly allow combining the flashlight and the blinking modes.

• Feedback
  • We noticed that a few times users would hit buttons that didn't do anything repeatedly. To help prevent that, some visual or audio feedback could be used.

• Help Menu
  • The Help Menu proved a little unpopular. The reasoning was that this is a relatively small, quick usage app. Some felt the app was intuitive enough that a help menu was unnecessary. Others felt that it took too many screen changes to reach particular help items. Searching for help is an interesting idea worth exploring. Another is help contextual to the current activity. That could be done with a persistent quick-key throughout the modes.

• Things the experiment could not reveal
  • Using a paper-prototype to prototype our application, while allowing us to learn much about the menus, told us nothing about the reaction of users to the aspects of the application having to do with light. Questions that remain unanswered
    • How does blinking affect the user's ability to configure the blinking mode
    • How would the color of the light affect the user's ability to read the sliders
    • Are colors useful/worth it?
    • How would brightness affect the user's ability to interact with configuration screens?

Appendix

Informed Consent Form

Task Instructions

Observations

• Subject 1
  • Activity 1
    • No trouble finding select button
    • No trouble accomplishing task
    • Manages the sliders well, with no explanations
    • Originally looked for an up-down button on the side to manage brightness, upon not finding this, used the up down
  • Activity 2
    • Hits home button first
    • Takes a little time (icon may not be clear) to select the flashlight app
    • Navigates to the blinking mode
    • We need to highlight the different speeds!
    • Was confused by initial screen
    • Need some sort of feedback for illegal actions
    • Had trouble realizing what buttons to use
  • Activity 3
    • Hits home button again
    • Thinks home screen is the main screen for the app (Alarm is a hidden feature)
    • Manages the time sliders well
    • Thinks that color selection should be done before pressing start
    • Doesn't think color and brightness changing is unnecessary, tedious
    • Thinks a random color setting might be useful
    • Wants a touchscreen!
  • help screen errata:
    • Unsatisfied with help screen
    • Suggests contextual help geared towards current activity
    • activated by icon
    • Suggests search lists particular topics, clicking on topics leads to relevant menus
    • Maybe a manual on the internet
  • blinking errata:
    • how to turn off blinking?
    • click speed again
  • Alarm errata:
    • blinking duration
    • wants it to blink
    • wants snooze functionality
• Subject 2
  • Activity 1
    • No trouble manipulating the sliders
    • Has trouble adjusting brightness
    • Has some trouble turning off the flashlight
    • Navigates back to turn off light (does not know how to turn off light from flashlight menu)
    • Navigates to help to find out how to turn off light
    • Tries to manipulate help menu directly, instead of reading instructions (note: make it obvious what is a button and what is not)
    • Navigates back to flashlight after it doesn't work, and applies instructions
  • Activity 2
    • Navigates to main menu
    • Navigates to blinking
    • hits select
    • hits select again
    • hits it again
    • hits back
    • task success!
  • Activity 3
    • Pondered the screen for a bit
    • Didn't realize there were no sounds
    • Is able to manipulate the sliders well (naturally)
    • Tries to hit middle button, nothing happens
    • Wonders if he is done for a while
    • Wants someway to know what kind of alarm is being used
    • Is a fiddler, fiddles
    • Thought nothing would happen if he changed the on to off (Did not understand the interface)
    • Alarm – usually associated with a sound
  • Extra Comments
    • Thought there might be an issue with rt/lft up/dn for color/brightness, but personally found it intuitive
    • Had issues with how the alarm was laid out
    • Start/stop button linked to middle button in alarm
    • Expected to go back to the menu after setting alarm
    • Thought original help menu is more clear
• Subject 3
  • Activity 1
    • Manages controls well, is able to change color and brightness well
    • First instinct to turn off light to turn down brightness
    • Navigates back to turn off light
    • Thinks to use side buttons to turn off light in flashlight mode
    • Finally is able to turn off light after a bit of trouble
  • Activity 2
    • Correctly identifies the middle button as the thing that changes blinking speed
    • Does everything right
  • Activity 3
    • Hits the call button to bring up the call menu
    • Has a bit of trouble utilizing the alarm menu
    • Is not clear on the operation of the directional buttons
    • Does not know what the on/off button does
    • Unintuitive
    • Buttons to add
      • Turn on
      • Turn off
      • Start (change to set)
    • Does not think the countdown functionality is not useful
    • Would like the option to have sound, but thinks it may add too many levels of clicking
    • Did not want to play around with the help menu
    • Felt the interface was intuitive enough

• • Help menus
    • Feels the original menu is more descriptive
    • But the other one is easier to navigate
    • Modify the second one to only be icons
    • But feels some icons may be poor (possible illegibility)
    • understood what ambient mode was without use

• • extra comments
    • Maybe rgb color codes?
    • Possibly color choosing by camera
    • Any button press to bring up the menu, but center button should be reserved to turn
    • off/on
    • Wants to utilize side buttons
    • Default flashing mode
    • Scrolling for the side buttons instead of cycling
    • Turn on/off blinking mode? - Yes (if flashlight has it)
    • No off button for flashlight? - Yes
    • Settings should be saved
    • icon to indicate alarm

---