Closed Bug 825289 Opened 11 years ago Closed 10 years ago

Some fields in "Add Contact" enable word suggestions but aren't useful

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-basecamp:-, b2g18+)

RESOLVED FIXED
2.1 S7 (24Oct)
blocking-basecamp -
Tracking Status
b2g18 + ---

People

(Reporter: cjones, Assigned: mai)

References

Details

(Whiteboard: interaction [UX-P3])

Attachments

(2 files)

Grr, thought I filed this a long time ago.

 - First name / Last name
 - Zip code

These aren't useful currently.  See bug 825133 for a potential solution.

bb? -> radar
blocking-basecamp: ? → -
tracking-b2g18: --- → +
well, for the givenName it can be useful to enable the word suggestions provided the dictionary is able to match the most common givenNames. For family name and company name I agree.
Assignee: nobody → jmcf
Status: NEW → ASSIGNED
Attached file Pointer to GH PR #7390
Attachment #699269 - Flags: review?(timdream+bugs)
Comment on attachment 699269 [details]
Pointer to GH PR #7390

redirect to :djf, who did most of the word suggestions work.
Attachment #699269 - Flags: review?(timdream+bugs) → review?(dflanagan)
Comment on attachment 699269 [details]
Pointer to GH PR #7390

Multiple values for x-inputmode violates the HTML5 spec for the inputmode attribute, at least as it currently stands. See http://www.whatwg.org/specs/web-apps/current-work/#input-modalities:-the-inputmode-attribute

 And the change in logic from a single-valued attribute to a multi-valued attribute carries too much risk for other Gaia apps.

If you want to modify latin.js to implement latin-name with capitalization only and no suggestions, I'd accept that patch, though we might also have to ask Jonas or Mounir for a review.

