929361 - [Keyboard] Update Keyboard Visual Design

Status: RESOLVED FIXED

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

Description

[Eric Pang [:epang] UX]

Attachment: 1.3 Keyboard Spec.key

Update keyboard to new 1.3 visual design. Making the keyboard better on the current metric performance is the goal.

Comment 1

[Eric Pang [:epang] UX]

Psds for keyboard in portrait and landscape can be found here on box:
https://mozilla.box.com/s/ixxryt8pif0owzm489oh

Comment 2

[GoodMike]

Attachment: Feedback and questions from TPE UX team

Comment 3

[GoodMike]

Hi Eric,

Please see attachment "Feedback and questions from TPE UX team" for our feedback and question.
Thank you.

#1. Four Coloration Layer Design :
Is the purpose of the different color layer for dividing key rows ?
In this case, there is no need for physical lines to divide different row ?
It s fresh design, and good try.

#2 Contrast Issue
The contrast is not much a bit vague for visual perception and reading.
Since we are using grey icon over darkest row.
It’s like the icon and texts are melting into the background.

#3. Alt Layout
For keyboard with only one IME, our layout design will
replace IME key with comma.
More balanced visually and easy for input. ( See Mike’s Spec later)

#4. Long Press UI 
What’s the design gonna look
like when there are two rows ? 
Such as A may have a lot of different candidate letters or 
in the future we may have two layers after long press.

#5. Long Press UI Alignment
Suggest no overlap. This may cause visual noise. A soft reminder here.

#6 Alternate Language
The rectangle square doesn’t match current design.
Why not use round shape or round corner shape ? 
And second layer candidates are in horizontal direction.
Maybe it can be consistent. 
The numbers of IMEs should be limited and There may a IME Settings shortcut in the list. [ See Mike’s spec later ] 

#7.Hint text Suggestion 
1.Increate Font size for  reading friendly across different age of people.
2.More clear highlight. The contrast of selected word is not obvious enough.

Comment 4

[Eric Pang [:epang] UX]

