Snooze dialog needs to be more flexible

VERIFIED FIXED in 0.7

Status

Calendar
Alarms
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: mmindenhall, Assigned: Sven Giermann)

Tracking

unspecified

Details

Attachments

(3 attachments, 3 obsolete attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

The snooze dialog only provides the ability to snooze for "5 minutes", "15 minutes", "30 minutes", "1 hour", or "1 day".  I was a big fan of the 0.2 snooze dialog, which had a text entry box for the number, and then a dropdown box to select "minutes", "hours", or "days".  This provided a lot of flexibility in using the snooze feature creatively.  For example, if I have an upcoming event that I want to be reminded of, I can set an alarm for 1 day prior.  When the alarm pops up, I can then snooze it for 23 hours so I'll be reminded again an hour before the event starts.  Then I can snooze it for 55 minutes in order to get a "5 minute warning".  Etc.

My request is to restore this snooze flexibility in the Alarms UI.  I'm leaving this as a "Normal" severity bug rather than an "Enhancement", since I consider it a regression from functionality that was available in 0.2.


Reproducible: Always
(Reporter)

Comment 1

11 years ago
Forgot to mention version:  0.3RC2.

Comment 2

11 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061031 Calendar/0.4a1

Confirmed

Comment 3

11 years ago
Confirming since koen has confirmed it as part of Octobert 31st test day.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

11 years ago
In addition this dialog needs "Open Item" buttons that open the Edit Task/Event dialog. Currently, if one needs to change something in a item, has to remember the name of the task/event and look for it in the task list or calendar sheets.

Comment 5

11 years ago
One more thing - the alarms dialog needs a Minimize button as well.

Comment 6

11 years ago
From my point of view the following behaviour would be better:

I set an event to Friday 14:00 and I want to be reminded 1 day before. I will get the reminding Thursday at 14:00. It would be better then, to have the possibility to tell the programm that I want to be reminded again 2 hours before the event starts. So the Reminding dialog should not show an option to enter select a time after which I will be reminded again. But the Reminding dialog should give the possibility to select which period of time BEFORE the events starts I want to be reminded.

Other organizer programs like (e.g.) Outlook are working like this.

Updated

11 years ago
Duplicate of this bug: 365601

Comment 8

11 years ago
Also the non-standard dialog needs to be fixed.  The snooze button is to the left of the snooze interval dropdown.  Standard dialog box design puts the button for an action below or to the right of the entry fields for the action.  In this case the Dismiss button is to the right of the entry field making it very easy to set the snooze interval then dismiss the event by clicking the button that is in the normal spot for action on the field you just entered.

Comment 9

11 years ago
Please provide feature to set following intervals for snooze:
minutes: 5,15,30,45
hours:1,2,3,4,5,6,8,10,12 (or 1/2 day)
days: 1/2 (or 12 hours),1,2,3,4,5,6
weeks:1,2

Comment 10

11 years ago
(In reply to comment #6)

Ideally, there should be a choice of whether the time intered for the next alarm is a time from now or for a time before the event. Shedule+ (old Microsoft app) does this very simply with a "Beforhand" checkbox at the end of the dialoge. Unchecked means time is from now. Checked means to remind at X time before the event. 

Comment 11

11 years ago
Yes, there should be the following options for the snooze feature:
1. A text box to enter a number (that indicates the units)
2. A drop down menu that are the units (minutes, hours, days, weeks)
3. A drop down to indicate whether the alarm should trigger before the event starts or after the current time.

With this combination I think one will have a lot a flexibility in snoozing their triggered alarms. Hope these suggestions will be taken into consideration in the very near future. Thanks.

Comment 12

11 years ago
(In reply to comment #11)
> Yes, there should be the following options for the snooze feature:
> 1. A text box to enter a number (that indicates the units)
> 2. A drop down menu that are the units (minutes, hours, days, weeks)
> 3. A drop down to indicate whether the alarm should trigger before the event
> starts or after the current time.
> 
> With this combination I think one will have a lot a flexibility in snoozing
> their triggered alarms. Hope these suggestions will be taken into consideration
> in the very near future. Thanks.
> 

Actually number one above should be changed to following:
1. An editable drop down with default menu items like (5, 10, 15, 30, etc...).
to enter the duration to snooze. This will offer more flexibility to the user to choose a finer duration if he/she needs it.

Comment 13

11 years ago
(In reply to comment #12)
> (In reply to comment #11)
> > Yes, there should be the following options for the snooze feature:
> > 1. A text box to enter a number (that indicates the units)
> > 2. A drop down menu that are the units (minutes, hours, days, weeks)
> > 3. A drop down to indicate whether the alarm should trigger before the event
> > starts or after the current time.
> > 
> > With this combination I think one will have a lot a flexibility in snoozing
> > their triggered alarms. Hope these suggestions will be taken into consideration
> > in the very near future. Thanks.
> > 
> 
> Actually number one above should be changed to following:
> 1. An editable drop down with default menu items like (5, 10, 15, 30, etc...).
> to enter the duration to snooze. This will offer more flexibility to the user
> to choose a finer duration if he/she needs it.
> 

I'd agree more with the first option. A number field which can either be typed into or maybe have those little up and down buttons to change the value up and down quickly without using the keyboard. I think that limiting the options to 5, 10, 15 etc will just limit the options available and frustrate people who want a reminder in 4 days or 8 minutes.
Unless you mean that there should be 5, 10, 15 etc options, but the number can also be edited manually. That may be the best of both.

I strongly agree with the rest of your points. That's exactly what I'd like to see!
All those 'ideal' dialog are quite flexible, but you are forgetting one thing: they are not as easy to use. I think it's better to be useable then to be flexible.
So if you want more flexibility, try to think of a way that's still as easy to use (so don't require the user to set three fields, while currently only one field is to be set)

(and you don't need to quote all the previous messages when you reply in bugzilla. It makes the bug unreadable due to duplicated information)

Comment 15

11 years ago
To make this an adequate solution there /needs/ to be 3 options (number, unit, from now/before/after).  That's just a fact of usability.

There's no reason that having those options makes the dialog "not as easy to use".  It's completely user-intuitive.  "Delay this alarm by ten minutes."  "Delay this alarm until 1 hour before."  "Delay this alarm until 1 week after."

Having an editable select box achieves the best of both worlds for the number field.  Presets of 1, 5, 10, 15, 30, etc. but the field is still manually modifiable for custom values.  The units are fixed anyway - Minutes, Hours, Days, (Weeks?)...

A comparison to "what it currently does" is bad - what it currently does isn't functional for practical purposes.  How those options are displayed to the user is morphable, but the requirement of what those options are really isn't.
Comparison to the current situation is not bad at all: setting one or setting three fields is a huge difference. Setting three fields requires the user to assemble a sentence out of individual fields, while just selecting the entire sentence at once is much easier. You don't need to look-ahead at the other fields to understand that you can change the units.

In short: Multiple fields require multiple steps, which is not as easy as just one step.

So whatever solution you come up with, it must still be possible to use one of the the current options with just one step. And preferably, no other fields visible that will distract the users.

Comment 17

11 years ago
Multiple fields do not require multiple steps if there's a configurable default. Then you can just click snooze as you can now, but those other options need to be there or the snooze if just not very useful at all.
In fact its actually just annoying. I currently have to be reminded every day about things that I'd rather be reminded about in 4 days, or 2 days before hand, once the first alarm has gone off. It's enough to make me look elsewhere for a calender app. Very annoying. It's the only reason that I still have Schedule+ on my system as well as Sunbird.

Comment 18

11 years ago
Isn't the way the event/task-dialog works exactly what everyone wants?  That is, you have a dropdown that lists the common options, and a final option of 'Other' that exposes the three fields everyone is asking for.  Then you have the best of both worlds: one click access for the common options and flexibility for people who feel the need to snooze alarms for 53 minutes.  As a bonus, you could keep the last three/five/n 'flexible' periods that were entered in the dropdown as well.  Presumably most of the use-cases lead to repetition of those choices.

Most importantly, the alarm dialog was designed to be an easy space for extension authors to play in.  Rather than lots of "yes, this should be fixed now" comments, I'd much prefer to see attempts at implementing suggestions people are proposing here.  (You'll quickly learn that packing 3 widgets into an alarm-box makes things either crowded or overly-large.)

Comment 19

11 years ago
The custom Alarm options are the ones that are required for Snooze also. But the units to enter should be an editable drop down (with a handful of predefined menu items) instead. This reduces the number of fields that a user has to enter.
Also some of you have been pointed out that the user might require multiple steps to use this feature affectively. How about having a default for these three fields which can be set or changed via. the calendar's preferences? Say the default would be 5 minutes after now. Most of the times the user may not need to change anything.
Or for those who think three fields is too much how about reducing it to two by doing the following:

1. An editable drop down with default menu items like (1 min., 5 min., 10 min., 15 min., 30 min., 1 day, 2 days, 1 week,  etc...).
to enter the duration to snooze. And add some intelligence into the code that handles this duration to interpret the keywords such as min[.s], hr[s], hours, wk, week[s], day[s]. This will give flexibility to the user to enter the duration (example 33 m and the snooze will interpret this as 33 minutes) she/he wishes to snooze.
2. A drop down to indicate whether the alarm should trigger now/before/after.

I think one would prefer walking slow (having to change two fields) rather than hopping with one leg (no flexibility at all).

Comment 20

11 years ago
(In reply to comment #18)
> Isn't the way the event/task-dialog works exactly what everyone wants?  

It's one option, but I definitely don't find it ideal in the slightest.  I actually can't stand the way that alarms are set, right now.  There are two options - 15 minutes, and 30 minutes.  Beyond that involves selecing "custom" and then typing in new values.  If it (like the snooze dialog) were simply like I described above, it would be much easier to use.   Use the "custom" look, but preset the number field with a populated dropdown of default values.  (Hell, even if the normal select box supported manual addition of new "defaults" it would be better than it is now, but that's a separate discussion.)

Scrunching the dialog into two fields, as suggested in #19, is actually more work for both the developers and the users.  Not only do they have to type in the number, but they also have to type in the unit type.  If you take into account internationalization (RTL text, unit identification, etc.), this method is nearly unworkable.

For those arguing against three input/select fields, WHY is having those worse than having our current dialog?  With proper defaults values available it fulfills the current functionality, and more, with very little user impact.  This is how calendaring apps' alarm/snooze dialogs have always been built - with good reason.

Comment 21

11 years ago
Sorry, I didn't know about the difficulties when it comes to I18N (internationalization). In that case I guess some other alternative with similar affect should be designed. 
But thing I want to comment on para. 2 1st sentence of #20. If you are running a company and  a customer requests a feature, do you say it is difficult to your R&D and therefore you cannot provide the feature? Please do not mis-understand the respect that I have to all the people contributing to the calendar project. I really appreciate the work that they contribute squeezing whatever free time they have. But I feel that if it makes the user happy it is worth for the developer go through the pain once. A satisfied and a happy user will bring a hundred more users :-).
(Assignee)

Comment 22

10 years ago
(In reply to comment #14)
> All those 'ideal' dialog are quite flexible, but you are forgetting one thing:
> they are not as easy to use. I think it's better to be useable then to be
> flexible.

What about just having 2 fields and bring back the "Edit item" button?
I could imagine 1 field to enter a number and a drop-down for the units (both pre-populated with the defaults) to snooze the alarm for the given time from now and a button "Edit item" to do the rest...
This would also make it possible to just display the item again or to change something else.

Comment 23

10 years ago
Sorry to be a nag, but are any of the developers looking at this issue and taking it seriously?
Sunbird had become my primary calendar now and it's perfectly functional in every way fro me apart from these alarms. The amount of reminders I get daily just because I can't specify reminder times that I would choose is getting very annoying.
If I had any time on my hands I'd try to learn a programming language just to have a go at this, but with a family and a demanding job time is not something I have. surely some of the programmers working on Sunbird are actually using it too though. Don't these restricted alarms that result in constant reminders drive you nuts?
(Assignee)

Comment 24

10 years ago
Created attachment 281465 [details] [diff] [review]
Comeback of the Edit button

This would bring back the 'Edit' button to the alarm widgets, which would address the requests to set a new alarm time (i.e. 10 minutes before) without blowing the alarm dialog.
It also solves the mis-placement of the 'Dismiss' button, mentioned in comment #8.

To the reviewers: I used the global 'calendar.edit.button.label', because of the string-freeze for 0.7!
I will also attach a screenshot for easy ui-review.
Attachment #281465 - Flags: ui-review?(philipp)
Attachment #281465 - Flags: review?(daniel.boelzle)
(Assignee)

Comment 25

10 years ago
Created attachment 281466 [details]
Screenshot for Attachment #281465 [details] [diff]

Comment 26

10 years ago
Comment on attachment 281465 [details] [diff] [review]
Comeback of the Edit button

This patch doesn't address the topic reported in this bug and belongs to Bug 332866. But I think the final UI decision needs to be done first (Bug 341576).
(Assignee)

Comment 27

10 years ago
Comment on attachment 281465 [details] [diff] [review]
Comeback of the Edit button

Thanks Stefan, moving this one to Bug
332866!
Attachment #281465 - Attachment is obsolete: true
Attachment #281465 - Flags: ui-review?(philipp)
Attachment #281465 - Flags: review?(daniel.boelzle)
(Assignee)

Comment 28

10 years ago
Comment on attachment 281466 [details]
Screenshot for Attachment #281465 [details] [diff]

Thanks Stefan, moving this one to Bug
332866!
Attachment #281466 - Attachment is obsolete: true
(Assignee)

Comment 29

10 years ago
Created attachment 281478 [details]
Split the snooze length into 2 fields: value and unit.

Before spending time on this, I would like to get some UI feedback.

Also pay attention, that this would interfere with Bug 377416!
Attachment #281478 - Flags: ui-review?(christian.jansen)

Comment 30

10 years ago
I'm on a conference, if I have some time free. I'll review it (ASAP...)

Comment 31

10 years ago
Comment on attachment 281478 [details]
Split the snooze length into 2 fields: value and unit.

Generally I like the idea, even if it adds complexity to the dialog. IMHO the default should be set to 5 or 10 Minutes.
Attachment #281478 - Flags: ui-review?(christian.jansen) → ui-review+

Comment 32

10 years ago
(In reply to comment #31)
The default should be set to the users preference, see Bug 377416.
(Assignee)

Comment 33

10 years ago
Created attachment 281657 [details] [diff] [review]
2 fields patch v1

This modification splits the snooze value field into 2 fields: value and unit.

Also it solves the problem discussed in bug 377416, see comment #32.
Attachment #281657 - Flags: review?(daniel.boelzle)
Assignee: nobody → giermann
OS: Windows XP → All
Hardware: PC → All
Status: NEW → ASSIGNED
(Assignee)

Comment 34

10 years ago
Created attachment 281797 [details] [diff] [review]
2 fields patch v2

This update also sets the untis drop-down initially, when larger values are set as default.

It should be considered to change the preference dialog too, because it is not possible to set values larger than 999 minutes (i.e. 1 day = 1440 minutes).
Attachment #281657 - Attachment is obsolete: true
Attachment #281797 - Flags: review?(daniel.boelzle)
Attachment #281657 - Flags: review?(daniel.boelzle)
Comment on attachment 281797 [details] [diff] [review]
2 fields patch v2

>+          switch (snoozeUnit) {
>+            case 'days':
>+                snoozeValue = snoozeValue * 24;
I add a comment here that the fallback is intended.
>+            case 'hours':
>+                snoozeValue = snoozeValue * 60;
>+                break;
>+          }

r=dbo; well done Sven, thanks for the patch.

Checked in on HEAD and MOZILLA_1_8_BRANCH.
Attachment #281797 - Flags: review?(daniel.boelzle) → review+
Created attachment 281946 [details] [diff] [review]
further check for positive snooze value
Attachment #281946 - Flags: review?(ssitter)

Updated

10 years ago
Attachment #281946 - Flags: review?(ssitter) → review?(philipp)
Attachment #281946 - Flags: review?(philipp) → review+
Target Milestone: --- → 0.7
Checked in on HEAD and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 38

10 years ago
I've been a bit confused by the recent emails I've been getting re this issue as I'm not used to Bugzilla, but has this been fixed and put into 0.7?
That's what it looked like and I'm SO happy if it's the case.
Thank you for taking this problem seriously and coming up with a solution if I've read the progress correctly. I for one can't wait for 0.7 now!
Cheers
Damian
(Assignee)

Comment 39

10 years ago
VERIFIED with Build 2007-09-23-03-mozilla1.8
Status: RESOLVED → VERIFIED

Comment 40

10 years ago
I'm sorry if this is posting in the wrong place, I'm not used to bug submitting so I don't know what you should do if a bug is considered fixed, but I think there's still a big problem with the fixed snooze dialogue.

It's much better, but there's still no way to tell the alarm to go off X time BEFORE the event. You can only set X time from now. A simple check box would achieve this.

I also think what's currently there would be improved if the number could be changed with up and down buttons rather than having to manually type a value.

Not having a 'before' event toggleable option is the main problem I have with it though.

Damian
(Assignee)

Comment 41

10 years ago
The removal of the check for negative values and a small modification to calAlarmService.js/snoozeAlarm() would enable to enter "-10" minutes to snooze until 10 minutes before the event starts. (which could indeed be done using a checkbox rather than negative values)

But trying this I encountered some more problems with this issue:
1. You could move the Snooze time to the past, which would lead to a sudden new alarm after pressing 'Snooze'
2. To be more flexible it would be better to introduce another function 'rescheduleAlarm'; this would enable more options like '... minutes/hours/days before/after the event starts/ends' but it definitely blows up the alarm dialog.

Especially the second issue entitles your request to be more in line with bug 341576.

Comment 42

10 years ago
Damian, Sven: I'd like you to move the discussion about new issues and enhancement requests in an appropriate new bug (or bugs) instead of discussing them in a closed and verified bug.
You need to log in before you can comment on or make changes to this bug.