852682 - SIM pin entry screen in FTE is not clear

Status: RESOLVED DUPLICATE of bug 1017591

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

Description

[Casey Yee]

Attachment: FTE SIM pin entry is unclear

SIM pin entry during first run experience is confusing:
- "Skip" and "Send" buttons don't make much sense since you should not be able to skip this step and your not sending your code anywhere.   "Back" to return to the previous screen and "Ok" to submit your pin would be more appropriate.
- Title should also be specific about what kind of pin code is being requested.   "Enter SIM pin" would be more descriptive.

Comment 1

[Fernando Campo (:fcampo)]

I think 'skip' button should remain in the screen, as we are actually able to skip the step. User should be able to use the device without phone capabilities, or at least configure it freely without worrying about the PIN. It will be asked again when he tries to use it as a phone.

For the other issues, I'm adding UX and interaction designers to give their opinion

Also, I don't think this is a blocker, as it's more a question of semantics

Comment 2

[Rafael Rebolleda]

The user should most def be able to skip this step and use the phone with no phone capabilities. The issue we need to follow in this regard is SIM activation, but I think we should have that covered by now. "Send" definitely doesn't make any send. I'm fine que "OK". I'm also guessing "PIN" should be all caps if SIM is too.

I'm adding Sergi to the loop to take a look at some visual inconsistencies in this screen.

Comment 3

[Sergi]

Attachment: SIM PIN Entry :: Screenshot

I agree with Casey we should not give the user the option to skip this screen. Let's say that maybe we should change the label of the button. It's true we should let the user keep on without having phone capabilities, but this would be better done by adding a "Cancel" button, like other major OS does. I also suggest to change the "Send" label by an "Ok", because we're not sending nothing anywhere.

Other suggestions are to remove the title on top of the input area. IMHO it's pretty clear what this screen should be used for if you read the label in the header, and we will make the screen more clean and clear if we reduce the amount of info displayed.

Last thing, i'm not quite sure why are we showing a "," in the point key, And a "-" in the zero key. I assume that's something related to keyboard, but taking into account we're not using those symbols to enter a PIN code, i think it's better if we can remove them.

Comment 4

[Sergi]

Attachment: SIM PIN Entry FTE :: Screenshot

Guys,

i've been checking the screen we're using to ask for the SIM PIN outside the FTE, and we should make these two screens consistent. I mean, for me asking for the SIM PIN should not be part of the FTU, and we should use an activity instead. The main difference is that an activity is shown with an animation from bottom to top, and we should use an "X" on the header.

I talked with Fernando and he told me it's not possible to use an activity to ask for the PIN, but que should make this screen look as it was an activity from an styling point of view, and for the sake of consistency. Basically that involves adding an "X" to the header to cancel the PIN request, and an "OK" to accept the PIN and proceed. We should also use the same background as we use in settings, and not the one we're using right now.

We should also change the way the SIM PIN Screen looks like in the rest of cases. I've added a screenshot to this bug. Let me know if we should open a new one for this.

Comment 5

[Sergi]

Attachment: SIM PIN Entry Generic :: Screenshot

Comment 6

[Fernando Campo (:fcampo)]

Just to clarify, we don't use activities on the FTU as it is isolated from the WindowsManager to avoid side effects by getting out of the initial process, but maybe we could use a common shared component (html+js+css only) in order to keep the consistency.

Right now we have PIN screens on FTU, Settings and System, all of them with quite the same functionality and some differences on style (settings is able to change the pin, for example), so maybe we should isolate a minimal functionality on an independent component under /shared folder.

And as a note to Sergi, apart from the PIN screen, remember there's also a PUK code screen (and some provider unlock code screen too), and some errors to show to the user (but with the basic style we see on the screenshot, we would be able to easily transform those screens too)

Comment 7

[Sergi]

