FinalPrototype-Group:Team Freaking Amazing

From Cs160-sp08

Jump to: navigation, search


Team Members

Jessica Fitzgerald: problem, target users, tasks, final interface, some coding, powerpoint

Daniel Gallagher: design evolution

Andry Jong: final interface, implementing Mini Application

Mike Ross: final interface, implementation, implementing MiniApps framework, incorporating MiniApps developed separately, reworking and polishing interfaces to address user comments.


The problem we would like to address is that most alarm systems today are too basic to include all the functionality users need and want. Many alarm systems do not allow you to set exactly which days of the week you want alarms to go off, but instead force you to set an alarm to recur either daily or on weekdays. Our project aims to update the interface of an alarm clock to make it more user friendly by allowing you to choose exactly which days of the week you want your alarm to go off. We also include a timer that you can set off in a certain number of minutes or hours to remind you of laundry or something you put in the oven, or of someplace you need to be. Along with designing a clear and easy-to-use mobile alarm interface with the complexity hidden from casual users, our alarm will allow users to attach mini-applications that deliver information like weather and reminders when their alarm goes off.

Target User Group

Our application appeals to a wide variety of users, because almost everyone will use some sort of alarm to wake up in the morning. Specifically we wanted to focus on the needs of young people either in school or in the workplace with busy schedules who use their mobile phones frequently. These are people who do not have a lot of time in the morning, and are often rushing out the door. A person that fits this category may want to know the weather report as soon as they wake up so they can dress appropriately for the day without having to fumble around on their computer or the television. The ToDo List feature will remind them first thing of any important things they need to remember as they rush out the door. Our application aims to help people with busy schedules function more efficiently through our user friendly interface.


The following tasks are meant to provide a good idea of how our interface works and what it is capable of.

Task 1

(Easy) : Make a nap timer and set it to go off in 1 minute

  • The user will need to create a new timer, with no mini applications that will go off in 1 minute
  • This is a very easy task and we expect users to have no problem with this one at all
  • We consider the timer to be an important part of our interface, so it gives a sense of how easily users can maneuver a basic part of our interface

Task 2

(Medium) : Create a Wakeup alarm and add the weather mini application to it, view weather when the alarm goes off.

  • The user will create a new alarm, and fill in information to set the Alarm off at a certain time. They will also add a weather mini application that they will be able to look at when the alarm goes off
  • In this task, the user is expected to know how to set a basic alarm as well as to add a mini-application to it, which is a little more difficult. The mini applications are the heart of our interface so it is essential to have them as part of a task.

Task 3

(Hard) : Set an alarm named Car Alarm recurring Monday and Wednesday with ToDo List (go to class and wash car).

  • The user will need to create another new alarm. They will also need to be able to create lists in the ToDo List application. They must also be able to set a recurring alarm with a custom recurrence.
  • This task is important because it includes the recurring option which makes our interface more customizable and user friendly.
  • It also gives the user practice with adding entries to the ToDO list, and it gives them more practice with adding mini-apps to alarms.


The UI for AlarmBuddy changed in relatively minor, yet important ways over the course of the project. The evolution of our design can be separated into several stages:

  • Initial Design sketches
  • Low-fi prototype
  • Initial Interactive prototype
  • Final prototypeo

These correspond to projects from the class, as we went through the most design revisions prior to and after completing the writeups for the various assignments.


The initial design sketches included a variety of elements that were not implemented in the final version for a variety of reasons, as well as excluded some features we ended up adding later.

Changes from inital design sketches to Low-fi prototype:


  • Timers! We did not consider timers seriously until just before the low-fi prototype was made; they emerged in a very primitive form as being identical to alarms in all ways except recurrence.


  • Some of the artsy effects of the initial sketches were removed, including some icons and such for clarity.

Initial Designs, Storyboards

Image:alarmbuddything1.jpg Image:alarmbuddything2.jpg

Low-Fi Prototype


Changes from Low-fi prototype to interactive prototype:


  • The ‘Add Mini Apps’ interaction was changed: when the user selects the “Add Mini Apps” section in the Edit Alarms screen a new menu full of usable mini apps will appear, each of which has its own settings. This replaced the old method of selecting mini applications directly from the Edit Alarm screens and was done as a result of user difficulties in identifying that “Add Mini Apps” would take them to a different screen and that there were more options available.
  • Confirm/Cancel buttons were added across the board based on user requests for them, and confusion with the Android idea of using BACK and persistent state to work with their data. By the time we made our final prototype all screens had confirm/cancel buttons, as well as working with back button usage as a form of cancellation.


  • Icons on main screen for “create new alarm” and “create new timer”: We figured that utilizing Android’s context menu was more applicable to this since with any number of alarms the create new ___ button will be lost off the screen and force scrolling, nor was it intuitive to have to scroll through all alarm icons in order to create a new one rather than just opening up a menu.
  • For the interactive prototype the graphics and imagery we invented were removed due to time constraints in coding the interactive prototype and struggles with programming the Android API
  • Wizard-of-oz functionality included due to time constraints, for example the weather mini application did not actually query a weather database but used a static image downloaded from the internet. Alarms go off instantly.

