please give me back the keyboard with lower case letters !

[Julien Wajsberg]

Hi,

recently the keyboard changed for an all-uppercase keyboard, I find that
this is quite inconvenient. Having the lowercase/uppercase letters makes
it very easy to know if the next key will be uppercase or lowercase.

With the current way we don't see this as clearly, the only way to see
it is with the "shift" key, and it's not convenient at all because
usually the hand is over it and therefore we don't see it.

As a dogfood user I find that this was a bad idea, sorry...

Thanks,
--
Julien

[Gregor Wagner]

+1

Entering passwords was already an annoying task but now I want to throw my phone out
the window during typing my LDAP password.

-Gregor

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

[Fabrice Desre]

I complained in the bugs (860318 and 810306) also, but UX says we're
gonna love it because iPhone does that. It's really time to enforce UX
people to dogfood.

Fabrice

--
Fabrice Desré
b2g team
Mozilla Corporation

[Ben Francis]

I've tried to put across an argument for why this change is bad in this
comment https://bugzilla.mozilla.org/show_bug.cgi?id=810306#c17

No response from UX yet.

Ben Francis
http://tola.me.uk

[Kevin Grandon]

I could go either way on this. I do understand not wanting to jog the entire keyboard UX due to a shift change, but on the otherhand the current solution is not enough. If we do keep the current solution, we need a much bigger notification that caps are enabled. The tiny little blue arrow isn't enough.

-Kevin

[Julien Wajsberg]

just commented on https://bugzilla.mozilla.org/show_bug.cgi?id=874800.

I could live with the new behaviour for normal input, I don't change the
case myself so often. I think this is especially useful for passwords,
and we can know that an input is of the password type. So maybe that's a
possible compromise.

Thanks Fabrice and Ben for the pointer to the bugs !

Le 23/05/2013 20:32, Ben Francis a écrit :
> I've tried to put across an argument for why this change is bad in this
> comment https://bugzilla.mozilla.org/show_bug.cgi?id=810306#c17
>
> No response from UX yet.
>
>
> On Thu, May 23, 2013 at 7:16 PM, Fabrice Desre <fab...@mozilla.com> wrote:
>

[Josh Carpenter]

Hey folks, I'll chime in here quickly (just in meeting) as the lug who made the call on this.

This was debated among the UX'ers. Some people love all caps, others like the upper-lower switching of Android and Windows. What eventually forced our hand were performance issues. In Madrid we were determined to solve a batch of nasty keyboard delays that in aggregate made text entry feel terrible. Before we made this switch there were noticeable delays in the rendering of keys when switching between upper and lower (or vice versa), to the degree that I'd be typing lower case while the keys still showed upper. This obviously made the keyboard feel jarring and slow. By keeping the keys upper case at all times, we resolved that perceptible delay.

> It's really time to enforce UX people to dogwood.

FWIW Casey and I live on FFOS as our daily devices. What I was referring to in that comment was: we have many years of prior art here on iOS and BB platforms indicating that this is not an issue for the average user. If you're coming from Android it may feel jarring at first, and if you're doing compacted LDAP password entry it may be slightly sub optimal, but I think you'll find that you habituate over time. This is how our physical keyboards work, after all. You can also just look at the text in the text field to confirm you're in the correct case (even in the case of passwords, where the most recent character should be shown).

>>> With the current way we don't see this as clearly, the only way to see
>>> it is with the "shift" key, and it's not convenient at all because
>>> usually the hand is over it and therefore we don't see it.

So we can definitely look at making the Shift key highlighting more prominent. We'll talk with the visual team about this and see what we can do to optimize this.

Im happy to converse about this; just have to hop back into call here. Feel free to ping back here or directly!

—
Josh Carpenter
UX Lead, Firefox OS
Mozilla

[Faramarz Rashed]

i think it's a great idea to provide feedback to UX and they can incorporate all and everyone's input into their process and decision making. ultimately though, let's leave the decision to the area of expertise. i trust josh and UX team's call in this matter...

faramarz

On May 24, 2013, at 9:17 AM, Gabriele Svelto <gsv...@mozilla.com> wrote:

> Hi all, just wanted to add my 2eurocents to this discussion, see my inline comments:

>
>> This was debated among the UX'ers. Some people love all caps, others
>> like the upper-lower switching of Android and Windows. What
>> eventually forced our hand were performance issues.
>

> From my POV we should have focused on fixing the performance issue. That being said it's true that the previous behavior showed some lag when switching keyboards but since the output was consistent it never bothered me much.

>
>> What I was
>> referring to in that comment was: we have many years of prior art
>> here on iOS and BB platforms indicating that this is not an issue
>> for the average user.
>

> IMHO this is not a valid rationale for the markets we'll be launching in. In those markets feature phones are popular and Nokia ones in particular while very little people will have experience of iOS or BB. All of those phones clearly show uppercase/lowercase letters when writing and this applies both to models with a physical keyboard (were you can see a 3-characters preview of the case such as Abc, ABC or abc) and to those with a touchscreen (like the Asha line and older S40/S60 phones).
>
> Gabriele

[David Flanagan]

Please see also bug 875963. It appears that there is no actual
performance gain from the switch to all caps: our code is still tearing
down and rebuilding the entire keyboard every time the case is changed.
If we make apps/keyboard/js/render.js smart about switching case without
rebuilding itself (using a CSS text-transform, for example), we could
make the keyboard faster than it is today even if we went back to the
uppercase/lowercase behavior.

David

[Josh Carpenter]

(Sorry, a brief response again... in meeting)

> Please see also bug 875963. It appears that there is no actual performance gain from the switch to all caps: our code is still tearing down and rebuilding the entire keyboard every time the case is changed. If we make apps/keyboard/js/render.js smart about switching case without rebuilding itself (using a CSS text-transform, for example), we could make the keyboard faster than it is today even if we went back to the uppercase/lowercase behavior.

It's a perceived performance gain. We hide the delay. The actual switching delay is still happening in the background and needs to be addressed, but the user doesn't see the delay in the key cases switching because we stay in upper-case.

Continuing on issue of perf, we've had heroic efforts from yourself, Rudy, Pavel, Margaret, Jed, Sam and others to improve it, and it's much better, but there's definitely still room for improvement. Both to responsiveness (100ms should be the time it takes to display a key popup and render the character to the text field after pressing a key), and to perceived performance (we're targeting dynamic hit targets—among other improvements—for v1.2).

—
Josh Carpenter
UX Lead, Firefox OS
Mozilla

[Josh Carpenter]

> If we make apps/keyboard/js/render.js smart about switching case without rebuilding itself (using a CSS text-transform, for example), we could make the keyboard faster than it is today even if we went back to the uppercase/lowercase behavior

Meant to also add: yes, let's do this :)

—
Josh Carpenter
UX Lead, Firefox OS
Mozilla