810306 - Display capital letters only (never lower case)

Status: RESOLVED DUPLICATE of bug 860318

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

Comment 1

[Sergi]

Attachment: Keyboard : Capital Letters :: Screenshot

Comment 2

[Sergi]

The keyboard should always display capital letters. The way to display  whether if caps is activated or not is using the states available for the caps button.

Comment 3

[Casey Yee]

Why not?   I find it very useful to at a quick glance whether the keyboard is shifted.

Comment 4

[Sergi]

It was designed this way for a better visualization of the keys in small screens. Right now the way to reflect whether CAPS is activated or not is by the different states designed for that key. 

Anyway i will leave this one to @Steve in order for him to say if this bug is still valid.

Comment 5

[Sergi]

Besides better visualization it's also a matter of improving users typing speed. Real keyboards (let's say the one in your laptop), don't change form upper to lower case, they just indicates you whether you have caps lock activated or not. I think this improves typing speed because the system doesn't change back and forth form upper to lower case letters when, for example, letters following punctuation get auto-capitalized.

Anyway, that's my take on this issue

Comment 6

[Josh Carpenter [:jcarpenter]]

Agreed. Steve and I spoke about this in SF, IIRC. It's a bit subjective, admittedly (like debates over physical keyboard types), but I believe the case for always-uppercase is strong. 

1) Switching is jarring. 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. The advantage cited ("I can glance at the keys and see what mode I'm in") is actually a symptom of a false need _created by_ the Android implementation. The switching forces (compels) the Android user to spend more time glancing at the keyboard to determine what mode they're in, when the optimal solution is to handle it automatically, and let the user think about what they're typing; not what mode they're in.

2) Lower case characters are also harder to quickly scan and recognize. They have better visual differentiation between individual characters, it's true, but at the sizes we're dealing with that breaks down, and all caps become more reliably legible.

I'm strongly in favor of this change. Flagging Rudy for needinfo on who can do the work needed.

Comment 7

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

I can handle this change if this request got priority.
Please nominate this as leo+ or at least tracking-b2g to get higher priority.

Thanks.

Comment 8

[Josh Carpenter [:jcarpenter]]

Thanks Rudy. The UX team will follow up on this in the next 48 hours once we've gotten internal alignment.

Comment 9

[tofumatt [:tofumatt]]

What's the follow-up on this? This is a pet-peeve of mine for non-iOS keyboards and I'd love to see this approved. Hell, I'd work on the patch if no one else has code for it.

Comment 10

[Josh Carpenter [:jcarpenter]]

We'll take another look at this with the profiler. I'm concerned that the time to switch is exacerbating our performance problems.

Comment 11

[Mike Lee [:mlee]]

Jed,
Did you ever work with Josh to profile this?

Comment 12

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

No, we haven't profiled this yet.  Also, note that the keyboard-uppercasing changes I've seen just use a CSS text-transform, so there will still be separate DOM trees for the upper- and lower-case keyboards, so I wouldn't expect much difference.

Comment 13

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Jed Davis [:jld] from comment #12)
> No, we haven't profiled this yet.

Wrong!  I filed bug 863662, with data attached, while at the work week in Madrid.  (And then completely forgot about it.  I blame jetlag.)

But there may have been changes to the keyboard code that affect this, and they may or may not have been uplifted from gaia master to v1-train.

However, this part of the previous comment stands:

> the keyboard-uppercasing changes I've seen just use a CSS text-transform, so there will still be separate DOM trees for the upper- and lower-case keyboards, so I wouldn't expect much difference.

Comment 14

[[:fabrice] Fabrice Desré]

That's really a bad decision. I've been using a unagi as my only phone for months, and have not a particularly good eyesight, but switching to an always all caps keyboard is clearly a regression. 

How many UX people here have lived with this phone & keyboard *for real* ? I see no objective justification for this change, while the experience of several people that have used the phone argue in favor of displaying lowercase letters.

Comment 15