Interactive Prototype: Image:alarmbuddything4.jpg

Changes from interactive prototype to final prototype:


  • The custom recurrence screen was added. This menu is accessible from the “Edit Alarms” screen when the user selects “custom” from the recurrence slider. A popup screen will appear, rather than a new activity as we had originally planned in our initial design sketches because we identified the only important information for the user to see was the days of the week available to select and a confirm/cancel button- the rest was extra and would clutter up a simple menu.
  • The wizard-of-oz functionality for the weather mini application was replaced with working weather lookup code
  • The back end for storing alarms and mini application data was improved, for example, alarm information is stored rather than just title.
  • The alarm actually goes off on time; wizard-of-oz instant alarm setoff removed and actual code added so alarm goes off at time set.
  • Interface shown when alarm goes off improved in layout and coding from low-quality prototype version


  • No functionality was removed for the final prototype

Final Interface

Functionality and User Interface Design

My Alarm Screen

Our original idea was to have two buttons - each for Create Alarm and Create Timer - which looks exactly the same as the existing alarms and timers buttons all the time, to make it easier for the users to create new alarm/timer. However, it takes a lot of space on the screen that users can only see a couple of alarms/timers that they have created. Hence, we decided to put our Create Alarm and Create Timer functions in the Menu.

However, even that, leave us with a problem of having the My Alarm screen to be totally empty as it starts for the first time; and users tend to wait for something to appear before they start navigating through the application. The solution we decided is to make Create Alarm and Create Timer to be a different buttons from any other alarm/timer, which also leaves more space for the users to still be able to see their alarms and timers.


Edit Alarm and Edit timer

When user create a new alarm they will be directed to the Edit Alarm screem. Here, users can suppy Title of the alarm, the time when the alarm should turn off, the recurrence sequence (between daily, none recurring, or custom recurring where users are supposed to be able to specify their own recurring schedule based on days of the week), the tone used as the alarm turns off, and finally, users can also insert mini applications that will come after the alarm turns off.

Very similarly to Edit Alarm screen, the only thing that is different with Edit timer will be that there is no recurrence option in this screen and that the time is based on the number of hours and minutes that the user wants it to turn off starting from when the timer is activated.

Image:EditAlarm.jpg Image:EditTimer.jpg

Alarm v.s. Timer

One of the problems we had with our interface before was how to make a difference between the Alarms and Timers from My Alarms screen. We decided a simple solution for this: Colorings. In our final interface, we decided that our Alarms should be colored in blue while Timer are green. We realize that the impact of giving different colors for alarms and timers does not only make it easier for the user to make a difference between alarms and timers, but also provide a good aesthetic feature to our application.


Active v.s. Inactive

Another problem related to My Alarms screen was how to make a difference between active and inactive alarms/timers. A quick fix to this is again to assign different colors to applications when they are active or inactive. In our final interface, the ones that are lit up are active, and the ones that are not lit up are inactive.

We did not stop there, we also include the status of each alarm/timer to show that it is running (especially for timer). This implementation provides more than just good feedback to users telling them whether the alarms/timers are active or inactive, but also telling users some details of the timer so that users would not have to go to each alarm/timer to be able to review it


Interface Consistency

Some of the users were concerned about how our Confirm and Cancel buttons in some Edit screens are in different positions as the others (sometimes Confirm is on the left side, other times on the right). In our final interface, it should be all on the same position throughout the whole interface: Edit Alarm, Edit timer, Add Mini Apps, Edit ToDo and Edit Weather

Image:EditAlarm.jpg Image:EditTimer.jpg


Image:Note.jpg Image:weatherr.jpg

Alarm Stop

As our motivation in creating this application is to provide great user experience in using mobile phone's alarm application, we want to be able to provide our users with options of which application they would like to view first. Although we only have three applications implemented so far, we want this to be a good basis for future reference. Hence, we decided to show icons for the available (activated) mini apps for users to choose as they turn of their alarms. This way, users have more independence of what they would like to view first thing as they wake up.

Image:snoozestop.jpg Image:Off.jpg

Mini Application: ToDo List

As the users enter the ToDo list mini application they will see a full list of any reminders that they have created. If user decided to create new ToDo entry, they will be brought to another screen where they can edit the ToDo entry and title. This mini application is very similar to the Notepad Tutorial that we all went through when we just got introduced to Android. There is not much change in interface design in this application except for the Confirm and Cancel buttons that we would like to keep consistent throughout our application.

Image:Note.jpg Image:AddNote.jpg

Mini Application: Weather