(In reply to Fernando Campo (:fcampo) from comment #6)
> Just to clarify, we don't use activities on the FTU as it is isolated from
> the WindowsManager to avoid side effects by getting out of the initial
> process, but maybe we could use a common shared component (html+js+css only)
> in order to keep the consistency.
> 
> Right now we have PIN screens on FTU, Settings and System, all of them with
> quite the same functionality and some differences on style (settings is able
> to change the pin, for example), so maybe we should isolate a minimal
> functionality on an independent component under /shared folder.

As far as we have the same styles for all the screens, i'm ok with it.

> 
> And as a note to Sergi, apart from the PIN screen, remember there's also a
> PUK code screen (and some provider unlock code screen too), and some errors
> to show to the user (but with the basic style we see on the screenshot, we
> would be able to easily transform those screens too)
Let's apply the same styles for all the screens, and we can fine tune them wen done.

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

Minusing for now since it's not clear what the action will be on this bug, is comment 5 the proposed change?  Please come back with an uplift nomination when a decision is make that takes into account the risk of changing this screen so late in the game.

Comment 9

[Sergi]

(In reply to [e-mail] from comment #8)
> Minusing for now since it's not clear what the action will be on this bug,
> is comment 5 the proposed change?  Please come back with an uplift
> nomination when a decision is make that takes into account the risk of
> changing this screen so late in the game.

Yes, comment 5 is the proposed change

Comment 10

[Fernando Campo (:fcampo)]

(In reply to Sergi from comment #9)
> (In reply to [e-mail] from comment #8)
> > Minusing for now since it's not clear what the action will be on this bug,
> > is comment 5 the proposed change?  Please come back with an uplift
> > nomination when a decision is make that takes into account the risk of
> > changing this screen so late in the game.
> 
> Yes, comment 5 is the proposed change

So I'm taking care of it. Will renom when patch is ready, so I can evaluate the risk better

Comment 11

[Sergi]

Attachment: Enter PIN Generic

I've made a couple of updates to the visuals. Basically added the field title again and the message informing how many retries are left. In case the user inputs an incorrect PIN we should be showing an overlay with an error, and paint the field in red. When the user starts typing the PIN back again we should remove the red outline. Another suggestion is to always show how many tries the user has. When you have 3 tries left we may paint the text in black. When there're 2 or less we should use red.

I've attached a couple of samples, one with the SIM PIN entry screenshot and another one with the flow i described before.

Comment 12

[Sergi]

Attachment: Enter PIN :: Error Handling

Comment 13

[Sergi]

Attachment: Enter PIN :: Error Handling

Comment 14

[Fernando Campo (:fcampo)]

While reviewing old bugs I found this, that probably collides with the current visuals, and latest changes on the FTE. 

Asking UX to confirm if this is obsolete or we should take care of it (with a visual refresh)

Comment 15

[Victoria Gerchinhoren [:vicky]]

Hi Fernando,
There are severak bugs that were left behind just due to priorization, and being old might not mean that are solved (like the transitions). Can you provide screenshots of how it is working right now?

Thanks!

Comment 16

[Fernando Campo (:fcampo)]

Attachment: current SIM-PIN Screens

(In reply to Victoria Gerchinhoren [:vicky] from comment #15)
> [...] Can you provide screenshots of how it is working right now?
> 
> Thanks!
I live to serve :)

All System, Settings and FTE PIN screens, first appearance, and error handling.
Ping me if you need more screenshots.

Comment 17

[Victoria Gerchinhoren [:vicky]]

(In reply to Fernando Campo (:fcampo) from comment #16)
> Created attachment 8420983 [details]
> current SIM-PIN Screens
> 
> (In reply to Victoria Gerchinhoren [:vicky] from comment #15)
> > [...] Can you provide screenshots of how it is working right now?
> > 
> > Thanks!
> I live to serve :)
> 
> All System, Settings and FTE PIN screens, first appearance, and error
> handling.
> Ping me if you need more screenshots.

Hahah! Thanks Fernando, you're right, I think this bug is obsolete. 

But, the screens with the orange header are not using the correct input field... Should a new bug for that be raised?

Comment 18

[Fernando Campo (:fcampo)]

(In reply to Victoria Gerchinhoren [:vicky] from comment #17)
>>
> Hahah! Thanks Fernando, you're right, I think this bug is obsolete. 
> 
> But, the screens with the orange header are not using the correct input
> field... Should a new bug for that be raised?

That would be a good idea, I opened bug 1009053 for that.

Also, I noticed that while both System and Settings' header strings (Enter SIM PIN) and input label (SIM PIN) are synchronized, FTE differs (Enter PIN code / Type your PIN code).

And where FTE and System use both footer buttons, Settings still uses the top-right. Also FTE uses 'OK' and System uses 'Done'.

Shouldn't we sync all those aspects on the different screens? strings, position of errors, colours, etc.

Comment 19

[Victoria Gerchinhoren [:vicky]]

(In reply to Fernando Campo (:fcampo) from comment #18)
> (In reply to Victoria Gerchinhoren [:vicky] from comment #17)
> >>
> > Hahah! Thanks Fernando, you're right, I think this bug is obsolete. 
> > 
> > But, the screens with the orange header are not using the correct input
> > field... Should a new bug for that be raised?
> 
> That would be a good idea, I opened bug 1009053 for that.
> 
> Also, I noticed that while both System and Settings' header strings (Enter
> SIM PIN) and input label (SIM PIN) are synchronized, FTE differs (Enter PIN
> code / Type your PIN code).
> 
> And where FTE and System use both footer buttons, Settings still uses the
> top-right. Also FTE uses 'OK' and System uses 'Done'.
> 
> Shouldn't we sync all those aspects on the different screens? strings,
> position of errors, colours, etc.

Yes Fernando, you're right. It should all be consistent. And all edit/settings headers are light gray with blue text, so that should be consistent as well.

Are you covering the bug filling?

Thanks

Comment 20

[Fernando Campo (:fcampo)]

De-assigng myself until we have a clear path to follow

Comment 21

[Jacqueline Savory [:jsavory] UX]

Removing flag as I believe this one is covered in bug 1017591

Comment 22

[Sam Foster [:sfoster] (he/him)]

Lets close this old bug in favor of bug 1017591