Implement keyboard suggestions for email addresses based on information in contacts db.



Firefox OS
5 years ago
a year ago


(Reporter: lightsofapollo, Unassigned)


(Blocks: 1 bug, {feature})


Firefox Tracking Flags

(feature-b2g:3.0?, tracking-b2g:backlog)


Comment hidden (empty)
Is there more details on this bug or improvement?
Assignee: nobody → gweng
Hello, I've some ideas about this enhancement, and placed a personal studying note at my GoogleDrive:

Because this is my first bug, if I did anything inproper, please leave comments to let me know.
After some offline discussions, this feature can be processed in two different ways:

1. Use the existing keyboard candidate panel, which follows the original proposal
2. Use a autocomplete list below the input element, like what we usually see on search engine sites

We will get a simpler version if we follow the first way, but 3rd keyboards will not benefit from it; the second way requires us get some new UX designs, which may cause lots of changes.

And if we decide to append the autocomplete to input elements with mail type, we will need to create a system wide service to create the list for every inputs in all apps. If we don't do that, there will be only those apps implement it can show that list, others will still suffer the user while he/she need to input mail addresses.
Flags: needinfo?(firefoxos-ux-bugzilla)

Comment 4

5 years ago
Is this a feature that is slotted for 1.3?

Comment 5

4 years ago
Flagging Bruce and David to see if there are any plans for this in 1.3. This could be considered in our list of quality improvements for keyboard in 1.3, but I'm not sure if it's in or should be.
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?(dflanagan)
Flags: needinfo?(bhuang)
I don't know of any plans to do this for 1.3, but it seems like a good idea to consider it.

IIRC, The HTML spec for inputmode="name" explicitly contemplates exactly this use case.  We punted on it before, but we should make this work, eventually.

Greg: thanks for your analysis of this. I had only considered the possibility of doing it through the autocorrect area.  But I actually like your idea of a drop-down list better.  I suppose that is up to the UX team to decide.

Tying it to the autocorrect mechanism would be gaia work, and would be specific to our keyboard app. Doing it as a dropdown would be gecko work, and would tie in with other changes like range selection and cursor movement.
Flags: needinfo?(dflanagan)
This wasn't specifically listed for 1.3, I'll add it in the backlog and we can look into it once the other items are done.  Is there more UX needed?
Flags: needinfo?(bhuang)

Comment 8

4 years ago
Bruce, I'll flag this for UX review and we'll determine if more UX is needed. Thanks!


4 years ago
Blocks: 924662

Comment 9

4 years ago
This will be include in the new spec this week.
Have no time and resource to do this. Beside that, spec is not ready.
Assignee: gweng → nobody
FYI, this is also covered in Google Summer of Code proposal from one of the participants. See:
blocking-b2g: --- → backlog
Keywords: feature
Already confirm with Bruce this is not going to be a 2.2 feature, so let's talk about it in 2.3.
feature-b2g: --- → 2.3?

Comment 13

3 years ago
Use feature-b2g:3.0? rather than 2.3?.
feature-b2g: 2.3? → 3.0?


3 years ago
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.