Closed Bug 985856 Opened 11 years ago Closed 7 years ago

[Keyboard UX update][User Story] App-customizable [Enter] button

Categories

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

x86
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:+)

RESOLVED WONTFIX
tracking-b2g +

People

(Reporter: bhuang, Unassigned)

References

Details

(Whiteboard: [ucid:SystemPlatform57, ft:system-platform])

As a user, I would like common functions to appear on the keyboard when I am typing in specific fields so that I can quickly complete text or perform action on the text box. Acceptance: (Follow visual spec) In multiline text input, far right button in bottom row is the “enter” key which does a line break. In search fields, far right button is a “search” key, which searches for the text in the field. In single line text input or password fields, far right button is “Go”, which completes the input and moves to the next field if applicable. In url fields, the “.com” button appears which will enter .com at the caret. The “/” character is to the left of the space bar and will enter a / at the caret. In email fields, the “.com” button appears which will enter.com at the caret. The “@” character is to the left of the space bar and will enter a @ at the caret. Refer to pp. 17~18 of UX spec in bug 983043
Whiteboard: [ucid:SystemPlatform57, 1.5, ft:system-platform]
See bug 983043 for the UX spec update.
Whiteboard: [ucid:SystemPlatform57, 1.5, ft:system-platform] → [ucid:SystemPlatform57, 2.0, ft:system-platform]
feature-b2g: --- → 2.0
feature-b2g: 2.0 → ---
Whiteboard: [ucid:SystemPlatform57, 2.0, ft:system-platform] → [ucid:SystemPlatform57, ft:system-platform]
feature-b2g: --- → 2.0
Whiteboard: [ucid:SystemPlatform57, ft:system-platform] → [ucid:SystemPlatform57, ft:system-platform], [p=1]
Target Milestone: --- → 2.0 S2 (23may)
After a discussion with Omega, this feature may not be feasible for 2.0 because, 1. per the p.18 of UX spec in bug 983043, we need to know if the input is in the form, however, so far we don't have that info in Gaia layer. 2. Besides, the better way to do this would be: let the developer be able to specify the "input hint" instead of doing some guessing is O.S level, this is because we could not know what action is associated to that input when the user presses "Enter" key. e.g. When a user inputs a "url" in a contacts app, it may not make sense to change "Enter" to "GO". -- Howie, I'll remove the target milestone first.
Whiteboard: [ucid:SystemPlatform57, ft:system-platform], [p=1] → [ucid:SystemPlatform57, ft:system-platform]
Target Milestone: 2.0 S2 (23may) → ---
Omega, if possible, please help chime in per UX perspective. Thank you.
Flags: needinfo?(ofeng)
Flags: needinfo?(hochang)
feature-b2g: 2.0 → ---
Flags: needinfo?(hochang)
(In reply to Rudy Lu [:rudyl] from comment #3) > 2. Besides, the better way to do this would be: let the developer be able > to specify the "input hint" instead of doing some guessing is O.S level, > this is because we could not know what action is associated to that input > when the user presses "Enter" key. 2. makes more sense. We will come out some proposal targeting 2.1.
Flags: needinfo?(ofeng)
Please see Bug 983043 for latest UX spec.
What's the status of this bug? Is it being covered by multiple bugs out there?
Rudy, do you know the answer to above question?
Flags: needinfo?(rlu)
Not exactly, this is a feature that might need Gecko support, which I already had a brief discussion with Xulei. We could continue the discussion on API/standard we need for v2.2 if this is in UX's priority list.
Flags: needinfo?(rlu)
Let's make a decision on whether or not this should reach 2.2.
feature-b2g: --- → 2.2?
Rudy, could you explicitly states what UI changes or API support this bug represents? From comment 0 this bug looks redundant but I am not sure.
blocking-b2g: --- → backlog
feature-b2g: 2.2? → ---
tracking-b2g: --- → +
Flags: needinfo?(rlu)
There is one statement in comment 0 that we have not implemented: >> In single line text input or password fields, far right button is “Go”, which completes the input and moves to the next field if applicable. And as the UX spec also stated to change the [Enter] key to [Next] for form navigation, which is why I mentioned form navigation in comment 3. I would suggest we keep to the bug for customizable label for the [Enter] key, like [GO], [Done], [Send], and track form navigation with bug 857637.
Flags: needinfo?(rlu)
Summary: [Keyboard UX update][User Story] Context sensitive bottom row → [Keyboard UX update][User Story] App-customizable [Enter] button
blocking-b2g: backlog → ---
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.