Alarm clock design

The following is a design review and proposal for the Alarm Clock applet.

JohannesJensen: Note that technically Alarm Clock has moved from being a panel applet to living in the notification area with a status icon.

Design review

  • Left clicking on the applet produces no response.

    • JohannesJensen: Left clicking the applet will in future versions snooze all triggered alarms. If there are no triggered alarms, left clicking on the icon will open the alarm list window .

      • AllanDay: left click should always open the alarm list window. It isn't obvious that it would have a snooze function.

  • Use of double-click to open the edit menu is non-standard and not easily discoverable.
  • Applet tooltip provides instructions for usage. This is non-standard and should be unnecessary. The tooltip should be simple and discriptive: 'Alarm clock'.

Right click menu

RMBMenu.png

  • The right-click menu offers no obvious way to add an alarm

    • JohannesJensen: Noted, I'll definitely add this.

      • AllanDay: actually, ignore this comment. ;) The right click menu doesn't need this.

  • Reliance on RMB to access the majority of the applet's functionality is inappropriate, since RMB lacks discoverablity.

    • JohannesJensen: Okay, so as long as the left click menu opens the alarm list window then this is improved, right?

  • What does 'Clear alarms' mean? It is not obvious.

    • JohannesJensen: It means stopping playing any ringing alarms. I've renamed this to "Stop alarms" in trunk.

  • Clear and snooze alarm options are not greyed out when no alarms are active/ringing

    • JohannesJensen: Good point, I'll fix this in the next version. Fixed in trunk.

'Alarms' dialog

Alarms.png

  • 'Add' should be 'Add...'; 'Edit' should be 'Edit...'
  • Purpose of the activate checkbox is not obvious. You would assume that a new alarm would be activated automatically.

    • JohannesJensen: New alarms will be activated automatically in the future. How can I make it more obvious?

      • AllanDay: I'm recommending removing the enable/disable alarm functionality.

'Edit alarm' dialog

EditAlarm.png

  • The dialog is too complex and contains too many elements.
  • The name of dialog is confusing - suggests that user is editing an existing alarm, rather than adding a new one (as will most often be the case)
  • Timer option is not advertised until this dialog. It should be more discoverable.

    • JohannesJensen: Would you suggest having two buttons instead? One for add alarm and one for add timer?

      • AllanDay: yes - see the design recommendations.

  • It isn't obvious that the time inputted for a timer is the time left. Could be renamed to length?
  • 'Label' - seems like a superficial name for this field. What about 'Name' or 'Title'?
  • Time picker boxes are too wide - they should be wide enough for two digits only.
  • Time picker boxes should contain two digits at all times. The default should be: '00:00:00'.
  • Colons are unnecessary in time picker
  • Should time pickers cycle one another? eg. Should moving minute down when on zero reduce the hour by one?

    • JohannesJensen: Good idea, although personally I never click those buttons... Maybe one set of spin buttons for hour / min / sec is not really needed?

      • AllanDay: I'm uncertain whether this is a good idea, since it could be confusing. Keeping it simple (with no cycling) might be best.

  • 'Trigger alarm' does not clearly describe this section. Why not 'Repeat'? This is standard terminology in calendar/alarm applications.
  • Snooze option - is it necessary to set this on a per alarm basis?

    • JohannesJensen: Nope, this is already a blueprint and in the progress of being fixed.

  • 'Notification' is an unusual term. What about 'Alert'?
  • Notification options expose too much implementation for novice users. Needs abstracting.
  • Delete confirmation box is non-standard for GNOME. Is it necessary for alarms? They're simple to reproduce...

