FinalPrototype-Group:The Flash

From Cs160-sp08

Jump to: navigation, search

Contents

Files

Team Member Contributions

  • CHOW, JONATHAN NICHOLAS - Flashlight / Integration
  • DHARAWAT, RAVI R. - Blinking / Ambient
  • PANG, RANDY JASON - Alarm
  • TRAN, BRIAN TRONG - Menus

Although these were their primary roles, all team members contributed to write up, creation, and debugging of various parts of the final prototype.

Problem and Solution Overview

Most college students and young professionals carry cell phones on their person. These cell phones function not only as a means of communication, but fill a variety of different roles. On such role is that of a light source. Since these individuals seldom maintain a flashlight on their person, their cell phone is the next best tool. Unfortunately, current cell phones are not made with the idea of keeping a steady source of light in mind. So, we have devised a Flashlight Application for the Android phones which will allow users to keep a constant source of light with them always.

This Flashlight Application contains 4 different modes: Flashlight, Blinking, Alarm, and Ambient. Flashlight mode is a standard colored screen with the ability to adjust the brightness and color of the screen. Blinking mode is similar to Flashlight mode, except background is blinking according to a user selected speed. Alarm mode allows a user to set a silent "light" alarm. Ambient mode is for users who want a more animated source of light.

Target User Group

College students or young professionals. These are the groups of people who would most likely buy an Android capable phone. This also encompasses the age group we believe would get the maximum benefit from our application's features. Although the flashlight mode is useful for most people, situations that are more suited to college students and young professionals are: looking for the right key on your keychain, looking for items dropped in the car, and trying to navigate an apartment without waking roommates. We also envision Blinking mode being useful for a group of friends who go to a crowded event, such as a concert, and need help finding one another.

Tasks

   * Task 1: 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.

- Make your cell phone blink at medium speed.

   * Task 2: 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. You want to use a dim red light so it won't ruin your nightvision. After you've found what you're looking for, you no longer need the light, so you want to turn it off to save power.

- Set your cell phone to emit a dim red light - Turn it off afterwards

   * Task 3: Set an alarm and watch light animations until it goes off.

For this task, please imagine yourself in a library wanting to set an alarm for one minute in the future, but please keep in mind that silent visual cues (e.g. your cellphone blinking) is far more preferable in an environment like a library where noise in unacceptable. However, after you set your alarm you find yourself bored, and want to be entertained by some light animations until the alarm goes off.

- Set a flashlight alarm on your cell phone to go off in one minute and watch light animations until it goes off.

Rationale Behind Task Choices

