2 Minute Promo Presentation

For Microsoft Powerpoint

Back to Top

Problem Statement

Based off of potential user responses, the Chronos Multipurpose Alarm Clock needs to be very intuitive when allowing users to input calendar and alarm times/settings. The advent of programmable menus may not be the most useful feature of the clock, so all reasonable uses should be accounted for in the firmware development. Because of current cell phone capabilities, the Chronos Multipurpose Alarm Clock needs to be more focused on the input/output methods and calendar/alarm settings and usability. The touch screen, wallpaper, and mp3 features are well-liked and useful features of the Multipurpose Alarm Clock and will be carried out on the final design of the clock.

Back to Top

User Group

In deciding the target audience of our project we considered those who have hectic lives and could use a multifunction alarm clock to help them manage their tasks. As a result, we came up with two distinct representative users: a student and a worker.

Students: Students need to manage their school work as well as their personal lives. They need to track homework due dates as well as birthdays. Students have a unique problem in that their daily schedule will vary based on class schedules. If they have a part-time job as well this will increase the variability in their schedule. Based on talking to students we felt they could use an alarm clock that could be personalized to their needs. Furthermore, many students would enjoy customizing options this product employs. While we are considering a wide range of ages for students, we do not recommend this product for those under 16. We determined this age range based on the technical aspects the product will employ as well as the lack of interest anyone under 16 would have towards this product.

Workers: Workers have their own distinct needs. For them, they need to manage their work and personal lives. Work includes having business dinners, meetings, and deadlines. Personal would include birthdays, anniversaries, and parties. This multipurpose alarm clock could be used to help them organize all these tasks in a handy solution. These users may also enjoy the MP3 and photo options to customize their product.

Back to Top

Tasks

User Task Matrix
Task Student User Worker User
Set up Alarms
Frequently Frequently
Add Appointments to Calendar
Frequently Frequently
Set Up To-Do List
Sometimes Sometimes
Customize Alarms
Frequently Sometimes
Customize GUI (Make Photo as Wallpaper)
Sometimes Sometimes
Add MP3s
Frequently Sometimes
Add Photos
Sometimes Sometimes
Play MP3s/Radio
Frequently Sometimes
View Photos
Sometimes Sometimes

Back to Top

Design Concepts

When we thought about what types of tasks we wanted to cover in our design, we thought of two different conceptual ideas. The concept ideas were based off of objects we interact with in the real world, such as cell phones and alarm clocks. They all incorporated the options into something we were thinking of in a real world sense. We decided that the interface was most like that of an alarm clock, with many different features that would make it into a life management system and digital media hub.

We were definitely influenced by the decision for it to be a tangible device. We considered the idea of it simply being software on a computer, but when we ended up thinking of it as a device with buttons, the ideas shifted because of how one has to interact with the buttons themselves. Then, the concept of a user touchable system came into play, and our ideas for the layout and hierarchy to lead the interaction followed.

Back to Top

Key Features of Hi-Fi Prototype

Click here for the Hi-Fi Prototype (Opens in a New Window)

  • Create an alarm that is for 9:00am, Mon-Fri, and starts on 12/4/06. Set the alarm to use a MP3: ymca.mp3
    -optional: Change your mind and delete the alarm when you're done.
  • Add the event "Winter Recess" on 12/23 to your calendar.
  • Add to your To-Do List the item "HCI Paper".
  • Listen to all your MP3s.
  • Look at photos Jeremy and Maria took and then view the slideshow you previously made.
  • Change the skin to "Flame".
    -optional: And then you can change it back to "Water" when you get tired of it.

Back to Top

Lessons Learned from Prototyping

Through the creation of two different prototypes, we learned a great deal about how one uses and corrects their designs. The iterative process helps you to understand how different designs have flaws and advantages. After making the two different prototypes, it is evident that there is no way to know that your design is perfect unless you build it and test it.

We learned that there are advantages to low-fi and hi-fi prototyping. The low-fi prototype does a good job at showing the general organization of the system, and allowing the testers to interact with a simple interface. The interface is utilized so that corrections can be quickly made, without having to reprogram the whole system or rebuild the entire project. At the same time, its easier to make sure that there aren’t any problems with the design at this point. We could have ended up finding problems after doing much more effort. You can easily go through many low-fi prototypes because they are not complicated or costly, yet give a good idea of how the system may interact with the user. We discovered that we could use power-point to make the prototype, which was not very difficult and easily changeable. Testing could then be used to discover problems with mapping, and making sure that feedback was accurate.

The hi-fi prototype introduces a higher branch of interaction. At this point, the feedback is more real, and the tester can have a better idea of what to expect. We used a different type of prototyping medium, which was web based. This allowed a little more interaction, but took more time to finish. The hi-fi prototyping taught us about the way we can use the web to emulate a real product. This was one of the biggest ideas we acquired. We can use different programs to emulate the system for testing. Then, changes can be made before we do too much programming or creation of an actual system.