[tofumatt [:tofumatt]]

Look at the iOS keyboard, the Mac keyboard, many PC keyboards... capital letters have a more consistent size and height, lending a much more uniform an aesthetically pleasing design to the keyboard.

The uniform look of each key makes it look much less of a hodgepodge of letter soup, which is what many Android and the Firefox OS keyboards look like to me.

Comment 16

[tofumatt [:tofumatt]]

Side note: I'm also used to scanning many keyboards for capital letters so I find it easier to visually scan an uppercase keyboard, but that is more of a "good UX is consistent" thing, and may only apply to those with experience in mostly-uppercase keyboards.

Comment 17

[Ben Francis [:benfrancis]]

As I see you have taken care to justify this design decision, let me be a bit more objective than simply accusing you of being members of some weird cult ;)

(In reply to Josh Carpenter [:jcarpenter] from comment #6)
> 1) Switching is jarring. 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.

If the keys moved position, size or shape then I think you could argue it was jarring, but it is only the labels that change. Why is this any more jarring than switching between number and symbol modes? The function of the buttons is changing so the labels of the buttons change to reflect that.

> The advantage cited ("I can glance at
> the keys and see what mode I'm in") is actually a symptom of a false need
> _created by_ the Android implementation.

Having a visual indication of what case your keyboard is in is certainly a valid need and changing the labels on the keys is an effective way to communicate this information. So it really comes to down to whether it is jarring or not.

To that point I would counter the argument given by hypothesising that the reason iPhone users find it jarring is because they are used to having a virtual keyboard which always displays capital letters, regardless of what case they are entering. So let's examine the justification for this...

> 2) Lower case characters are also harder to quickly scan and recognize. They
> have better visual differentiation between individual characters, it's true,

These two points seem to cancel each other out...

> but at the sizes we're dealing with that breaks down, and all caps become
> more reliably legible.

...so the remaining argument is that the lower case letters are not legible at this scale. If this hypothesis is supported by user testing then can we perhaps address this problem in another way, by changing the style or size of the typography for example?

> The switching forces (compels) the
> Android user to spend more time glancing at the keyboard to determine what
> mode they're in,

I would argue that what is important is not the length of the saccade of the eyes, but the level of attention needed. Noticing a more obvious change apparent through peripheral vision requires less cognitive effort than looking for a subtle change of only a few pixels on one button.

> when the optimal solution is to handle it automatically,
> and let the user think about what they're typing; not what mode they're in.

Requiring the user to remember which mode they are in rather than displaying it on the buttons they are pressing just gives them another piece of information to store in their short term memory.