(In reply to GoodMike from comment #3)
> Hi Eric,
> 
> Please see attachment "Feedback and questions from TPE UX team" for our
> feedback and question.
> Thank you.
> 
> #1. Four Coloration Layer Design :
> Is the purpose of the different color layer for dividing key rows ?
> In this case, there is no need for physical lines to divide different row ?
> It s fresh design, and good try.
> 
> #2 Contrast Issue
> The contrast is not much a bit vague for visual perception and reading.
> Since we are using grey icon over darkest row.
> It’s like the icon and texts are melting into the background.
> 
> #3. Alt Layout
> For keyboard with only one IME, our layout design will
> replace IME key with comma.
> More balanced visually and easy for input. ( See Mike’s Spec later)
> 
> #4. Long Press UI 
> What’s the design gonna look
> like when there are two rows ? 
> Such as A may have a lot of different candidate letters or 
> in the future we may have two layers after long press.
> 
> #5. Long Press UI Alignment
> Suggest no overlap. This may cause visual noise. A soft reminder here.
> 
> #6 Alternate Language
> The rectangle square doesn’t match current design.
> Why not use round shape or round corner shape ? 
> And second layer candidates are in horizontal direction.
> Maybe it can be consistent. 
> The numbers of IMEs should be limited and There may a IME Settings shortcut
> in the list. [ See Mike’s spec later ] 
> 
> #7.Hint text Suggestion 
> 1.Increate Font size for  reading friendly across different age of people.
> 2.More clear highlight. The contrast of selected word is not obvious enough.

Hi Mike, great feedback!  Going to redirect this to Przemek since he's the visual owner of the new keyboard designs :)

Comment 5

[Przemek Abratowski [:przemek] UX]

To prevent us from designing in the Bugs comment section I answered the above questions in an email to Mike, changes and adjustments might be made to the keyboard after we see the design on device. 

Pavel, For now please proceed with the design as originally specked. 

Thanks

Comment 6

[GoodMike]

Hi all, I have released ux spec and will complete internal discussion with Josh Carpenter and related ux people. Once we don't I will release the new spec. Prxemek's design will need to adjust on the spec but keep the visual design style. Przemek's design is a visual spec not ux spec.

Comment 8

[GoodMike]

Attachment: [Spec] Keyboard Layout_4 inch_v1.1.pdf

Keyboard UX Spec Release.

Comment 9

[Binyamin]

(In reply to GoodMike from comment #8)
> Created attachment 831272 [details]
> [Spec] Keyboard Layout_4 inch_v1.1.pdf
> 
> Keyboard UX Spec Release.

URL & Email keyboard ccTLD proposal (related to Keyboard Layout_4 inch_v1.1.pdf page 16):

1. While switching to different language keyboard, replace .com with language based ccTLD - for example show .es for Spanish keyboard, .il for Hebrew keyboard (maybe to avoid this purpose, because of "disturbing flicker"/switch mentioned in proposal 2.1).
2. Expand ccTLD choice on long click .com based on device Language settings + Browser history + localization. Still keep (do not remove) .com key from English keyboard.
Keep in mind not every user whose device interface is in English would ever surf domains .us, .uk, .gb and would still prefer .com
We need to prioritize ccTLD options:
 2.1 highest priority - always show localization based ccTLD - for example if located in Russia, expend .ru (if accepted proposal 1., keep in mind to avoid .ru duplication)
 2.2 second priority - show ccTLD comparing Language settings + Browser history (do not expend it to tens of options)

By keeping all this proposals, the real example for case Settings languages English, Spanish, Hebrew, Localization Israel, the must surfing domains .ru, .com :
 * in English keyboard - keep key .com, expend ccTLDs .he, .ru and do not expend .sp since Browser history does not find such domains
 * in Spanish keyboard - replace .com with .sp, expend .he, .ru, .com
 * in Hebrew keyboard - replace .com with .il, expend .ru, .com

Additional URL keyboard proposal (related to Keyboard Layout_4 inch_v1.1.pdf page 16):
Replace key ":" with "-", since the real live use case much more can be "-" than ":". Character "-" is often noticeable in URLs, but ":" almost never.

Comment 10

[Przemek Abratowski [:przemek] UX]

This Bug was intended for the visual design changes covered in the original spec attached by Eric Pang, Mike you are requesting other changes then those covered in the original visual design spec please create a new Bug that outlines the new features and interaction changes that you're looking for.

The point of this bug is just to take the current 1.2 keyboard visual style and update it, as covered in " 1.3 Keyboard Spec.key"

Thank you
Przemek

Comment 11

[Stephany Wilkes]

Note for triage: This bug is for the scope of work Przemek described. Bugs should be evaluated against this visual design spec.

Comment 12

[Casey Yee]

Taking the visual updates for keyboard.

Comment 13

[Casey Yee]

Attachment: bug-929361.jpg

Screenshots of patch,

Comment 14

[Casey Yee]

Clearing VD review flag.
We have agreement with visual to go with this. 

Flagging for code review.

Comment 15

[Casey Yee]

Attachment: Patch for Gaia/master

Comment 16

[David Flanagan [:djf]]

Back from Thanksgiving vacation and will try to review soon, but am tied up with a koi+ bug right now, so it will be a day or two before I can get to this. 

I'm not a particular expert on the current CSS for the keyboard, so feel free to find another reviewer if you can't wait.

Comment 17

[David Flanagan [:djf]]

Comment on attachment 8339579 [details] [review]
Patch for Gaia/master

I didn't understand the existing CSS, so don't have many comments on the new CSS that has replaced it.  But I did leave a few nits on github to be addressed.

I'm giving r- because of these more serious issues:

1) If I press and hold on the O or I or L keys (in the English layout) the list of alternatives goes off the right edge of the screen.  In the old keyboard, alternatives for keys on the right side of the keyboard would extend to the left. (I don't seem to be able to generate a screenshot while also holding my finger down on the key, so I can't show you this).

2) The shift key is highlighted for single character shift, but is not highlighted for caps lock.  The unshifted case and caps locked cases look the same.