The primary rationale behind our task choices was simply to think up tasks that would test the entirety of our applications functionality. We have been using various variations on these three tasks (with different scenarios) ever since our lo-fi prototype. When we did our lo-fi prototype, we only had three modes available (because Ambient wasn't do-able with lo-fi), so it made splitting the tasks up with each one corresponding to a different mode fairly simple. With our final prototype, we fully implemented Ambient mode, so we added that to our difficult task (because user's complained our tasks were too easy, and we wanted to test it's functionality).

Task 1: With Blinking Mode, we envisioned people just quickly turning it on when trying to get attention either in a crowd, on a bike, or on the side of the road. We choose this for the easy task because it only required one of the d-pad buttons, slowly acquainting the user with our interface. It also provided somewhat of a 'wow'-factor to get the user excited about our application.

Task 2: Flashlight Mode is the original idea that this application was designed around. We expect it to be the most frequently used mode. We choose this as our medium task because it utilizes all 5 d-pad buttons change color, brightness, and turn the backlight on/off.

Task 3: Alarm Mode is mode different from all the modes in our application, which is why we initially choose it for our hard task. However, much to our surprise, in our pilot studies, we actually found it to be one of the fastest tasks to be completed (i.e. it was pretty easy, although it did help that users had learned the interface a little by doing tasks 1 & 2), so we added in Ambient mode as well to make the task harder and test Ambient mode's functionality.

Design Evolution

Menus

Lo-Fi Prototype
Lo-Fi Prototype
Interactive Prototype
Interactive Prototype
Final Prototype
Final Prototype
  • Lo-Fi => Interactive:

Our Lo-Fi users did not expect the ambient icon to be an image of a lava lamp. Interactive prototype reflected user expectations for the ambient icon by using an image of "distorted colors".

  • Interactive => Final:

Comments by users about losing night vision when viewing an application with a white background, led to a reversal of colors. The background became black and the text color was changed to white with yellow highlights. The menus allow using left/right buttons for navigation in which the right button would select an item on the menu and the left button would go back in the menu to indicate progression in the menus.

Flashlight

Lo-Fi Prototype
Lo-Fi Prototype
Interactive Prototype
Interactive Prototype
Final Prototype
Final Prototype
  • Lo-Fi => Interactive:

A number of observations were made during the lo-fi testing of the Flashlight Mode. The first was the users tended to try and use the "Sound Up/Down" keys on the side of the phone to adjust screen brightness. This was not a feature that we planned on implementing, since no other such right and left buttons exist on the side of the phone for color adjustment (which breaks our d-pad mapping). So what we decided to do was move the brightness slider to the bottom instead of right border. The reason for this is that most laptop color sliders are shown horizontally. We also decided to move the color slider to the left border to remove the association that the "Sound Up/Down" keys on the right edge of the phone control the slider on the right border.

During lo-fi testing we also noticed that some users had difficulty telling the difference between colors on the color slider. To make things more coherent, we ordered the colors from top to bottom according to white plus the color spectrum (ROYGBIV - red, orange, yellow, green, blue, indigo, violent).

Since lo-fi testers seemed to have a problem determining what happened when they pressed the center d-pad button (turns flashlight on or off), we decided to give a small pop-up dialog that tells the user whether the flashlight is on or off.

Keeping with the theme of pop-up dialog, we also used pop-up dialogs to notify the user what the current percentage of the screen brightness is when they move the slider. This gives them a visual with the slider, but also a number to associate with the current state of the brightness.

  • Interactive => Final:

Most of the comments that we received about Flashlight during the Interactive Prototype presentation said that we brightness slider and center key we unintuitive. We worked to remedy the brightness slider problem in the Final Prototype by using a black/white color gradient for the brightness slider and that was what users are more familiar with and it also does a better job representing brightness. We also corrected the issue with the center key by adding an in-mode pop-up Help Menu (as was suggested by one of the Pilot Usability testers). This can be access by pressing the "Menu Key".

Blinking

Lo-Fi Prototype
Lo-Fi Prototype
Interactive Prototype
Interactive Prototype
Final Prototype
Final Prototype
  • Lo-Fi => Interactive:

Blinking mode experienced the same slider changes as Flashlight mode, including pop notification of brightness. The fillable speed notifier was replaced by a pop that indicated the current speed. Blinking mode was made to have a zero speed mode, as testing revealed it to be superfluous.

  • Interactive => Final:

The same slider change as was made in Flashlight mode was made in Blinking mode. A Help popup was also added, reached through the menu key.

Ambient

Lo-Fi Prototype
Lo-Fi Prototype
Interactive Prototype
Interactive Prototype
Final Prototype
Final Prototype
  • Lo-Fi => Interactive:

We decided to omit the ability to change color and brightness in ambient mode. User feedback suggested it was unnecessary, and would add extra complications and time to the process. Now ambient mode simply switches between preset animations. Ambient animations focus on changes in color and brightness of shapes that move about the screen.

  • Interactive => Final:

Two new animations were added, more in keeping with the spirit of Ambient mode (the idea of playing with light and color): shapes2 and randomShapes. All animations except Shapes were stripped out.

Alarm

Lo-Fi Prototype
Lo-Fi Prototype
Interactive Prototype
Interactive Prototype
Final Prototype
Final Prototype

Our alarm changed a lot over the course of this project. Although quantitatively, the most changes were made from the interactive prototype to the final prototype, we feel that the lo-fi testing was actually the most valuable in guiding the design of the alarm, because it really reshaped the direction we wanted the alarm to go in, as well as brought up a lot of questions we hadn't thought of yet. (Note: Figure's are in the Alarm Final Interface section)

  • Lo-Fi => Interactive:

Because our users ran into a lot of confusion regarding the 'Turn alarm ON/OFF' terminology during our lo-fi testing combined with the fact that none of our testers liked the idea of an alarm that starts on and turns off (which is the reverse of conventional alarms), we decided to scrap that functionality completely in the interactive prototype. We also didn't have any ability to turn the alarm off in the initial lo-fi prototype, or check what time the alarm was currently set for (or check if it was even set at all), so we added this basic functionality in the interactive prototype.

  • Interactive => Final:

Although our alarm was primitively working in our interactive prototype, we mainly added polish to it in our final prototype. Immediately visible additions are the alarm icon which comes up in the status bar to let you know if an alarm is set or not (a lot of users requested this in our interactive feedback, and most alarm's on modern cell phones have this useful feature) (Figure AL.5) and also the cleaning up of the interface (moving the time to the bottom to keep the interface consistent and immutable at all times), mainly due to the enlargement of the alarm time (a lot of people said the time was too small) (Figure AL.3). One thing that was not implemented was the creation of a dynamic interface (i.e. the interface would change based on whether the alarm was set or not, for example, the 'Turn Alarm off' doesn't need to be there when the alarm isn't set yet). Although we considered this, as well as got one comment about it, we decided against implementing it because we read earlier in the semester that you should try to avoid modes whenever possible (because it might add confusion). Instead, we opted for a middle of the road solution, whereby if you click 'Turn Alarm Off' when no alarm is set, it will now warn you that the alarm is already off. (Figure AL.1)

In addition to those visible changes, a lot was changed regarding the alarm's back end. First and foremost was that in our interactive prototype, the alarm didn't reset itself after going off (this was due to weird interactions with Android's IntentReceiver). This has been fixed in the final prototype. In addition, there were some minor bugs regarding various setting the time (the default time is now the alarm time if one is set, if not the current time) and using back button (we'd get weird null errors) that have now been fixed.

Help

Lo-Fi Prototype Option 1
Lo-Fi Prototype Option 1
Interactive Prototype
Interactive Prototype
Final Prototype
Final Prototype
Lo-Fi Prototype Option 2
Lo-Fi Prototype Option 2
  • Lo-Fi => Interactive:

Users were given two different designs for viewing help descriptions during lo-fi prototype testing. The first design consisted of a submenu that would lead to help descriptions for a particular mode. The second design had a single help description that would be used for all the different modes. All three users exhibited clear preference for the design with the submenu. The interactive prototype featured that design.

  • Interactive => Final:

Concerns about loss of night vision led to changing the submenu and help descriptions to have a black background with white text. Complaints by users about readability during user pilot studies led to change in the help description for a particular mode. Selection was disabled so users did not need to highlight a particular entry on the list of controls to read clearly. Instead, all the entries featured contrasting colors between text and background to be read clearly.

Final Interface

UI Design

Menus

  • Functionality

Upon starting the application, users can select any of the modes available in the application by use of a menu.

  • UI Design

User can easily navigate the menu by use of the direction pad and select button. Users can press up/down to move vertically along the menu. The center key allows users to select the desired mode. Left/Right navigation is also possible with right being select and left taking the user back to the previous menu screen. The icons representing each mode are viewable alongside the mode's name in the menu. The entry that the user is currently on will be highlighted with yellow text (Figure ME.1).

  • Implementation

Android did not provide any default lists with entries that had both images and texts. The solution was to make a new class for entries that had a view that encompassed both an ImageView and a TextView. A new class for lists that could hold such entries was written as well. Since we were not using Android supported features, it was difficult to learn how to highlight. This was done by changing the text color of the item at the position in the list where the user has selected using a Selection Listener.

(Figure ME.1) Display of the menu for the flashlight application. Flashlight mode is currently highlighted. If the user presses the select button, then he/she will enter flashlight mode
(Figure ME.1) Display of the menu for the flashlight application. Flashlight mode is currently highlighted. If the user presses the select button, then he/she will enter flashlight mode

Flashlight

  • Functionality

Flashlight Mode provides a constant source of light for the user. Users can change the light color, brightness, or turn the backlight on and off.

  • UI Design

To get to the flashlight, you must first select it from the main menu. It will then bring bring you immediately to a white flashlight at full brightness (Figure FL.1). From there, you can change the light color using up-down and the brightness using left and right (Figure FL.2). The backlight can also be turned on/off by pressing the center key (Figure FL.3). If users is confused about the key mappings, they can press the Menu Key to get an on screen help menu(Figure FL.4).

  • Implementation

Flashlight mode was done separately from Blinking. So while Blinking Mode was done using the Animation and setBackgroundColor(), Flashlight was created using by setting preset images as the background for the screen. A KeyDown listener finds out when up/down, left/right, center, or menu keys are pressed and then takes the appropriate actions. Among everything that was implemented in Flashlight Mode, creating the color slider was the hardest. We originally wanted a slider, then changed to separate boxes for clarity (since color is 3D: red, green, blue). We ended up using a modified GridView along the left edge as the slider, which allowed the current selected color to be outlined with an orange box. The bottom brightness slider is actually a ProgressBar widget with changing background. Backlight locking was accomplished by acquiring the PowerManager's WakeLock when Flashlight Mode is entered. Since we can't actually control the brightness of the backlight directly, we simulate it by changing the alpha level of the background. This works since the default background is black. All pop-ups were done using Toast.

(Fig FL.1) Initial Flashlight Mode screen.
(Fig FL.1) Initial Flashlight Mode screen.
(Fig FL.2) The color can be controlled by pressing up/down.  The brightness is controlled by pressing left/right.
(Fig FL.2) The color can be controlled by pressing up/down. The brightness is controlled by pressing left/right.
(Fig FL.3) The backlight can be turned on or off using the Center Key.
(Fig FL.3) The backlight can be turned on or off using the Center Key.
(Fig FL.4) Users can press the Menu Key to get a pop-up Help Menu
(Fig FL.4) Users can press the Menu Key to get a pop-up Help Menu

Blinking

  • Functionality

Blinking mode provides a blinking light to the user at any of three speeds. The light may be configured in the same way the Flashlight mode light may be configured

  • UI Design

To reach Blinking mode, the Blinking mode must be selected from the main screen of the Flashlight application. You are brought to a white screen blinking at the lowest speed, and greeted with a notification that tells you as much (FigBL.1). The middle button cycles the blinking speed between the three options. The color and brightness configuration of the screen behaves exactly that of Flashlight mode (FigBL.2). Pressing the menu key will bring up a help notification with a list of commands (FigBL.3)

  • Implementation

Blinking mode uses the same slider code as Flashlight, but uses an animated ImageView as its background, with the setBackgroundColor() method being used to change the background color. A KeyDown listener finds out when up/down, left/right, center, or menu keys are pressed and then takes the appropriate actions. Popups were accomplished with Toast. The most difficult part of blinking to implement was the blinking, with various schemes being used before finally finding an elegant solution through the use of an animation.

(FigBL.1) The initial screen
(FigBL.1) The initial screen
(FigBL.2) Color and brightness config
(FigBL.2) Color and brightness config
(FigBL.3) Help menu
(FigBL.3) Help menu

Ambient

  • Functionality

Ambient mode allows you to cycle between a number of animations that play with light and color.

  • UI Design

To get to Ambient mode, you select it at the main menu of the Flashlight application. You are greeted with the first animation, Shapes, and a pop up that tells you as much (FigAM.1). The center button on the directional pad is used to change between the different animations (FigAM.2, 3).

  • Implementation

Each of the animations was implemented using four ImageViews arranged at different positions on the screen as well as a combination of AlphaAnimation, RotateAnimation, TranslationAnimation, ScaleAnimation, and AnimationSet. A KeyDown listener finds out when center is pressed and then changes the animation. Popups implemented with Toast. The most difficult part of the implementation was developing animations that were enjoyable to view. This was because it required a great deal of experimentation and exploration.


(FigAM.1) The initial animation
(FigAM.1) The initial animation
(FigAM.2) The second animation
(FigAM.2) The second animation
(FigAM.3) The third animation
(FigAM.3) The third animation

Alarm

  • Functionality

Using the alarm you can set a silent, visual, blinking alarm anytime between now and 24 hours in the future. When the alarm goes off, your phone will begin begin to blink (Figure AL.6). You can also of course turn the alarm off or check when it's set for.

  • UI Design

To set an alarm, you first go open the alarm activity via the Flashlight main menu. Then, after clicking on 'Set Alarm', you can set the time to go off by either using the directional buttons (left-right to change which field to change, up-down to change it), or by using the keypad directly (using the numbers to fill in the time from left to right, and then using 'a' or 'p' to set AM or PM respectively) (Figure AL.3). Upon setting the alarm, the time you set the alarm for will prominently appear (Figure AL.3) and a notification icon will persistently appear in the top left corner of your screen until the alarm goes off (Figure AL.5). You can, of course, turn the alarm off by pressing the 'Turn Off' button if you want to (Figure AL.4).

  • Implementation

Alarm was primarily based off a number of demos in Android's APIDemos. The time selection was based off of Android's TimePicker. The alarm icon was based off of Android's StatusNotification. The actual alarm going off was based on Android's OneShotAlarm. The most difficult thing to implement was probably dealing with the alarm after it had gone off. This entails both going to blinking mode as well as resetting the alarm. Although these seem trivial in nature, they were actually quite difficult due to the nature of Android's IntentReceiver class (the class which Android bases it's OneShotAlarm off of), which is highly restrictive in the things you are able to do within it. In retrospect, if we had instead just used Java's Timer class from the beginning for the alarm (we actually did end up using in the end, due to IntentReceiver's limitations), implementing alarm would have been a lot easier (and cleaner!).

