Closed Bug 874800 Opened 9 years ago Closed 9 years ago
With capital letters only keyboard keys, it's very hard to tell it's state, especially when typing password
312.31 KB, image/jpeg
2.39 MB, image/vnd.adobe.photoshop
376 bytes, text/html
21.84 KB, image/png
+++ This bug was initially created as a clone of Bug #810306 +++ Read discussion on the cloned bug and bug 860318.
> 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 ?
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 ?
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.
Flags: needinfo?(jcarpenter) → needinfo?(fdjabri)
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.
I'm still not getting used to this behavior ...
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.
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.
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...
This is doing my head in, it can never have 'no performance impact', but it can be improved.
Assignee: nobody → dale
(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?
We are, but since they are drawing the same letters (all caps) there isnt any delay
(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.
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
Please ping Pavel if you need a 9slice of these buttons. But they should be using standard colours.
Sorry my mistake, didnt realise this bug tim opened to improve the 'notification' thing, will open a new bug for reinstating old behaviour
Assignee: dale → nobody
(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.
Pointer to Github pull-request
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.
Attachment #762547 - Flags: review?(timdream)
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 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.
Attachment #762547 - Flags: review?(timdream) → review+
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 :)
ni to Patryk to get his attention. Hi Patryk, Could you or someone else be able to get to Comment 19? Thank you.
Not relevant to 1.1, since we don't have that bug on 1.1 right now.
blocking-b2g: leo+ → -
After seeing it on device, I do agree its a bit dim. Can we try one with increased contrast: Button: #006a80 Button Highlight: #2b8395
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
You need to log in before you can comment on or make changes to this bug.