3) Using text-transform:uppercase in the CSS does bad things to the alternatives for the number keys.  Pressing and holding on 2 shows me "2ND" instead of "2nd".  Presumably you want text-transform: capitalize. Similarly, check the "l.l" alternative on the Catalan keyboard.

4) Actually, if you hold down the S key, you'll see an alternative "SS".  This is the capital form of the German letter ß.  I think we really need that to appear uncapitalized. So text-transform: capitalize might not do what you need, either. I guess maybe you can just not capitalize the alternatives.  Though it would be nice to capitalize them if the shift key is active.

I've also found a couple of visual nits:

a) When the keyboard is displaying long word suggestions (type 'mississip', e.g.) the margin on the left is bigger than the margin on the right.

b) When I press and hold the N key, there are just two alternative characters.  They are close together and it takes only a tiny finger movement to switch from one to the other.  When the alternatives pop up, they are different colors, but it is not clear which is the selected color and which is the unselected color.  This isn't an issue when there are 3 or more alternatives, of course.

Comment 18

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

Hi Casey, David,

Just want to add that it should not be necessary to add the following rule,
text-transform: capitalize or uppercase 

We have switched to a JS-based solution to make the keyboard displayed as "all uppercase", which is Bug 931578.

Comment 19

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

Comment on attachment 8339579 [details] [review]
Patch for Gaia/master

Seems David beat me to it. :)

Comment 20

[Casey Yee]

Thanks for the feedback guys, I'll have updates coming soon.

Comment 21

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

Casey,

Bug 908329 is the bug that modify the width of the alternative key.
It seems it would only affect the right-most and left-most key or when it only contains one single alternative key.

Comment 22

[Casey Yee]

I've addressed all the concerns on github as well as all but one item in comment 17:

> b) When I press and hold the N key, there are just two alternative
> characters.  They are close together and it takes only a tiny finger
> movement to switch from one to the other.  

It seems to me that the logic that writes the key width styles onto the element seems to be at fault here.    The "N" alternate keys are too small, while the "L" alternate keys are larger but disproportionate to each other.   I really don't understand what is going on here but as per Rudy in Comment 21, this only seems to effect the right-most and left-most keys.   

> When the alternatives pop up,
> they are different colors, but it is not clear which is the selected color
> and which is the unselected color.  This isn't an issue when there are 3 or
> more alternatives, of course.

Visual designers have noted this problem.   One possible solution is to add a triangle shape to the bottom of the selected key to indicate the current selection.  

The above remaining issues will be addressed as separate bugs and VD has given the go-ahead to continue with what we have here.

Flagging David for another review round.

Comment 23

[Casey Yee]

Attachment: bug-929361.jpg

Comment 24

[David Flanagan [:djf]]

Comment on attachment 8339579 [details] [review]
Patch for Gaia/master

This looks really good.  r+ provided that you file a followup bug to get the width right on the accented characters.

The desired behavior, at least in the old case, was that the first (leftmost or righmost) alternate letter should be as wide as the key from which it appeared.  We had problems before where if you typed on the edge of a key you might end up selecting the second alternate instead of the first.  The goal is that users get predictable results if they press and hold a key. They never get the second alternate unless they press, hold, and move their finger.

Comment 25

[Casey Yee]

Patch is in:
https://github.com/mozilla-b2g/gaia/commit/215febd4fcfda2f417b17437bf884459340cbf6f

Thanks everyone!

Comment 26

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

I have seen this just got backed out because of Bug 947059, which I already prepared a patch for it.

Comment 27

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

Change this to REOPENED, since the patch just got backed out with,
https://github.com/mozilla-b2g/gaia/commit/a2daf2be8d930df614f1cda83b8dbc911e97bac7

Comment 28

[Casey Yee]

new pull request here:
https://github.com/mozilla-b2g/gaia/pull/14437

This will resolve the test issues.

Comment 29

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

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

Casey, thank you.