Note that for v1 you could just use verbatim and implement automatic capitalization in gaia with a key event handler or onchange handler or something.
Attachment #699269 - Flags: review?(dflanagan) → review-
(In reply to David Flanagan [:djf] from comment #5)
> Comment on attachment 699269 [details]
> Pointer to GH PR #7390
> 
> Multiple values for x-inputmode violates the HTML5 spec for the inputmode
> attribute, at least as it currently stands. See
> http://www.whatwg.org/specs/web-apps/current-work/#input-modalities:-the-
> inputmode-attribute

Then, why the attribute is called x-inputmode instead of inputmode? If you embrace standards then use the standard attribute name and if not then we are legitimated to have different semantics for it. 

> 
>  And the change in logic from a single-valued attribute to a multi-valued
> attribute carries too much risk for other Gaia apps.

Yes, what risk? I cannot foresee any actually 

> 
> If you want to modify latin.js to implement latin-name with capitalization
> only and no suggestions, I'd accept that patch, though we might also have to
> ask Jonas or Mounir for a review.
> 

Well, that's another approach but in practice you need to combine both. For instance the word suggestions should be enabled for givenName and at the same time the latin-prose thing. 

> Note that for v1 you could just use verbatim and implement automatic
> capitalization in gaia with a key event handler or onchange handler or
> something.

At the cost of adding more code, that would be a risky change . I'm open to be more standards compliant, if that's really an issue with the non-standard attribute,  but a big -1 to do this through JS code at app level.
It is prefixed with x because the standard is still evolving and this is an experimental implemention, I suppose. But that doesn't mean we can freely diverge from the standard.

Also, this is exposed to web content and we want it to be in sync with what we do for Firefox for Android.  So it is really not something we can play freely with.

It was hard enough to get the input mode landed at all. There is no way we can change its behavior like this, a few days before the deadline for a bug that isn't even a blocker.  Sorry. I suspect that if we asked Mounir, he wouldn't even allow latin-name to be added.

So switching contacts to vertabim and giving up auto-capitalization would be the easiest way to resolve the bug.  What the email app did, was to switch to latin-name, knowing that it would behave like verbatim for now, but that it would eventually get auto-capitalization.  You could do the same I suppose.
thanks David for your comments. I think inputmode spec is not complete and does not meet our requirements. Alignment with standards is always desirable but if the standard has gaps, they should filled, thus I think we would need to contribute to the inputmode spec accordingly. 

I'm adding the UX people to the loop just for letting them know the situation.
Whiteboard: interaction [UX-P3]
Oops forget this comment I have described the wrong behavior. and see the following one

(In reply to Jose M. Cantera from comment #9)
> Mounir,
> 
> We would need your feedback here. Basically we would need to know if it
> would be acceptable to have a new value for the x-inputmode attribute that
> will allow to have first letter capitalized and keyboard suggestions enabled
> at the same time. The use case is, for instance, the name field in contacts
> app. In that case the keyboard autocomplete is able to suggest the most
> common names like José, John, whatever and on the other hand we would need
> the first letter capitalized when we start editing the field. I have
> proposed a solution allowing multiple values for x-inputmode but that
> solution was rejected due to disalignment with standards. 
> 
> So in essence we would like to add a new value to x-inputmode attribute
> which will have at the same time the behavior of latin-prose and verbatim
> 
> Please let u know, what are your thoughts 
> 
> thanks
Mounir,

We would need your feedback here. Basically we would need to know if it would be acceptable to have a new value for the x-inputmode attribute that will allow to have first letter capitalized and keyboard suggestions disabled at the same time. The use case is, for instance, the surname field in contacts app. In that case the keyboard autocomplete should not suggest anything and on the other hand we would need the first letter capitalized when we start editing the field. I have proposed a solution allowing multiple values for x-inputmode but that solution was rejected due to disalignment with standards. 

So in essence we would like to add a new value to x-inputmode attribute which will have at the same time the behavior of latin-prose and verbatim

Please let u know, what are your thoughts 

thanks
x-inputmode is currently only implemented in B2G. We disabled the implementation in some versions of Firefox for Android (we should do that again for the new ones coming). The current spec doesn't sound good to Jonas and I but we have a hard time finding what solution we would like. It is not really a simple problem and not one of our area of expertise.

However, I think we shouldn't do stuff that we wouldn't like to see standardised even if we currently don't follow the spec on purpose. I do not really like the idea of having multiple inputmode keywords and I think it would be simpler to have something called "latin-name" that would only auto-complete from the address book and do the expected capitalization.
Flags: needinfo?(mounir)
Tim,

This bug has been open for a long time. I don't know if currently there is a solution. If not, we should close, please let me know.

thanks
Flags: needinfo?(timdream)
We should not close the bug just because it's old :)

What I think we should do is go ask UX and have them check the "Add Contact" panel on master and see if there is any auto-suggestion turned on that is undesired, and ask them to amend the spec as well.
Flags: needinfo?(timdream) → needinfo?(cawang)
Hi, 

Omega and I have tried some common names and we felt these suggestions may be not that useful but at least they are not confusing or causing problems. We'd suggest to keep it so that for those users who are heavily relying on suggestions can gain some convenience with it. Thanks!
Flags: needinfo?(cawang)
so as per comment #15, I think we should close this bug, Tim, do you agree?
Flags: needinfo?(timdream)
Yeah, we should probably WONTFIX this bug if we are only talking about Name fields.

How about ZIP code field and other fields?
Flags: needinfo?(timdream) → needinfo?(cawang)
Ooops, I was too focusing on the name fields.
So, after checking all of them, I'd suggest removing the suggestions for Company/ Street/ Zip code fields on Contacts edit page. In these cases, users may face some difficulties with the suggestions. 

Thanks!
Flags: needinfo?(cawang)
Tim,

how we can avoid suggestions on those fields mentioned by Carrie?
Flags: needinfo?(timdream)
You can change the inputmode of these input boxes.

UI Tests -> UI/keyboard will help you find the best value on that.
Flags: needinfo?(timdream)
QA Contact: isabelrios → jlorenzo
after analazying the input fields in contacts add form I think the only field we should change is zipcode. It should be verbatim in order to avoid any suggestion on this field
Assignee: jmcf → mri
Target Milestone: --- → 2.1 S7 (24Oct)
Attached file patch v1.0
Hi Jose,
would you mind reviewing the code?
Regards
Attachment #8507901 - Flags: review?(jmcf)
(In reply to Marina Rodríguez [:mai] from comment #22)
> Created attachment 8507901 [details] [review]
> patch v1.0
> 
> Hi Jose,
> would you mind reviewing the code?
> Regards

I rectify myself. We need verbatim in street and company fields as well.

thanks
Updated the pr with your comments,
Regards
Comment on attachment 8507901 [details] [review]
patch v1.0

thanks marina. please land once treeherder is green
Attachment #8507901 - Flags: review?(jmcf) → review+
Master:51554d61fbd18b90f92458d2d161516cd39e492f
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: