832335 - [Clock] Display Alarm set notification inside Analog clock face

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Clock, defect)

Description

[Peter La]

Every time I set an alarm in the Clock app, it takes me back to the clock screen and immediately pops up a notification that I've set my alarm.  At times, this notification also immediately covers up the alarm I set.  What is the purpose of this notification?  I just set my alarm - do I need to be notified of it?  And when you are quickly checking on/off a list of alarms, this notification appears as well, and sometimes prevents me from checking off/on the bottom one until it disappears.

In general, it offers little value, and more often than not, gets in the way.

If we want to highlight/give visual confirmation that an alarm has been set, there may be a way of doing it that doesn't involve this type of notification popup, such as temporarily highlighting the alarm row on the main screen, and have it fade off.

Comment 1

[Panos Astithas (he/him) [:past] (please ni?)]

I agree that it often gets in the way, but I find some use in the estimate of how long until the alarm triggers, both as a verification that I didn't mess up the date, time, or am/pm setting, and also as an estimate of how much sleep I'll get when I'm setting an alarm to wake me up in the morning.

Comment 2

[Rick Waldron [:rwaldron]]

The current specs were created long after this was filed. 

Eric, this is to be implemented as spec'ed correct?

Comment 3

[Eric Pang [:epang] UX]

(In reply to Rick Waldron from comment #2)
> The current specs were created long after this was filed. 
> 
> Eric, this is to be implemented as spec'ed correct?

Rick, yes it's implemented to spec.

Peter, do you still consider this to be a problem?  I agree it is a bit annoying that it covers the new alarm.  Maybe this can be looked at and the notification can appear at the top (not obstructing the new alarm)?

Comment 4

[Rick Waldron [:rwaldron]]

(In reply to Eric Pang [:epang] from comment #3)
> (In reply to Rick Waldron from comment #2)
> > The current specs were created long after this was filed. 
> > 
> > Eric, this is to be implemented as spec'ed correct?
> 
> Rick, yes it's implemented to spec.

That's not what I was asking, because it's not currently implemented like this at all. I was asking if we should implement this as it appears in the latest spec. I'm going to assume the answer is yes.

Comment 5

[Rick Waldron [:rwaldron]]

Adam, can you take a look at this: https://mozilla.app.box.com/s/wzgsb3lkqglv0dnfdgzs/1/865451532/7980189616/1

I'd say that the Alarm set "hand" should represent the time of the _next_ possible alarm in the future.

Comment 6

[Eric Pang [:epang] UX]

(In reply to Rick Waldron from comment #4)
> (In reply to Eric Pang [:epang] from comment #3)
> > (In reply to Rick Waldron from comment #2)
> > > The current specs were created long after this was filed. 
> > > 
> > > Eric, this is to be implemented as spec'ed correct?
> > 
> > Rick, yes it's implemented to spec.
> 
> That's not what I was asking, because it's not currently implemented like
> this at all. I was asking if we should implement this as it appears in the
> latest spec. I'm going to assume the answer is yes.

Rick, I don't think Peter was referring to the alarm hand of the clock for this bug.  I believe he was referencing the notification pop up that appears from the bottom of the screen (covering the bottom most alarm for a few seconds).  Also, the clock is currently being worked on and I'm not sure if the alarm hand is to be implemented.  Przemek, working with Rob and Jacqueline was this part of the specs? Thanks!

Comment 7

[Adam Hyland [:protonk]]

Rick, I agree with Eric that the question of the spec (i.e. the alarm hand) isn't related to the issue being reported here. I'll take a look at both issues. Do you have a source with more context for the clock spec?

Comment 8

[Rick Waldron [:rwaldron]]

(In reply to Eric Pang [:epang] from comment #6)
> (In reply to Rick Waldron from comment #4)
> > (In reply to Eric Pang [:epang] from comment #3)
> > > (In reply to Rick Waldron from comment #2)
> > > > The current specs were created long after this was filed. 
> > > > 
> > > > Eric, this is to be implemented as spec'ed correct?
> > > 
> > > Rick, yes it's implemented to spec.
> > 
> > That's not what I was asking, because it's not currently implemented like
> > this at all. I was asking if we should implement this as it appears in the
> > latest spec. I'm going to assume the answer is yes.
> 
> Rick, I don't think Peter was referring to the alarm hand of the clock for
> this bug.  I believe he was referencing the notification pop up that appears
> from the bottom of the screen (covering the bottom most alarm for a few
> seconds). 

My mistake, I had just been reviewing the specs and then reading through bugs and had assumed the "alarm is set"... anyway, I'll spare you ;)

Thanks for the clarification.

Comment 9

[[e-mail], [e-mail]]

If we want to implement the alarm hand of the clock, please file another issue for tracking it. It would be more clear for each bug.

Comment 10

[Eric Pang [:epang] UX]

(In reply to Ian Liu [:ianliu] from comment #9)
> If we want to implement the alarm hand of the clock, please file another
> issue for tracking it. It would be more clear for each bug.

Rick, no worries :)

Ian,  I'll be discussing this with the visual team today.  It is not clear it the plan was to implement the alarm hand on the clock at all.  Thanks!

Comment 11

[Eric Pang [:epang] UX]

(In reply to Eric Pang [:epang] from comment #10)
> (In reply to Ian Liu [:ianliu] from comment #9)
> > If we want to implement the alarm hand of the clock, please file another
> > issue for tracking it. It would be more clear for each bug.
> 
> Rick, no worries :)
> 
> Ian,  I'll be discussing this with the visual team today.  It is not clear
> it the plan was to implement the alarm hand on the clock at all.  Thanks!

At the moment we don't have any plans to implement the alarm hand on the analog clock.  No new bug needs to be opened, thanks!

Comment 12

[Eric Pang [:epang] UX]

(In reply to Eric Pang [:epang] from comment #10)
> (In reply to Ian Liu [:ianliu] from comment #9)
> > If we want to implement the alarm hand of the clock, please file another
> > issue for tracking it. It would be more clear for each bug.
> 
> Rick, no worries :)
> 
> Ian,  I'll be discussing this with the visual team today.  It is not clear
> it the plan was to implement the alarm hand on the clock at all.  Thanks!

At the moment we don't have any plans to implement the alarm hand on the analog clock.  No new bug needs to be opened, thanks!

Comment 13

[Eric Pang [:epang] UX]

(In reply to Eric Pang [:epang] from comment #10)
> (In reply to Ian Liu [:ianliu] from comment #9)
> > If we want to implement the alarm hand of the clock, please file another
> > issue for tracking it. It would be more clear for each bug.
> 
> Rick, no worries :)
> 
> Ian,  I'll be discussing this with the visual team today.  It is not clear
> it the plan was to implement the alarm hand on the clock at all.  Thanks!

At the moment we don't have any plans to implement the alarm hand on the analog clock.  No new bug needs to be opened, thanks!

Comment 14

[Adam Hyland [:protonk]]

Attachment: Patch on github

I've attached a patch which refactors the banner notification code and also updates the location of the banner itself. I can't see in the specs for 1.2 or 1.1 (or the UX wireframes) if there is a specific location the UX team has in mind for the banner. However I agree with Peter that the very bottom is not optimal. I chose to place the notification at about 20% of the screen height, which won't fully obscure the bottom alarm or the clock face itself. This also offers the user a quick animation to indicate that this element is not as persistent as the alarm elements themselves.

Comment 15

[Eric Pang [:epang] UX]

(In reply to Adam Hyland from comment #14)
> Created attachment 792980 [details] [review]
> Patch on github
> 
> I've attached a patch which refactors the banner notification code and also
> updates the location of the banner itself. I can't see in the specs for 1.2
> or 1.1 (or the UX wireframes) if there is a specific location the UX team
> has in mind for the banner. However I agree with Peter that the very bottom
> is not optimal. I chose to place the notification at about 20% of the screen
> height, which won't fully obscure the bottom alarm or the clock face itself.
> This also offers the user a quick animation to indicate that this element is
> not as persistent as the alarm elements themselves.

I don't believe a updated spec for this has been created since I think it already follows the current spec (https://mozilla.box.com/s/kkgyd49uae6awxgbsx6i). Stephany, do you know?  It looks like Peter filed the bug as a discussion - but spec work may never have been started.

Comment 16

[Adam Hyland [:protonk]]

(In reply to Eric Pang [:epang] from comment #15)
> I don't believe a updated spec for this has been created since I think it
> already follows the current spec
> (https://mozilla.box.com/s/kkgyd49uae6awxgbsx6i). Stephany, do you know?  It
> looks like Peter filed the bug as a discussion - but spec work may never
> have been started.

Eric, do you have a non password-protected version of that image? I was working from the publicly available 1.2 visual specs and the UX wireframes we've received on Clock so far.

Comment 17

[Eric Pang [:epang] UX]

(In reply to Adam Hyland from comment #16)
> (In reply to Eric Pang [:epang] from comment #15)
> > I don't believe a updated spec for this has been created since I think it
> > already follows the current spec
> > (https://mozilla.box.com/s/kkgyd49uae6awxgbsx6i). Stephany, do you know?  It
> > looks like Peter filed the bug as a discussion - but spec work may never
> > have been started.
> 
> Eric, do you have a non password-protected version of that image? I was
> working from the publicly available 1.2 visual specs and the UX wireframes
> we've received on Clock so far.

Hi Adam,  I've shared the entire clock folder with you now.  You shouldn't have a problem accessing the files.

Comment 18

[[e-mail], [e-mail]]

(In reply to Eric Pang [:epang] from comment #17)
> (In reply to Adam Hyland from comment #16)
> > (In reply to Eric Pang [:epang] from comment #15)
> > > I don't believe a updated spec for this has been created since I think it
> > > already follows the current spec
> > > (https://mozilla.box.com/s/kkgyd49uae6awxgbsx6i). Stephany, do you know?  It
> > > looks like Peter filed the bug as a discussion - but spec work may never
> > > have been started.
> > 
> > Eric, do you have a non password-protected version of that image? I was
> > working from the publicly available 1.2 visual specs and the UX wireframes
> > we've received on Clock so far.
> 
> Hi Adam,  I've shared the entire clock folder with you now.  You shouldn't
> have a problem accessing the files.

Hi Eric,
Could you please share the folder for me? I'm not able to access it. It's hard to understand what you have mentioned. Thanks.

Comment 19

[Przemek Abratowski [:przemek] UX]

info provided by Eric.

Comment 20

[Adam Hyland [:protonk]]

(In reply to Ian Liu [:ianliu] from comment #18)
> (In reply to Eric Pang [:epang] from comment #17)
> > (In reply to Adam Hyland from comment #16)
> > > (In reply to Eric Pang [:epang] from comment #15)
> > > > I don't believe a updated spec for this has been created since I think it
> > > > already follows the current spec
> > > > (https://mozilla.box.com/s/kkgyd49uae6awxgbsx6i). Stephany, do you know?  It
> > > > looks like Peter filed the bug as a discussion - but spec work may never
> > > > have been started.
> > > 
> > > Eric, do you have a non password-protected version of that image? I was
> > > working from the publicly available 1.2 visual specs and the UX wireframes
> > > we've received on Clock so far.
> > 
> > Hi Adam,  I've shared the entire clock folder with you now.  You shouldn't
> > have a problem accessing the files.
> 
> Hi Eric,
> Could you please share the folder for me? I'm not able to access it. It's
> hard to understand what you have mentioned. Thanks.

Eric,

I've updated the PR to match the spec (showing the banner notification slightly above the bottom).

Comment 21

[Eric Pang [:epang] UX]

(In reply to Adam Hyland [:protonk] from comment #20)
> (In reply to Ian Liu [:ianliu] from comment #18)
> > (In reply to Eric Pang [:epang] from comment #17)
> > > (In reply to Adam Hyland from comment #16)
> > > > (In reply to Eric Pang [:epang] from comment #15)
> > > > > I don't believe a updated spec for this has been created since I think it
> > > > > already follows the current spec
> > > > > (https://mozilla.box.com/s/kkgyd49uae6awxgbsx6i). Stephany, do you know?  It
> > > > > looks like Peter filed the bug as a discussion - but spec work may never
> > > > > have been started.
> > > > 
> > > > Eric, do you have a non password-protected version of that image? I was
> > > > working from the publicly available 1.2 visual specs and the UX wireframes
> > > > we've received on Clock so far.
> > > 
> > > Hi Adam,  I've shared the entire clock folder with you now.  You shouldn't
> > > have a problem accessing the files.
> > 
> > Hi Eric,
> > Could you please share the folder for me? I'm not able to access it. It's
> > hard to understand what you have mentioned. Thanks.
> 
> Eric,
> 
> I've updated the PR to match the spec (showing the banner notification
> slightly above the bottom).

Thanks!  I'll take a look when I get a chance :).

Comment 22

[Mike Pennisi [:jugglinmike]]

Hi Eric!

Adam has requested that I review this patch, but I noticed that the specification we've been discussing is for interaction, not for visuals, so it doesn't have the granularity we need to resolve this issue. The visual specifications for v1.1 and v1.2 both omit the disputed details. I'll wait on this patch until hearing back from you, specifically:

1. Exactly how should the banner be positioned?
2. Should the banner be displayed when disabled alarms are re-enabled?

Thanks!

Comment 23

[Eric Pang [:epang] UX]

(In reply to Mike Pennisi [:jugglinmike] from comment #22)
> Hi Eric!
> 
> Adam has requested that I review this patch, but I noticed that the
> specification we've been discussing is for interaction, not for visuals, so
> it doesn't have the granularity we need to resolve this issue. The visual
> specifications for v1.1 and v1.2 both omit the disputed details. I'll wait
> on this patch until hearing back from you, specifically:
> 
> 1. Exactly how should the banner be positioned?
> 2. Should the banner be displayed when disabled alarms are re-enabled?
> 
> Thanks!

Hi Mike!
Thanks for checking in about this.
1. I believe the banner should be located just above the bottom tool bar
2. I'm not sure what's been spec'd for this.

Jacqueline is the interaction designer for clock, Jacqueline can you help answer/confirm Mike's questions?  Thanks!

Comment 24

[Adam Hyland [:protonk]]

(In reply to Eric Pang [:epang] from comment #23)
> (In reply to Mike Pennisi [:jugglinmike] from comment #22)
> > Hi Eric!
> > 
> > Adam has requested that I review this patch, but I noticed that the
> > specification we've been discussing is for interaction, not for visuals, so
> > it doesn't have the granularity we need to resolve this issue. The visual
> > specifications for v1.1 and v1.2 both omit the disputed details. I'll wait
> > on this patch until hearing back from you, specifically:
> > 
> > 1. Exactly how should the banner be positioned?
> > 2. Should the banner be displayed when disabled alarms are re-enabled?
> > 
> > Thanks!
> 
> Hi Mike!
> Thanks for checking in about this.
> 1. I believe the banner should be located just above the bottom tool bar
> 2. I'm not sure what's been spec'd for this.
> 
> Jacqueline is the interaction designer for clock, Jacqueline can you help
> answer/confirm Mike's questions?  Thanks!

As a note, Mike's #2 refers to alarms being re-enabled from the checkbox available on the alarm list, any editing of the alarm (e.g. to change the time or name) will trigger the popup when the edit screen slides away.

Comment 25

[Mike Pennisi [:jugglinmike]]

Comment on attachment 792980 [details] [review]
Patch on github

Since the review process is temporarily suspended, I'm going to unset the review flag until we receive clarification from Jacqueline.

Comment 26

[Adam Hyland [:protonk]]

Banner refactoring work is tracked on Bug 913468. The UX questions here still need to be resolved but they won't block refactoring.

Comment 27

[Adam Hyland [:protonk]]

Eric,

Can we expect a spec update for the banner behavior for 1.3? If not, we can close this bug and file again when the spec is updated. If so, let me know and I can update the positioning and behavior for repeat alarms.

Comment 28

[Eric Pang [:epang] UX]

(In reply to Adam Hyland [:protonk] from comment #27)
> Eric,
> 
> Can we expect a spec update for the banner behavior for 1.3? If not, we can
> close this bug and file again when the spec is updated. If so, let me know
> and I can update the positioning and behavior for repeat alarms.

Hi Adam, I'm not sure if this is being spec'ed for 1.3.  Maybe Jacqueline or Rob can help provide more info to see if this is appropriate to close. Thanks!

Comment 29

[Dylan Oliver [:doliver]]

Redirecting the needinfo to Juwei -- I agree with the original reporter on this one.

Comment 30

[Juwei Huang[:juwei]]

Attachment: Alarm set notification.png

Please refer to attachment.
My suggestion would be more prefer to put the banner on top (beneath the header) rather than keep it in the bottom, since the bottom notification will still overlap the alarm info when create a new alarm (especially first time set up).
I know to put notification on top might be not align to the building blocks, yet I think the rule really depends on the design. Regarding to the current alarm in 1.3, the new alarms will display from bottom up. So I suggest to put the banner on top, then it will not overlap on any of the alarm.

Comment 31

[Candice Serran (:cserran)]

Design of clock changing in near future, so this change will become obsolete.