951920 - [Keyboard] Sizing on alternate keys menu for first and last characters are not correct.

Status: RESOLVED FIXED

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

Description

[Casey Yee]

When a user press-and-holds a keyboard key for the alternate key menu, the first and last characters are too small in size due to the radius applied to the menu.   

To solve this issue, the first and last alternate key characters need to be wider so that when the radius is applied to the menu, the keys maintain a reasonable size.

This pretty much applies to any key with more than 2 alternates.  eg: S: [ßśš$], I: [ïíìîīį], O: [öóòôōœøɵ], etc.

In the case of a key with 2 alternates eg: N: [ñń], the alt keys are too small and need to be wider.

In the case of a key with 1 alternate eg: R: [R$], the width of the alternate is too small creating a oval-like shape.   The key should be the same width as a standard key highlight (appearing round).  The same issue is present in ?: [¿], !: [¡], 0: [º].

The above behavior is not completely consistent though eg: L: [ł£] displays a narrow "ł" and the a wider "£".

Comment 1

[Casey Yee]

Attachment: bug-951920.jpg

Example of keyboard glitches with desired key sizing.

Comment 2

[Stephany Wilkes]

Adding a ni? for Hema to see if this is something David could work on for Friday. UX would also like to nominate this for 1.3+, as it's a 1.3 bug as it is.

The pop-up window after long tap "?" in symbol panel seems to be incorrect. It should be in "round shape" not "capsule shape."

The problem has to do with the platform calculating alternate key widths incorrectly and occurs on the left-most or right-most alternate keys (or just the single key). It actually goes both ways, sometimes the alternate keys are too wide, sometimes too narrow.

Comment 3

[Stephany Wilkes]

And to explain UX blocking rationale a bit further: We originally marked this as blocking the 1.4 VSD bug (above) as we thought this fix could not get in for 1.3 in time. However, the bug that's causing this was found in 1.3, and so we prefer that a fix for this bug be 1.3+ and not wait until 1.4 if at all possible.

Comment 4

[Hema Koka [:hema]]

Looks like Casey has already brought this up with David and it is in his list to look into

Comment 5

[David Flanagan [:djf]]

I spent my time working on a 1.1hd blocker and ran out of time for this bug, so I won't be able to look at it until January.

The relevant code for special casing the size of alternative keys is in apps/keyboard/js/render.js:584
Apparently that code no longer works right with the new CSS, and we'll have to change the JS and maybe also the CSS.

Comment 6

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

Hi Casey this sounds like a follow-up to bug 929361, do you have time to do this on your own on the orignal keyboard app and let djf to fix this in his new keyboard codebase altogether alone? If not I can try to work out resourcing.

Triage: +'ing to complete the visual refresh.

Comment 7

[David Flanagan [:djf]]

Tim,

I already told Casey I'd fix this.  I had hoped to get it done before the holiday, but will work on it tomorrow.

Comment 8

[David Flanagan [:djf]]

Attachment: link to patch on github

Casey: please try out the patch and see if it fixes the visual issues you wanted fixed.

Rudy: I thought this would be a simple CSS patch that Casey could review, but I needed to make non-trivial JS changes to handle the new alternatives menu visuals.  The biggest change is the removal of the unused menu layout code. The next biggest change is the menuLockedArea code and the way I use new properties of that object to redirect events to the right alternative button.  This gives us a better way of ensuring that the first (or last) alternative is always highlighted when the menu pops up.

Comment 9

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

Comment on attachment 8355719 [details] [review]
link to patch on github

This looks good on portrait mode, but in landscape, it seems the alternative key is a little bit too small.

I'll leave this to Casey for detailed UI review.
Thanks, David.

Comment 10

[David Flanagan [:djf]]

Thanks, Rudy. I forgot to test in landscape.  I'll be sure to fix that issue before landing.

Comment 11

[Casey Yee]

Comment on attachment 8355719 [details] [review]
link to patch on github

Looks great David :)  Thanks for your work on this one!

Comment 12

[Casey Yee]

(In reply to Rudy Lu [:rudyl] from comment #9)
> Comment on attachment 8355719 [details] [review]
> link to patch on github
> 
> This looks good on portrait mode, but in landscape, it seems the alternative
> key is a little bit too small.
> 
> I'll leave this to Casey for detailed UI review.
> Thanks, David.


I just checked landscape and it does look like the alt keys are about 10-15% too small in height.

Comment 13

[David Flanagan [:djf]]

The size of the alt keys in landscape mode is not affected by this patch. That issue predates this bug, and I suggest that we handle it as a separate bug and land this one as-is.

The main reason that I say this is that it is not at all clear what the right thing to do in landscape is. We could increase the size of the alternative characters to make them match the blue circle popups for each key, or we could decrease the size of the blue circle popups to match the alternative characters.  Note that the alternative characters do match the text on the keys themselves. But they are smaller than the text in the blue bubbles for each key.

Here's what is happening (assuming I'm understanding the code right): when we switch to landscape we redefine 1rem from 10px down to 7.5px. This is why the rows of the keyboard are less tall in landscape mode.  The keys theselves are wider because they expand to fill the available width.

When we go to landscape, we increase the text on the keycaps (and the alternative character popups) from 2.4rem to 2.8rem.  But because rems are re-defined, that is 24px to 75% of 28px: actually a decrease in size to 21px.  The height of the alternative characters menu shrinks more dramatically, however, from 30px to 22.5.

The blue bubbles are scaled differently, however.  The size of the bubble itself goes from 56px to 52.5px.  And the text inside the bubble goes from 28px to 26.25px.

So I'd say that it is not the alt chars menu that is too small but the blue bubbles that are too big.

It shouldn't be hard to fix, but I'm not qualified to decide how to fix it. And I think we ought to just handle it in a separate bug.

Comment 14

[David Flanagan [:djf]]

Landed to master: https://github.com/mozilla-b2g/gaia/commit/3d27ec08f47652d181f9653366143adc772c84bd

Comment 15

[David Flanagan [:djf]]

Uplifted to v1.3: https://github.com/mozilla-b2g/gaia/commit/522779225e86b7a4d1bf759036678dc321a1486e

Comment 16

[Casey Yee]

I agree, let's address the sizing of the alt keys in another thread.

Thanks for the patch David!