796413 - Keyboard layout doesn't match specs

Status: VERIFIED FIXED

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

Description

[GH to BZ]

[GitHub issue by rafaelrebolleda on 2012-07-23T08:43:50Z, https://github.com/mozilla-b2g/gaia/issues/2701]
More specifically, it doesn't match:

* Standard layout around the space bar
* Email layout
* URL layout

The specs have been available in [the wiki](https://wiki.mozilla.org/Gaia/System/Keyboard#Design_Spec) for a long while.

/cc @dcoloma, @lodr, @timdream, @RudyLu, @caseyyee

Comment 1

[GH to BZ]

[GitHub comment by timdream on 2012-08-14T09:02:48Z]
@RudyLu @lodr Can any of you work on the little differences on these? I suspect not all the differences is because of the implementation -- some of them being the fact that the spec is not up-to-date with info we decided since last meeting. Check with me or @caseyyee if in doubt.

Comment 2

[GH to BZ]

[GitHub comment by RudyLu on 2012-09-07T12:10:06Z]
Hi @rafaelrebolleda,
When implementing the keyboard of type URL, I encountered a problem,
Please refer to [this screenshot](http://i.imgur.com/0m4GU), which shows that we would have duplicate symbols shown when the user switches to the alternative layout of "number and basic symbols".

Could you please help define how to avoid this situation?
Thanks.

Comment 3

[GH to BZ]

[GitHub comment by rafaelrebolleda on 2012-09-07T14:20:50Z]
Sure!

I'm aware of the issue, but thought these refinements wouldn't make it into V1. If you're up to it, my idea is to provide simple alternate layouts in those occasions. That will probably imply having fewer keys per row.

Otherwise, we'll have to come up with different characters for those keys... I'm not sure we're going to have so many useful ones.

Comment 4

[GH to BZ]

[GitHub comment by RudyLu on 2012-09-12T06:37:44Z]
@rafaelrebolleda, 
 1. For "simple alternate layouts in those occasions", it will be much more complicated to implement it. 
     Besides, we have to define all the alternate layouts for URL, email, and maybe search type.

 2. I would suggest we put only the most important keys in the bottom row, such as
 `.`, `/`, `[space]`, and `.com` for URL type.

Comment 5

[GH to BZ]

[GitHub comment by autonome on 2012-09-25T01:18:39Z]
Hi @RudyLu, what's the status of this issue? When do you expect to be able to fix it by?

Comment 6

[GH to BZ]

[GitHub comment by rafaelrebolleda on 2012-09-27T15:54:49Z]
As mentioned in #3566, in which new specs are posted:

>I know some keys will be duplicated when switching to alternate keyboards (discussed in other threads), but unless someone tells me we can do *less, bigger* keys on those, I'd stick with what we have for the time being. It's not very elegant but we've got bigger fishes to fry right now.

Comment 7

[Walter Chen[:ypwalter][:wachen]]

This has been a issue since 2012/10/01. Keyboard design keep going out of control, including adding different style of keyboard and so on.

Like the bug I reported is one of the recently example of how the design should be done. (Bug 824139) If one just add a "@" to solve the issue, it would causing other issues like double "@" or one symbol disappeared.

Comment 8

[Joe Cheng [:jcheng] (please needinfo)]

Triage: BB-, Chris Lee minused the bug (assuming product has decided the current implementation is fine). 
Adding Josh to make sure this is fine to be different from UX spec. Please renom if changes needed.

Comment 9

[Josh Carpenter [:jcarpenter]]

Hi guys, I'll talk to Rafa and Casey and follow up on this.

Comment 10

[Josh Carpenter [:jcarpenter]]

Anyone working on this for Berlin work week, ping Casey and/or Rafa for the latest on what needs to be done.

Comment 11

[Joe Cheng [:jcheng] (please needinfo)]

it's blocking-basecamp-, not expecting the resource to be spent on this one. are you suggesting this is to be plused?

Comment 12

[Josh Carpenter [:jcarpenter]]

Hi Joe, we're per Andreas's day one intro, UX is tagging bugs that we'd like devs to address as they complete the remaining blockers. 

Casey and Rafa, I'm going to remove the "BerlinWW" tag from this until there is something actionable for devs to tackle. There's been no UX movement on this in a while, and other important keyboard bugs are still outstanding.

Comment 13

[Casey Yee]

Just to update this bug.

Myself and Raffa have decided that the current implementation is sufficient for V1 despite not matching the UX specs.    Any remaining issues have separate bugs filed so we can close this one out.

Comment 14

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

https://www.dropbox.com/sh/8u8nmhvgzkltc7l/97tNaPC1P8/System/Keyboard%20and%20Text