In the last prototype of our interface, we decided to use an image as a representation of our forcast data. Since the last time we present our interface, it now goes to Google weather's database and grab the weather forcast information based on the zip code entered by user. The data shown in our Weather mini application includes the days of the forecast, the maximum and minimum temperature that a perticular day would reach measured in degree Ferenheit. Now our users will be able to input any zip code althrough the United States and get their weather forcast information as soon as they open their eyes in the morning.

As users enter the Edit Weather screen they would have to provide a five digit zip code before they can see a preview of the weather forcast that they are going to see as the alarm goes off. Again, we keep the consistency of our interface as a whole using Confirm and Cancel buttons at the same position each time.

Image:weatherr2.jpg Image:weatherr.jpg


General Overview

The application is designed two main objects: alarms and miniApps. We can consider alarms and timers to be roughly the same thing because in the actual implementation, the only things separating them are a few database columns and conditional branches. Each alarm has a list of standard info including a name, time to activate, ringtone, and recurrence pattern. These get set in separate but nearly identical EditAlarm and EditTimer activities. The more interesting aspects happen once the MiniApps come into play.

MiniApps are android activities that inherit a MiniAppActivity class. The idea is that we only need a few standard things out of any given MiniApp: an icon, a unique String identifier, and a way of retrieving specific saved states of the miniApp, should it choose to utilize such functionality. Our class MiniAppActivity provides this, and it's mostly trivial to supply any given activity with a wrapper class that allows us to incorporate it into AlarmBuddy.

Each alarm has a unique id associated with it, and MiniApps are given knowledge of those, so should they choose, they can save information specific to each instance of an alarm. This can be a good thing in the event of memos, but we realized that with applications like our weather application, that fine granularity might not make sense, so applications can also share state across all alarms as well. As MiniApps are for the most part arbitrary activities, they essentially have free reign over how they operate.

Unfortunately there are a few bottlenecks where you would need to edit the actual source code to install a MiniApp, for instance, when retrieving a class from a string, but we tried to minimize these so that transitioning to a fully extensible model could be easier, as there are ways to avoid hard coding.

As for data storage, databases drive the entire program. Alarms are kept in one database, MiniApp instances associated with alarms are kept in a separate database, and each MiniApp uses their own databases or internal mechanisms to save state.

When an alarm is enabled, it kicks off a service to run in the background until its activation time occurs. It then starts a series of activities which result in a prompt to snooze the alarm or stop it, and once stopping is selected, a list of any MiniApps the user configured for this alarm is displayed for him or her to view one at a time.

What was hard to implement?

Designing the MiniApps and passing the relevant information around all the various activities proved to be the most difficult. One of our initial goals was to insure that developing further MiniApps would require minimal effort. This required that we build a generic MiniApp framework. Being extremely new to both Android and database use in general, this took several tries in both design and implementation. However, as the last MiniApp took only half an hour to install from a completely separate project, complete with its own icon and saved state, I consider it at least a minor success. For full flexibility, we would have had to use a content provider, but one of the other groups warned us against getting involved with them. We also skimped on providing separate Activities for setting up MiniApps and viewing them once the alarm goes off. The framework is there, however, but we realized this would mean developing another activity for all of our miniApps, even if they were extremely similar, so we tried to work around it by providing all the necessary functionality for both configuring and using a Miniapp in a single activity per MiniApp.

This was the first foray into database use for most of our group, and we were a little shaky figuring out when information required a database and when it would have been overkill, in addition to how we would transfer it if we didn't use a database and multiple activities needed it. Learning Android's different protocols with all their caveats (icicle bundles vs. extras bundles) also took a long time. The documentation for Android is rather spotty in parts, and some things just plain break your program (e.g. time picker widgets can apparently corrupt the xml files they appear in).

Things Left Out

  • We didn't end up creating as many mini-applications as we initially wanted. We just ended up creating the weather and to do list applications. We wanted to have a browser application and possibly some others, but we decided to concentrate on other parts of the interface instead of adding more mini-applications.
  • Most of the Cancel button do not have any functionality as well as the the Snooze button. We decided that this was something that could wait while we paid more attention to the design and look of the actual interface.
  • Once a mini-app is added it cannot be deleted. This part was not in our tasks and we felt there was not yet a need for deleting a mini-app from a set alarm.
  • The alarms do not go off at the set time, instead they go off at a fixed time. The android support for this is limited because of the way the System Clock is implemented and how the Alarm class works.
  • There is no ring tone when the alarm goes off. The android support for this is also limited and we thought it wasn't completely necessary to add, because we wanted to spend more time on the interface.
  • Slight cosmetic tweaks here and there would be nice, for instance better colors for alarms and timers, consistent colors for the "Create Alarm" and "Create Timer" buttons, better font alignment in some places, but we decided to spend our time on the more glaring issues.

Wizard of Oz

  • The original Wizard of Oz Weather MiniApp has been included to add an additional MiniApp. It simply displays a presaved image instead of actually finding the weather, but the Weather 2.0 application actually goes out and finds correct weather for those interested.


[add comment]
Personal tools