Design recommendations

  • Don't provide the facility to edit alarms - just use add and delete. Alarm settings should be simple enough not to require editing.

    • JohannesJensen: Not sure I agree here - why shouldn't the user have the ability to edit an alarm? I agree that the settings should be simple, but I feel it's cumbersome having to delete an alarm and create a new one just to make some minor change in the time.

      • AllanDay: see my email on the usability list.

  • Change some of the terminology:
    • 'Repeat' instead of 'trigger' [Fixed]
    • 'Alert' instead of 'notification' [Fixed]
    • 'Dismiss' instead of 'clear' [Fixed]
  • Primary functionality should be provided by left mouse button context menu. This functionality includes:
    • Add alarm
    • Add timer
    • View active alarms
    • Dismiss, snooze and delete individual alarms

      • JohannesJensen: All this functionality is available from the Alarm List window which can be accessed by left-clicking the status icon.

  • Secondary functionality should be provided by right mouse button context menu. This should include:
    • Dismiss all alarms
    • Snooze all alarms
    • Edit preferences
  • The applet icon should visually indicate when an alarm is going off.

    • JohannesJensen: In the trunk version, the icon blinks when an alarm is going off.

  • Open design questions:
    • Should the applet icon display how many alarms are active, when the next alarm is, etc?

      • JohannesJensen: As the applet is moving to the notification area, this might be a bit tricky to achieve technically. Maybe it would be possible to display how many alarms are active on top of the icon though..?

        • AllanDay: that's a possibility. Or what about a simple indication of whether there are active alarms or not?

    • Is it necessary to set the snooze period on a per alarm basis? This could be placed in the preferences.

      • JohannesJensen: Nope, definitely agree and this is something I'm already working on. Basically I'm thinking all alarms should be snoozable - also timers. An alarm clock should always be snoozed for the standard 9 minutes. For timers I'm planning to equip the snooze button with an optional drop-down list (GtkMenuToolButton) of predefined snooze configurations as well as a "Custom..." item.

        • AllanDay: that mechanism makes sense (I'm unsure whether a custom option is necessary though). Why not use it for alarms as well?

          • JohannesJensen: 9 minutes is the standard snooze time for most alarm clocks. As far as I know, this duration has been selected based on experiments with the sleep schedule. That's the reason I'm reluctant to having the option to select snooze time for alarm clocks, as they're generally used for waking up :-)

    • Should time pickers cycle one another? eg: Should moving the minute down when on zero reduce the hour by one?

      • JohannesJensen: I've never been happy with the current time picker. I don't really feel the 3 spin buttons are very useful for selecting the time. One spin button for each time element (hour, min and sec) seems too much...

        • AllanDay: I'd agree but don't know of a decent alternative.

    • Why would someone want to disable a notification bubble for an alarm?

      • JohannesJensen: No idea, that's why this has been removed in the latest development version :-)

Mockups

LMB.png

JohannesJensen: Such a menu would indeed be very neat, but as I mentioned in the mail: technically using a menu here might be inappropriate. Menu items were never designed to handle more than one click event.

NewAlarm.png

NewTimer.png

JohannesJensen: You would advise against using the same dialog for timers and alarms? The two of them are very similar...

  • AllanDay: Yes, I'd advise against that. It could be confusing if the timer dialog were to use 'Time' as opposed to 'Length'.

Repeat combo box would include the following entries:

  • Never
  • Daily
  • Weekly
  • Weekdays
  • Weekends
  • Monthly

JohannesJensen: How about other repetition schemes like Mon, Wed? Personally I have different wake-up schedules during the week. Is monthly really needed for an alarm clock - I feel this more fits into a full blown calendar application...

  • AllanDay: I agree - monthly isn't necessary. I also see the point about day-specific repetition. What about:

    • Never
    • Daily
    • Weekdays
    • Weekends

    • <Separator>

    • Mondays
    • Tuesdays
    • Wednesdays
    • Thursdays
    • Fridays
    • Saturdays
    • Sundays

JohannesJensen: I feel checkboxes are more appropriate for setting repeat on individual days. I guess each of the day-items could have a checkbox right of them? Then what happens if a user checks all days mon-fri? Should the weekends item be selected then? Furthermore, should the checkboxes be updated when "Weekdays" is selected?

Right mouse button menu would include:

  • Stop all alarms
  • Snooze all alarms
  • Preferences... [Though I am unsure what would go in here.]
  • Alerts...

The alert combo box would include a list of the set alerts followed by a separator, followed by an 'Edit alerts...' entry (this would open the alert editor).

Alerts.png

  • The order of the alerts in this dialog would conform to the order in the alerts combo box in the New Alarm/Timer dialog.
  • The top item is the default alert.
  • Alerts can be reordered using drag and drop.
  • Alerts can be renamed by double-clicking on their list entry.
  • When 'Add' is pressed - a new entry is added to the alert list and focus switches to this item so that a title can be typed.

JohannesJensen: Good idea to abstract the alerts into its own settings window! I like it very much :-) Where would the alert name come from though? What would be an appropriate name for an alert with a custom command?

  • AllanDay: glad you like it. :) I've added some notes on this above.

    • JohannesJensen: Why should the UI distinguish between applications and commands? After all, they're the same thing. Maybe the command part could be merged into the application part, and add a dialog for editing the applications?

JohannesJensen: I've also thought about allowing snoozing and stopping of application alerts. I.e. if the alarm starts Banshee and the user hits snooze, then playback should be stopped. This would require the applet to know how to stop banshee, so each application then comes with two commands: one for starting and one for stopping. How could this be incorporated into the UI without being confusing?

Attic/AlarmClock/Blueprints/BetterUI/More (last edited 2018-01-14 21:26:07 by SvitozarCherepii)