(Fig AL.1) Instead of creating separate visual modes based on whether the alarm was set, we instead opted to display different messages to inform the user of what was going on based on whether the alarm was set or not.
(Fig AL.1) Instead of creating separate visual modes based on whether the alarm was set, we instead opted to display different messages to inform the user of what was going on based on whether the alarm was set or not.
(Fig AL.2) You can set the alarm by using either the directional pad or, for more advanced users, the keypad.
(Fig AL.2) You can set the alarm by using either the directional pad or, for more advanced users, the keypad.
(Fig AL.3) When the alarm is set, an icon appears in the top left corner letting you know the alarm is set, and the alarm time appears in prominent fashion.
(Fig AL.3) When the alarm is set, an icon appears in the top left corner letting you know the alarm is set, and the alarm time appears in prominent fashion.
(Fig AL.4) If you decide you don't want your alarm to be set, you can simply turn it off
(Fig AL.4) If you decide you don't want your alarm to be set, you can simply turn it off
(Fig AL.5) No matter if you're surfing the web or checking your contacts, the alarm icon will remind you your alarm is set. (Of course, the alarm will also trigger from anywhere)
(Fig AL.5) No matter if you're surfing the web or checking your contacts, the alarm icon will remind you your alarm is set. (Of course, the alarm will also trigger from anywhere)
(Fig AL.6) When the alarm goes off, your phone will begin to silently blink to grab your attention.
(Fig AL.6) When the alarm goes off, your phone will begin to silently blink to grab your attention.

