[UX Spec] User should be able to configure alarm settings to vibrate only.

RESOLVED FIXED

Status

Firefox OS
Gaia::Clock
P1
normal
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Stephany Wilkes, Assigned: Casey Yee)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: u=user c=System )

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

5 years ago
UX pattern is needed since this setting (and the UX choices we make here) will also apply to the Clock and Calendar alarms. This is actually about alarm behavior in general.

Addresses row 12 of the LG 19 spreadsheet.

UX patterns and wireframes are expected outcomes.
(Reporter)

Updated

5 years ago
Duplicate of this bug: 855390

Comment 2

5 years ago
I've offered a global settings concept and an in-app concept. You can find both in this pdf: http://kunzi.me/LaJj

Comment 3

5 years ago
Apologies, I left out a note:

One of the cons that I observe about the concept shown on page 8 of the document is that users might not notice the Vibrate Only sound option as they are expecting a list made entirely of sounds. I've tried to combat this by putting it near the top of the list, before any other sound options.

Comment 4

5 years ago
quick question before sending off the final spec:

I've applied the global toggle pattern in-app here: http://kunzi.me/UW14

Does that look weird/off without a text value like the other options?

We could swap out the toggle for an on/off select, however, that may be a bit clumsy to have an on/off select when that's precisely what the toggle button is for: http://kunzi.me/bc6s

My favorite option is to left align the toggle like so: http://kunzi.me/AwaF

But i'm not sure if the left-aligned toggle pattern appears anywhere else. If not, would it be strange introducing it in this app?

Updated

5 years ago
Duplicate of this bug: 832336
Created attachment 746463 [details]
Mock Up for Edit Alarm

Hi, 

I've attached the revised mock up to include a drop down for vibrate.

Sergi, can you take a look at this mock up and let us know if the labels above the drop down selects will be a problem?  If they work, will the building blocks need to be updated?

Thanks!
Flags: needinfo?(sergiov)
Kyle, Seeing as Pavel has created a patch on bug 832336.  Would it make sense for him to transfer and update the patch once we have confirmation from Sergi about the labels?
Flags: needinfo?(kyle)
Component: Gaia::Settings → Gaia::Clock
Hardware: Other → ARM

Comment 8

5 years ago
Eric, I think it makes sense to transfer and update the patch, yes.
Flags: needinfo?(sergiov)
Flags: needinfo?(kyle)
I just want to say that this one is new functionality and will need some dev work, right?
(Reporter)

Comment 10

5 years ago
Yes, but the dev work will take place in a separate implementation story.

Comment 11

5 years ago
Created attachment 749254 [details]
Set Alarm :: Screenshot

(In reply to Eric Pang [:epang] from comment #6)
> Created attachment 746463 [details]
> Mock Up for Edit Alarm
> 
> Hi, 
> 
> I've attached the revised mock up to include a drop down for vibrate.
> 
> Sergi, can you take a look at this mock up and let us know if the labels
> above the drop down selects will be a problem?  If they work, will the
> building blocks need to be updated?
> 
> Thanks!

The main problem i see in this screen, and that's something that comes from some time ago, is we should not be using the Time Picker inside the settings screen. Time picker is a system component, and it should be launched from within the settings screen using a list button (the one with a little arrow at the bottom right). The list button should contain the current selected time if any, or a call to action if not.
 
Regarding the labels my suggestion is to use the standard subheaders. 

Let me know if you need more info.

Thanks!
Created attachment 749304 [details]
Mock Up for Edit Alarm

Hi Sergi, 

I spoke with Patryk and Przemek about the mock up you created.  We completely agree with the way the Time Picker should be handled.

We don't think it makes sense to use subheadings in this case because the labels are more descriptions of what the drop downs do and not separate sections.

Will handling labels in this way need to be added to the building blocks?

I've created a new mock up to reflect this update, let me know what you think and if we are good to advance this bug. 

Thanks!
Attachment #746463 - Attachment is obsolete: true
Flags: needinfo?(sergiov)
Flags: needinfo?(arnau)

Comment 13

5 years ago
I see. Yes we should add the labels you're proposing to the building blocks. I'm wondering if it would be better to add them together with the button BB (IMHO that doesn't make a lot of sense), and another option would be to add this as part of lists or headers (this way we should be able to use these labels with other components like input fields.
Flags: needinfo?(sergiov)
(In reply to Sergi from comment #13)
> I see. Yes we should add the labels you're proposing to the building blocks.
> I'm wondering if it would be better to add them together with the button BB
> (IMHO that doesn't make a lot of sense), and another option would be to add
> this as part of lists or headers (this way we should be able to use these
> labels with other components like input fields.

I believe adding them to be part of lists or headers makes more sense, but you and Arnau have much more experience with the BB, so I trust your judgement.

Can you let us know when the Building Blocks are updated so Pavel can start work on this bug?

Thanks again!
Eric

Comment 15

5 years ago
I've been checking with Arnau and seems what makes more sense is to add a label to the button BB. This way you will be able to use it or not depending on the app. We may add this also to inputs, just in case we also need to place a label next to it.

We'll start implementing this asap and will let you know when it's available.

Thanks!

Updated

5 years ago
Flags: needinfo?(arnau)

Updated

5 years ago
Attachment #749254 - Attachment is obsolete: true

Comment 16

5 years ago
I've added a new BB bug and assigned it to Arnau: https://bugzilla.mozilla.org/show_bug.cgi?id=872464

Hope to have this ready today.

Will keep you posted.

Thanks!
(In reply to Sergi from comment #16)
> I've added a new BB bug and assigned it to Arnau:
> https://bugzilla.mozilla.org/show_bug.cgi?id=872464
> 
> Hope to have this ready today.
> 
> Will keep you posted.
> 
> Thanks!

Great, thanks Sergi!
(Reporter)

Comment 18

5 years ago
I am marking this Resolved (since Eric has completed the final wireframe) and will block the engineering implementation story (867038) on it. I will close earlier wireframe related bugs as Dupes or Resolved. Please ping me if you have any questions.
(Reporter)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Reporter)

Updated

5 years ago
Blocks: 867038

Comment 19

5 years ago
Eric, one more thing Steve pointed out. 

The delete button at the bottom of the screen should go over a black background, because it's referring to the whole screen.

Can we update that in the mockup?

Thanks!
Created attachment 750613 [details]
Mock Up for Edit Alarm

Sergi, I've updated the mock up.  Can you confirm this is the correct treatment?  I'll also be uploading the mock up to the engineering bug - so both are up to date on the latest mock up. Thanks!
Attachment #749304 - Attachment is obsolete: true
Flags: needinfo?(sergiov)

Comment 21

5 years ago
(In reply to Eric Pang [:epang] from comment #20)
> Created attachment 750613 [details]
> Mock Up for Edit Alarm
> 
> Sergi, I've updated the mock up.  Can you confirm this is the correct
> treatment?  I'll also be uploading the mock up to the engineering bug - so
> both are up to date on the latest mock up. Thanks!
That's perfect.

Thanks!
Flags: needinfo?(sergiov)

Updated

5 years ago
Depends on: 872464
You need to log in before you can comment on or make changes to this bug.