Back to Top

Evaluation of Prototypes

For Chronos, we had two cognitive walkthroughs for our low-fidelity prototype, whereas our high-fidelity prototype merited three heuristic evaluations. Our cognitive walkthroughs were evaluated by two of our group members. Classmates used the heuristic evaluation to critically judge our high fidelity prototype. Even though the cognitive walkthroughs were viewed from a critical point-of-view, they were done with only a low-fidelity prototype. This first version was still in development, and although ours was still highly functional, there were a few bugs that created enough room for improvement. Since this was simply a walkthrough, we summarized findings for each task into three questions. In addition, as with anything done within a group, our responses were biased in support of our own cause.

Results from our classmates who knew very little about our project before they evaluated the more completed high-fidelity prototype provided a better understanding for us to see what other things we could improve upon for future development. Results from one heuristic evaluation applauded our general interface, but the user wanted to see more windows. This is a valid point, since the user is assumed to be able to navigate throughout various windows in a very short amount of time with either their stylus or finger. Also, some of the viewing areas may seem cluttered. These two concepts go hand-in-hand. Multiple windows may cut the time a user stays on one view. Another user proclaimed that adding MP3s and personal photographs to the device was highly innovative, but there was potential for error. A third classmate knew exactly that it was an alarm clock (which is great when the user recognizes the device) and thought the device to be highly functional for a prototype.

All users said the design was consistent and made it apparent for what actions could be performed. They would, however, like to see these actions digested into an easier viewing method (ie - one window per action). Also, these users claim it was easy to make errors and agreed on having a help option available for the less technical savvy.

Link to Cognitive Walkthrough 1
Link to Cognitive Walkthrough 2

Link to Heuristic Evaluation 1
Link to Heuristic Evaluation 2
Link to heuristic Evaluation 3

Back to Top

Lessons Learned from Evaluations

First and foremost, we learned to include a help guide on the project directly. Although one evaluator remarked about following through our online guide, some people may not have access to a computer while using our device. This feature should be focused on if a situation that called upon this resource was to occur. Chronos was designed to have a touch-screen interface. A couple of our evaluators wanted to see more interactivity with the screens and have multiple screens to come up as they perform a task, much like in a Personal Digital Assistant. One person even went to say our interface was clean, but became cluttered when entering certain areas, such as Adding Photos. We could argue that the multiple screens would demand more memory from the device and slow down the processes. In addition, the user would need to continuously press a Back button, if one existed, to edit information presented earlier. In our prototype, most of the tasks were laid out in one window. This design was easier toimplement, but changing to what evaluators suggested may prove to make this device more popular, especially for our targeted audience of students and tech-savvy business people.

Back to Top

Further Redesign Ideas

Overall, our group is very satisfied with the final hi-fi prototype of the Chronos multipurpose alarm clock. Keeping the functionality and general design in mind, there are only a few improvements that were thought of during the heuristic walkthroughs. The first minor issue had to do with information about the clock. Nowhere did we label the capacity of MP3s, photos, and/or state the file storage size in megabytes.

Also regarding information is a lack of directions, however; for the prototype this was not really that necessary to provide. Note, a final product would have included a manual. One heuristic walkthrough evaluator noted that our product only works in English, Japanese, and Spanish, however; our product was only planned for sale in the US and Japan.

One feature that was incorporated on one of the lo-fi prototypes was the ability to switch between functions (such as to-do list and photos) without going back to the home screen. This feature did not make it to the final hi-fi prototype, but probably could have been integrated. It was excluded from the final hi-fi prototype because each director (arrow, icon, or whatnot) would need to be labeled and it would have to either flow through the features in a set order or list each icon on every screen on the Chronos. If these icons could be used successfully on the touch-screen, they may be thought of as a potential improvement for the device. Also, one heuristic walkthrough evaluator noted that most cell phones, computers, and other devices with alarm features usually display an icon of a bell or alarm when an alarm is set. This is not used on Chronos and would be a good upgrade to the device.

The overall usability as per the walkthrough personnel was highly talked about, so future improvements to the device should not interfere with its great usability and visual appeal.

Back to Top

Navigation

Main Page

Proposal

User Needs & Task Analysis

Prototypes & Evaluation I

Revised Prototypes

Final Report

Information

Chronos Alarm Clock Project was created by Group 6 in Professor Jacek Gwizdka's Fall 2006 HCI Class.

Group 6 Members:
Peter Holt
Maria Musillo
Jeremy Pharo
Anisah Syed

This page was last updated on Wednesday, December 13, 2006