874800 - With capital letters only keyboard keys, it's very hard to tell it's state, especially when typing password

Status: RESOLVED FIXED

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

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

+++ This bug was initially created as a clone of Bug #810306 +++

Read discussion on the cloned bug and bug 860318.

Comment 1

[Julien Wajsberg [:julienw]]

> I think this is a stronger argument for it being jarring because when switching case based on
> the syntax of a sentence it's not such a direct result of a user action, so may be more
> jarring as a result. But saying that this effects typing speed seems like a bit of a leap
> without data to back it up.

I'd say that it's especially a problem for passwords, and for passwords we don't really need a speedy typing.

Would it be sensible to have the old behaviour back for password inputs, but keep the new behaviour for other inputs ?

Comment 2

[:gerard-majax]

I'd say it's a problem for every kind of input. What is the rationale behind "display caps letter when you will be entering non caps" ? Do the people who decided this really use they device daily, writing texts and emails ?

Comment 3

[Stephany Wilkes]

Reassigning to Francis since this involves keyboard. This will be addressed after we tackle leo+, tef+ and tracking bugs, which are UX's top priority right now.

Comment 4

[Matěj Cepl]

Just to add my nit to this discussion (yes, I think that ALL CAPS is a wrong UX decision).

> When the entire keyboard jumps between upper and lower case it is visually
> disruptive, drawing my eyes to the keyboard, forcing me to rescan for my target.

I don't know what kind of text you write usually, but for me (and I guess for majority of users) entire keyboard doesn't jump all the time (and it is mostly in more pleasing lower-case, but that's another issue), it jumps only when I switch mode, which is really nice subliminal indicator of the change. Not I don't stare at my keyboard all the time exactly because the jump makes it obvious even without looking for tiny small blue spec on the Shift key.

Comment 5

[:gerard-majax]

I'm still not getting used to this behavior ...

Comment 6

[cbarker]

Unless auto correct is updated to aid in making sure everything is entered in proper case, I'd say Caps for all Keys could lead to some issues for end users such as myself.  For example, I may have to try and explain that I hadn't intended to shout at my mother when replying to her text with, "wHERE Are YOU?"

My suggestion for this, if no agreement can be made on this, just make it an option in the keyboard settings.  An Ease of Access setting for the keyboard would give everyone what they want.

Comment 7

[Francis Djabri [:djabber]]

My view on this is that we should simply follow the most performant option, which should be the most important consideration. The reason that we went with always showing the keys in upper case was that it was for performance. 

If switching between lower and upper case on the keyboard has no impact on performance then I'd be happy for the keys to switch case as appropriate, but if it introduces any delays or reduction in response times, either now or potentially down the road, then I would prefer it if we keep all the keys in upper case to make sure that we're delivering the best possible performance to the user.

Comment 8

[Antoine Turmel [:GeekShadow]]

Switching to low/up letters is important I think it's more visual to tell if you are lowcase/upcase rather than just an icon...

Comment 9

[Dale Harvey (:daleharvey)]

This is doing my head in, it can never have 'no performance impact', but it can be improved.

Comment 10

[Ben Francis [:benfrancis]]

(In reply to Dale Harvey (:daleharvey) from comment #9)
> This is doing my head in, it can never have 'no performance impact', but it
> can be improved.

Didn't someone say that we're still actually redrawing all the keys when you change case anyway? If performance really is the main argument then do we have numbers to back that up?

Comment 11

[Dale Harvey (:daleharvey)]

We are, but since they are drawing the same letters (all caps) there isnt any delay

Comment 12

[Ben Francis [:benfrancis]]

(In reply to Dale Harvey (:daleharvey) from comment #11)
> We are, but since they are drawing the same letters (all caps) there isnt
> any delay

Oh yes I remember someone saying now, the delay is still there, it just removes the perceived delay which is important.

Comment 13

[Patryk Adamczyk [:patryk] UX]

Attachment: Shift Key Proposal

Spoke to Josh, Francis and Jaime, this is our proposal.

Pressed
Arrow: #FFFFFF
Button: #004959
Button Highlight: #2b6875

Caps Lock:
Arrow: #333333
Button: #00aac8
Button Highlight: #2bb8d1

Comment 14

[Patryk Adamczyk [:patryk] UX]

Attachment: Shift Key PSD

Please ping Pavel if you need a 9slice of these buttons. But they should be using standard colours.

Comment 15

[Dale Harvey (:daleharvey)]

Sorry my mistake, didnt realise this bug tim opened to improve the 'notification' thing, will open a new bug for reinstating old behaviour

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Ben Francis [:benfrancis] from comment #12)
> (In reply to Dale Harvey (:daleharvey) from comment #11)
> > We are, but since they are drawing the same letters (all caps) there isnt
> > any delay
> 
> Oh yes I remember someone saying now, the delay is still there, it just
> removes the perceived delay which is important.

That's bug 875963 I believe.

Comment 17

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10382/files

Pointer to Github pull-request

Comment 18

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 762547 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10382/files

This is a CSS only change to make some style changes to the capsLock key so that it will be easier to identify its state.

Hi Tim,

Could you please review this?
Thank you.

Comment 19

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: screenshot of pressed (active) capsLock

Hi all,

Please be informed although the design might look better than the current implementation on screen, I found that it is not that obvious when I checked this on device (Otoro and Buri tested).

The main concern is #004959 for the background of pressed (active) capslock key
is too dark on device.

--
Pressed
Arrow: #FFFFFF
Button: #004959
Button Highlight: #2b6875
--

Can someone help to load this image on device and suggest some alternative color?
Thanks.

Comment 20

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 762547 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10382/files

I agree with Rudy that we should wait for UX feedback on the screenshot before landing this fix.

Comment 21

[Julien Wajsberg [:julienw]]

The same color won't look the same on any device, so we should not focus on specific devices. Instead we should calculate the contrast between both colors and see if that's enough... Of course UX are the right guys for that :)

Comment 22

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

ni to Patryk to get his attention.

Hi Patryk,

Could you or someone else be able to get to Comment 19?
Thank you.

Comment 23

[Alex Keybl [:akeybl]]

Not relevant to 1.1, since we don't have that bug on 1.1 right now.

Comment 24

[Patryk Adamczyk [:patryk] UX]

After seeing it on device, I do agree its a bit dim. Can we try one with increased contrast:

Button: #006a80
Button Highlight: #2b8395

Comment 25

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Patryk,

Thanks for your feedback.
I have modified the style according to your suggestion.

Merged to Gaia master,
https://github.com/mozilla-b2g/gaia/commit/4d97d245abb5ba2efc273ea395e47802c1769767