[Clock] Display Alarm set notification inside Analog clock face

RESOLVED WONTFIX

Status

Firefox OS
Gaia::Clock
RESOLVED WONTFIX
5 years ago
3 years ago

People

(Reporter: Peter La, Assigned: protonk)

Tracking

unspecified
All
Gonk (Firefox OS)

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

(Whiteboard: interaction, v1.1)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
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.
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.
The current specs were created long after this was filed. 

Eric, this is to be implemented as spec'ed correct?
Flags: needinfo?(epang)
(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)?
Flags: needinfo?(epang) → needinfo?(pla)
(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.
Assignee: nobody → achyland
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.
Summary: Alarm set notification in Clock is unnecessary and gets in the way → [Clock] Display Alarm set notification inside Analog clock face
(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!
Flags: needinfo?(pabratowski)
(Assignee)

Comment 7

5 years ago
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?
(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.
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.
(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!
(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!
(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!
Flags: needinfo?(pla)
(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!
(Assignee)

Comment 14

5 years ago
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.
Attachment #792980 - Flags: review?(waldron.rick)
(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.
Flags: needinfo?(swilkes)
(Assignee)

Comment 16

5 years ago
(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.
(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.
(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.
info provided by Eric.
Flags: needinfo?(pabratowski)
(Assignee)

Comment 20

5 years ago
(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).
(Assignee)

Updated

5 years ago
Attachment #792980 - Flags: review?(waldron.rick) → review?(mike)
(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 :).
Blocks: 910313
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!
Flags: needinfo?(epang)
(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!
Flags: needinfo?(swilkes)
Flags: needinfo?(jsavory)
Flags: needinfo?(epang)
(Assignee)

Comment 24

5 years ago
(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 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.
Attachment #792980 - Flags: review?(mike)
(Assignee)

Updated

5 years ago
Assignee: achyland → nobody
(Assignee)

Comment 26

5 years ago
Banner refactoring work is tracked on Bug 913468. The UX questions here still need to be resolved but they won't block refactoring.
Attachment mime type: text/plain → text/x-github-pull-request
(Assignee)

Updated

5 years ago
Assignee: nobody → achyland
(Assignee)

Comment 27

5 years ago
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.
Flags: needinfo?(epang)
(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!
Flags: needinfo?(epang) → needinfo?(rmacdonald)
Redirecting the needinfo to Juwei -- I agree with the original reporter on this one.
Flags: needinfo?(rmacdonald)
Flags: needinfo?(jsavory)
Flags: needinfo?(jhuang)

Comment 30

4 years ago
Created attachment 8359130 [details]
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.
Flags: needinfo?(jhuang)
blocking-b2g: --- → backlog
Design of clock changing in near future, so this change will become obsolete.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.