User experience redesign of
EvilAlarm
- a mobile alarm clock with a twist
Olli Savolainen, June-July 2011 / Return to software at pilpi.net
I designed a UI for a simplified, quick-to-use alarm clock for the Nokia N900 and possibly for future MeeGo devices. Together with EvilAlarm's original author Christian Pulvermacher, we integrated the new UI into EvilAlarm, a clock app designed to make sure you wake up when you need to.
EvilAlarm is currently available in the N900 extras-devel repository (instructions for enabling the repository).
Challenges:
- Establish communication channels, organize version control
- Use case prioritization, streamlining "red routes" (key workflows)
- Easy discoverability of main features; distinction between simple configuration while carrying out a task (select alarm type while creating an alarm) and persisting user preferences
- Screen design: de-emphasize other than red route features
As an interaction designer, this project meant moving from pure usability engineering to more holistic user experience design. Here a bit of immersiveness, by means of aesthetics and animation add value to the emotional side of the experience.
Also — while they say Meego might not survive the smartphone/tablet platform wars, I thought Qt Quick, a declarative, somewhat XML-like UI specification language an interesting concept and wanted to learn it.
GitHub repository for EvilAlarm
Project birth
This was a hobby project grown out of honest personal frustration: there seemed to be no proper alarm clock for the Nokia N900. Prototyping with Qt Quick/QML is, well, quick, so I tested the real thing early and pretty often, too. I created no original graphics; everything is originally a Creative Commons licensed photo/image, edited by me to suit the UI. When I was getting content with the UI design, I started realizing that the actual alarm functionality, playing with the APIs, is not something I want to put much of my time and effort in.
I had earlier tried Christian Pulvermacher's EvilAlarm. It gets its name from making sure users get up when they are supposed to, exactly at the moment they reeeally really do not want to. It makes you play a simple game (integrating another open source project, Blubbels) to keep the alarm quiet, or alternatively you have to shake your phone for a couple of minutes so you are definitely awake when the thing finally stops harassing your dreams. So it was a design appealing strongly to basic human nature, and I liked that.
The user experience of EvilAlarm was confused, and did not adhere to various basic usability heuristics. So I ended up contacting the EvilAlarm developer. He seemed to like the idea of merging my UI with his app. In all his messaging Christian was very polite and friendly, and it seemed to me that we got along well.
Design goals and choices
The goal of the new UI is to streamline the basic workflow of setting an alarm, while making the experience aesthetic and aligned with the "evil" theme of the app. Also, the "killer feature" of EvilAlarm, really waking you up when you are supposed to, needed to become more prominent in the UI. On the other hand, as the app's behaviour can be seen offensive if it comes as a surprise — making your phone something that can not be instantly made quiet, except by throwing it out the window (or, if you feel patient, by taking out the battery).
Presenting the main feature: evil alarms
The decision was made to add a "normal" alarm mode to EvilAlarm. This may seem in conflict with the goal of making the "evil" features more prominent. However, there are contexts where one does not want the alarm to be "evil", for example a public place where you want to wake up yourself and then make the alarm quiet as soon as possible, to not disturb others. The user should not need to think which app they start up every time they want to set up an alarm. One alarm clock should serve all basic alarm clock needs.
Also, as the "evil" alarm functionality can be perceived offensive, it should not be possible for it to come as a surprise to the user. Having a normal mode by default but a prominent alarm type selection in the UI makes it easy to try the more interesting functionality out at will. Functionality for testing how the alarm will look like, while still being able to close it at will, already existed in EvilAlarm.
Previous alarms
I hesitated adding an alarm history/previous alarms list to the alarm configuration screen, since it seemed that there was already too much stuff in the alarm configuration screen, and this might distract users (remember, this is a mobile small screen UI). This was before I had integrated even the alarm type selection into the UI. But then I started playing with a bottom bar, which is standard in other N900 apps too.I came into the conclusion that alarm history is another core feature of EvilAlarm - if it were hidden in the menu, some users might think it's not there and thus the app does not fit their needs. Usability testing seemed to indicate that the bottom bar was not distracting enough to disturb the main task of setting a simple alarm.
Usability testing
Informal usability testing was carried out on EvilAlarm in various phases of the project. A particular challenge was that the paper corner seemed to afford swiping in some users' minds, which was fair enough, but implementing swipe was not as trivial as expected in Qt Quick.
Another issue discovered in the testing was that in the alarm config screen, the UI automatically switched the alarm slider on when the user changed the alarm. Many users didn't notice this automatic change. As their original recollection was of the alarm being off, and they had not done anything to change it, they assumed that they still needed to turn the slider - even if it was from "ON" to "OFF". So the automatic switching was removed.
Research
This was more of a personal hobby project, so no formal user research was conducted. Being excited about the project did lead me to talk to friends about the experience though, and that sparked some ideas along the way.
Still, it is sad that I had no resources for further discovery. There would surely be a lot to learn about what users are really interested in in an alarm clock.
I've seen the Android default alarm clock and thought it was rather complex, though it nicely mapped different time-related functionality (alarm, world clock, timer, countdown) into a single app. It was also surprising how easy it is to set alarm on a traditional Nokia mobile phone - this touch UI is still quite a bit more hassle than a keyboard-based UI. A simple numeric keyboard fits setting an alarm surprisingly well. It would be great to continue comparative research, too.
