| 2014-08-19 18:59:04 |
Charles Kerr |
bug |
|
|
added bug |
| 2014-08-19 19:19:50 |
Dave Morley |
bug |
|
|
added subscriber Dave Morley |
| 2014-08-20 08:08:54 |
Giorgio Venturi |
bug task added |
|
ubuntu-ux |
|
| 2014-08-20 08:09:02 |
Giorgio Venturi |
ubuntu-ux: status |
New |
Triaged |
|
| 2014-08-20 08:09:07 |
Giorgio Venturi |
ubuntu-ux: importance |
Undecided |
Medium |
|
| 2014-08-20 08:09:10 |
Giorgio Venturi |
ubuntu-ux: assignee |
|
Giorgio Venturi (giorgio-venturi) |
|
| 2014-08-20 08:18:05 |
Giorgio Venturi |
ubuntu-ux: status |
Triaged |
Fix Committed |
|
| 2014-08-20 14:35:52 |
Charles Kerr |
ubuntu-ux: status |
Fix Committed |
Confirmed |
|
| 2014-08-22 08:08:30 |
Matthew Paul Thomas |
summary |
Need better usability when two alarms kick at the same time |
Competing notifications when two alarms kick at the same time |
|
| 2014-08-22 15:36:03 |
John Lea |
indicator-datetime: status |
Confirmed |
Triaged |
|
| 2014-08-22 15:36:51 |
John Lea |
summary |
Competing notifications when two alarms kick at the same time |
[Notifications] Competing notifications when two alarms kick at the same time |
|
| 2014-09-04 11:12:30 |
Giorgio Venturi |
description |
A cousin of bug #1354406
Some of the early testers are hitting a use case that we didn't account for, that of multiple alarms set for the same time.
Indicator-datetime currently tries to pull up notifications for, and play sounds for, both notifications. That's happening by accident and is clearly not the right approach.
I can think of a couple of approaches we might take:
(1) Queue the alarms such that only one triggers at a time. This has the advantage of being simple, both in concept and in code. I'm not certain this is the most user-friendly approach, as it could be frustrating have to dismiss a queue of alarms.
(2) Somehow fold multiple alarms together. This has the advantage of being friendlier to the user as only a single snooze/dismiss prompt would be given. However it opens other questions, e.g. which of the alarms' sounds should play?
Of these two I slghtly prefer (1) for its simplicity; however, neither of these options seems perfect and I'm hoping Design may have a better suggestion |
A cousin of bug #1354406
Some of the early testers are hitting a use case that we didn't account for, that of multiple alarms set for the same time.
Indicator-datetime currently tries to pull up notifications for, and play sounds for, both notifications. That's happening by accident and is clearly not the right approach.
I can think of a couple of approaches we might take:
-- SOLUTION --
If 2 or more alarms have been triggered, the notification at any time will display:
Title: 2 Alarms
Subtitle: [Label 1] 10:00, [Label 2] 10:01
The sound of the first alarm will be played. If they have the same time, the one that has been created first. |
|
| 2014-09-04 11:12:38 |
Giorgio Venturi |
ubuntu-ux: status |
Confirmed |
Fix Committed |
|
| 2015-06-04 10:59:56 |
Magdalena Mirowicz |
ubuntu-ux: assignee |
Giorgio Venturi (giorgio-venturi) |
Paty Davila (dizzypaty) |
|
| 2015-06-04 14:58:10 |
Charles Kerr |
ubuntu-ux: status |
Fix Committed |
Confirmed |
|
| 2015-06-04 14:59:15 |
Charles Kerr |
indicator-datetime: status |
Triaged |
Incomplete |
|
| 2015-06-04 14:59:24 |
Charles Kerr |
indicator-datetime (Ubuntu): status |
New |
Incomplete |
|
| 2015-06-15 16:07:59 |
Magdalena Mirowicz |
ubuntu-ux: status |
Confirmed |
Triaged |
|
| 2015-08-05 09:33:01 |
Paty Davila |
ubuntu-ux: status |
Triaged |
In Progress |
|
| 2015-08-05 15:42:45 |
Paty Davila |
description |
A cousin of bug #1354406
Some of the early testers are hitting a use case that we didn't account for, that of multiple alarms set for the same time.
Indicator-datetime currently tries to pull up notifications for, and play sounds for, both notifications. That's happening by accident and is clearly not the right approach.
I can think of a couple of approaches we might take:
-- SOLUTION --
If 2 or more alarms have been triggered, the notification at any time will display:
Title: 2 Alarms
Subtitle: [Label 1] 10:00, [Label 2] 10:01
The sound of the first alarm will be played. If they have the same time, the one that has been created first. |
A cousin of bug #1354406
Some of the early testers are hitting a use case that we didn't account for, that of multiple alarms set for the same time.
Indicator-datetime currently tries to pull up notifications for, and play sounds for, both notifications. That's happening by accident and is clearly not the right approach.
I can think of a couple of approaches we might take:
-- SOLUTION --
If 2 or more alarms have been triggered, the notification at any time will display:
Title: 2 Alarms
Subtitle: [Label 1] 10:00, [Label 2] 10:01
The sound of the first alarm will be played. If they have the same time, the one that has been created first.
------ UX Comment ------
Use cases:
1 - User sets 2 alarms, at the same time, with same attributes (repeat, label, sound)
Expected behaviour: Clock app / alarm manager recognise a conflict of newly set alarm time with previously set alarm and rejects it if it’s found same.
2 - User sets 2 alarms, at the same time, with (one or more) different attributes (repeat, label, sound)
Expected behaviour: the alarm that was set in the first place is the one that goes off (with correspondent sound and label) and the second one is fired as a notification bubble.
3 - User sets 2 alarms, at different times, even if the difference is 1 minute. Then first alarm goes off and second alarm does it one minute after.
4 - Several notifications fired at the same time:
Desired behaviour described here: Page 35: Notifications queuing and flood prevention
https://docs.google.com/document/d/1xDSZ_dnAMAlhgFnnyjJEibaITXjVLp1_pnj_tATNm9I/edit#heading=h.5ldl02lx6rwi
"In general, applications can fire only one notification at a time, but multiple applications can fire their notification simultaneously. All notifications should be treated as if they are in a queue and will be handled sequentially according to their fire time (in a FIFO manner)." |
|
| 2015-08-05 15:42:50 |
Paty Davila |
ubuntu-ux: status |
In Progress |
Fix Committed |
|