(In reply to Sergi from comment #5)
> Real keyboards (let's say the one in your laptop), don't change form
> upper to lower case, they just indicates you whether you have caps lock
> activated or not. 

Physical keyboards don't do this because it's a limitation of a medium dating back to 1873, the keys don't have pixels. They also show both numbers and symbols together on the same key, should we do this too? I don't think this is a strong argument.

> I think this improves typing speed because the system
> doesn't change back and forth form upper to lower case letters when, for
> example, letters following punctuation get auto-capitalized.

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.

(In reply to tofumatt [:tofumatt] from comment #15)
> Look at the iOS keyboard, the Mac keyboard, many PC keyboards... capital
> letters have a more consistent size and height, lending a much more uniform
> an aesthetically pleasing design to the keyboard.
> 
> The uniform look of each key makes it look much less of a hodgepodge of
> letter soup, which is what many Android and the Firefox OS keyboards look
> like to me.

The affordances of what a button does based on its label and the ability of the user to quickly distinguish between different letters seems more important than having a uniform appearance.


Trying to be objective as possible I would say that if I had never used a keyboard which updated the labels to reflect the function of the buttons then I would indeed feel less strongly about having that feature. But then if I'd never had a right arm I might feel less strongly about losing that too.

Comment 18

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

Given the fact this change has landed with bug 860318, I am going to set this as a dup.

I am not going to challenge design decisions made, but I personally think what we need is to make the cyan color of the shift key more noticeable. If iPhone was considered as a reference design, we should reference _the whole thing_.

Comment 19

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

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #18)
> I am not going to challenge design decisions made, but I personally think
> what we need is to make the cyan color of the shift key more noticeable. If
> iPhone was considered as a reference design, we should reference _the whole
> thing_.
> 

I have filed bug 874800 so we could continue the conversation there.

Comment 23

[William Hsu [:whsu]]

Verified it. Thanks!
Attaching the screenshot.

* Verified build:
 - Gaia      3a41d9c2c6dce6a5a248495a1847f8eaa703ef83
 - Gecko     http://hg.mozilla.org/mozilla-central/rev/171857e7e334
 - BuildID   20140112040202
 - Version   29.0a1

Comment 24

[William Hsu [:whsu]]

Attachment: Keyboard_20140113.png

Comment 25

[jezra]

I am the owner of a ZTE Open (a small screen device) and I use it daily and I wear corrective lenses. As a user, I expect the key displayed on my keyboard to be the character that will result when I press the key. If someone is going to make a design decision like this, please include an option somewhere to let the owner/user decide the best way to display characters on the keyboard.

Comment 26

[Jim Porter (:squib)]

(In reply to jezra from comment #25)
> If someone is going to make a design decision like this, please include an
> option somewhere to let the owner/user decide the best way to display
> characters on the keyboard.

Now that users can install third-party keyboards, I'd say we already do let the user decide how their keyboard should work.

Comment 27

[jezra]

(In reply to Jim Porter (:squib) from comment #26)
> (In reply to jezra from comment #25)
> > If someone is going to make a design decision like this, please include an
> > option somewhere to let the owner/user decide the best way to display
> > characters on the keyboard.
> 
> Now that users can install third-party keyboards, I'd say we already do let
> the user decide how their keyboard should work.

"if you don't like it, use something else" is not the same as "go into keyboard settings and uncheck 'display in ALL CAPS'"

Comment 28

[Jim Porter (:squib)]

Adding an option to this is the last thing I'd want to see, since that just adds more maintenance burden for a feature that I really doubt most people would toggle. It should be one way or the other.

I lean slightly towards showing lower-case letters when appropriate, but only because password entry can be painful otherwise. For other uses, I haven't found myself paying attention to the case of the letters, since it's usually right anyway. But then I'm not a UX designer.

Comment 29

[jezra]

As a daily user, who just had WYSIWYG keyboard character display removed, I would love to be able to make this decision myself. 

While this may be "a feature that I really doubt most people would toggle", I as an owner, and everyday user for the past 3 months, would definitely use the toggle.

Comment 30

[Worik Stanton]

I agree with jezra. This is not a duplicate of 860318, this issue is very specific and 860318 is general.

I assumed that the keyboard changed between 1.1 and 1.3 (I went from 1.1 to 1.3) because of patents (getting cynical...).  I find it very useful and I want it back

Comment 31

[Mike Habicher [:mikeh] (high bugzilla latency)]

When I first noticed the change from a mixed-case keyboard to an ALL-CAPS one, I thought it was a bug.

(In reply to Jim Porter (:squib) from comment #28)
>
> Adding an option to this is the last thing I'd want to see, since that just
> adds more maintenance burden for a feature that I really doubt most people
> would toggle. It should be one way or the other.

Are we really ruling out a simple* option like this unless we can empirically say that 50% of users will flip this toggle?

*for my admittedly uninformed value of "simple". :)

Comment 32

[Jim Porter (:squib)]

(In reply to Mike Habicher [:mikeh] from comment #31)
> Are we really ruling out a simple* option like this unless we can
> empirically say that 50% of users will flip this toggle?
> 
> *for my admittedly uninformed value of "simple". :)

This is perhaps my experience from Thunderbird speaking, where users often have requests like this (i.e. "just add an option for those who want it"), and we rapidly approached death by a thousand cuts. Especially given how much there is to do on other features that affect *everyone*, I'd rather not see us get bogged down by adding extra options.

Besides, if there are real usability issues with the way the keyboard is now, we should just fix them, period. Adding an option only helps the people who know enough to look for the option. I do agree that making the "shift" arrow blue probably isn't enough, especially since it's not much different looking from the gray, unshifted state. I'm not convinced that changing the case of the keys is the right way to go though, since that doesn't tell you whether you're in "Shift" mode or "Caps Lock" mode. One nice thing about old feature phones is that they showed the state of the keyboard right next to where you were typing, which made it easier to keep track of.

Comment 33

[jezra]

However, this isn't exactly a case of "just add an option for those who want it", it is more a case of "add an option for those who want it back because it should never have been removed in the first place". 

This was very usable keyboard functionality that was taken away from the users.

Comment 34

[[:fabrice] Fabrice Desré]

I complained loudly when we moved to lowercase-only, but that was done for performance reasons. I think we should revisit this decision if we have adequate performance with a lower/upper keyboard.

Comment 35

[Chris Mills [:cmills]]

FWIW, I always thought the upper-only keyboard was a bug that would be fixed at some point. I'd much prefer to be able to use upper/lower case, but perhaps this is just because I have used Android much more than iOS.

I don't see it as a huge problem, but i can see how this would matter a lot to some people. I really think adding an option to change between the two would be good.

Comment 36

[Henrik Skupin [:whimboo][⌚️UTC+1]]

So performance issues have been mentioned here for switching between lower and uppercase keyboard layouts. But on bug no comment really mentions how large this impact actually is. All what I see is that people mention impacts. Has anyone actually measured those? Also with the fix on bug 875963 the performance should have been improved a lot. Maybe Jan can give us some numbers here.

Also here an excerpt from bug 860318 comment 15 which was done by Josh Carpenter:

> (In reply to Fabrice Desré [:fabrice] from comment #11)
> > Is it expected that the keyboard only displays UPPERCASE letters even when
> > entering lowercase ones? That's pretty broken imho, so I'm backing this out.
> > 
> > https://github.com/mozilla-b2g/gaia/commit/
> > 447cdaa4656d6a830f5bd129be0ac0c755fa6153
> 
> This is intentional. For prior art comparison, try iOS vs Android.

The question is if all what Apple does is good. But as of now we have a totally different user base. The question is how they feel about this change. We haven't released 1.2 yet, so we might lack feedback on that. But once that happened I wonder how our user base on 1.2 will react. 

Also I agree that this is not a dupe. Main reason is that this bug is not about having capital letters only, but is requesting exactly the opposite. This bug is about to get back the upper/lowercase keyboard. So marking as regression by bug 860318 (compared to v1.1) and adding dependency. If we really cannot go this way, it should become at least a Wontfix.

But before we do this, I think what would be really helpful is to re-check which performance impacts we really have as of today and if it really makes sense to always call out those impacts when there is an upcoming discussion about which keyboard layout we support. As mentioned above, so far I don't see any numbers for that.

Comment 37

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Sorry, that was the wrong bug. Actually I wanted to comment on bug 883340. Restoring latest bug settings.

Comment 38

[jezra]

(In reply to Chris Mills from comment #35)
> FWIW, I always thought the upper-only keyboard was a bug that would be fixed
> at some point. I'd much prefer to be able to use upper/lower case, but
> perhaps this is just because I have used Android much more than iOS.
> 
> I don't see it as a huge problem, but i can see how this would matter a lot
> to some people. I really think adding an option to change between the two
> would be good.

To give some perspective of my "user story", I have never used Android or iOS until a few days ago when I was gifted an HTC device. The ZTE Open is my first device without a hardware keyboard. It is also the second mobile phone that I have owned, and my first smart-ish phone.  
Am I the target market for such a device?