Help

  • Functionality

Users that are unsure of how to use the other modes can reference the help section for assistance. A description of the controls for each mode is given.

  • UI Design

Help starts with a menu where the user will need to choose which mode they wish to read the help description for (Figure HE.1). The icons representing each mode will be viewable in the help menu. User can easily navigate the menu and help descriptions by use of the direction pad and select button. The help description for each mode displays the identifiers for the mode as well as images of the input keys paired with the functionality assigned to them (Figure HE.2).

  • Implementation

The submenu for selecting help descriptions of a particular mode were the same as that used for the main menu to select modes of the flashlight application. Thus, the same classes were used to create lists that had both text and images for each entry. To improve visibility for users, help description text color contrasted background color without the user selecting a particular on the list. We also disabled the user's ability to select items in the list for the help descriptions. Help faced the same difficulties as the Menus since they are both based on the same code.

(Figure HE.1) Help starts with this submenu. You can select any of the modes to view the help description.
(Figure HE.1) Help starts with this submenu. You can select any of the modes to view the help description.
(Figure HE.2) Help description for flashlight mode. Directional buttons are mapped to their effect in the mode of the application
(Figure HE.2) Help description for flashlight mode. Directional buttons are mapped to their effect in the mode of the application

Unimplemented Features

Flashlight

We initially were planning on having the sliders fade away after a certain duration. Due to the quickness of the users during the Lo-Fi Prototyping, this was not really tested. We also found it difficult to make this happen in the Interactive Prototype. Since the sliders aren't as obtrusive as they were initially designed in the Lo-Fi Prototype, it might be acceptable to leave them in. Further user studies are required to find the best solution.

Blinking

All unimplemented features in Blinking correspond to the unimplemented features in Flashlight Mode.

Ambient

Initially we were hoping for more complexity regarding the animations in Ambient mode, but that proved difficult to accomplish within the allotted time. Smoother animations with color-changing and gradient effects were desired.

Alarm

  • Currently, there still may be some issues with alarm uncharacteristically misfiring sometimes. What will happen is very rarely sometimes when the alarm goes off, it will go to a black screen instead of the blinking screen (it's fine after you press any button though). We tried to troubleshoot this issue but it came up fairly rarely and un-deterministically, so we're not sure exactly what is the problem.
  • Additionally one person asked to be able to set the brightness / color of the alarm beforehand. This would probably be implemented via another button in the alarm menu, but it may force us to use modes because we no longer have enough space to display all the buttons + time on the same screen, something we don't really want to do (because we want out application to be as simple as possible).
  • Some people asked for noise in addition to light, but we're not really sure if we want to add this feature, because the whole point is our application deals with light (and noise alarms will be commonplace in the other alarm applications). It is, however, something to consider.
  • Finally, there is a very weird bug whereby if the alarm goes off from within the alarm activity, and you press back, Android will only reset half of the text (this is very strange, since both textViews are set simultaneously and reset simultaneously). I believe this is a bug with Android, because the very simple code logic is done in a simple transaction (i.e. if one thing is reset, the other should be guaranteed to reset as well, but it's not happening).


Life Cycle

The Life Cycle functions of the application were not thoroughly implemented. There is a very slight functionality difference if the Android settings were changed so that activities are destroyed immediately. This difference mainly comes from the main menu moving scrolling up when the user enters "Help" or "Alarm". This does not decrease the functionality of the application, although it could potentially bother a user slightly. With more time, these issues could have been resolved.

Wizard of Oz

No Wizard of Oz techniques were used in this prototype.



[add comment]
Personal tools