Closed Bug 908487 (kb-dynamic-targets) Opened 11 years ago Closed 6 years ago

Keyboard hit targets should be dynamic.

Tracking

(Not tracked)

Status:

RESOLVED WONTFIX

People

(Reporter: swilkes, Unassigned)

References

Details

(Whiteboard: ux-tracking [ucid:SystemPlatform24, ft:system-platform], )

Attachments

(5 files)

Keyboard Specs.pdf 11 years ago Stephany Wilkes 1.69 MB, application/pdf		Details
a demo keyboard app with dynamic hit target resizing 11 years ago David Flanagan [:djf] 1.04 MB, application/x-zip-compressed	cawang : feedback-	Details
link to github pr 11 years ago David Flanagan [:djf] 46 bytes, text/x-github-pull-request		Details \| Review
Dynamic Hit Target KB user testing.pdf 10 years ago Carrie Wang [New account: carrie75521@gmail.com] 77.84 KB, application/pdf		Details
[SPEC] dynamic hit target.pdf 10 years ago Carrie Wang [New account: carrie75521@gmail.com] 2.55 MB, application/pdf		Details

Stephany Wilkes

Reporter

Description

•

11 years ago

Attached file Keyboard Specs.pdf — Details

Using the same technology as the autocorrect feature, the actual hit area of keys should be dynamically modified to suit the most probable word, thus making typos harder to come by.

The spacebar and adjacent keys leave some room to avoid typos with the ones above.

See page 25 of the attached UX spec.

Andreas Gal :gal

Comment 1

•

11 years ago

djf, this isn't really your team but you might want to discuss with Rudy and team whether you want to help out with this since this is totally up your alley.

David Flanagan [:djf]

Comment 3

•

11 years ago

Thanks for cc'ing me Andreas.

We might want to consider breaking this into two bugs. One for modifications to the autocorrect code to return the "most likely next key" information and one for modifications to the keyboard input handling to make use of that information. I'm happy to work on the former, but would like to caution that the latter seems like it may be more difficult than anticipated.

For example, the UX spec attached just shows circular hit areas with lots of empty, insensitive space between them. Assuming that we don't actually want the user's touches to be ignored, we'd have to do polygons instead of circles, which makes the math harder. The UX spec does not address the issue of how to handle a case where two adjacent keys (like s and d) are both high-probability.

The UX spec also makes the sensitive area of the space bar unconditionally smaller than what is actually displayed on the screen, which I fear will be a usability issue, unless it is time based, like what we see in the Microsoft video.

Another option, of course, is to leave the sensitive areas of the keyboard alone, and just change autocorrect to use touch coordinates directly and create its own interpretation of those touches. In that scenario, you would see exactly what you typed, but autocorrect would fix everything for you. There would be no issue of "I typed s but the keyboard input d", but autocorrection would become smarter.

Would that be as good as what Microsoft does? I think it would be easier, but I don't think we can know if it would be better without trying it to see. I think this is an area where research is still needed. And it seems premature to be having UX drawing pictures and telling us how to implement it.

I think we can do great things with the keyboard, and I think we should work hard on it. I just don't want to over-promise, or to commit to a feature that is still in the research stage, or even commit to a particular implementation approach without digging deeper into this.

Tim Guan-tin Chien [:timdream] (please needinfo)

Comment 4

•

11 years ago

Don't worry about this spec too much I think. It is quite old and I believe it was meant to be an illustration. We should work out the prefect touch area with iterations of user tests and code tweaks.

(In reply to David Flanagan [:djf] from comment #3)
> Thanks for cc'ing me Andreas.
> 
> We might want to consider breaking this into two bugs. One for modifications
> to the autocorrect code to return the "most likely next key" information and
> one for modifications to the keyboard input handling to make use of that
> information. I'm happy to work on the former, but would like to caution that
> the latter seems like it may be more difficult than anticipated.
> 
> For example, the UX spec attached just shows circular hit areas with lots of
> empty, insensitive space between them.  Assuming that we don't actually want
> the user's touches to be ignored, we'd have to do polygons instead of
> circles, which makes the math harder.  The UX spec does not address the
> issue of how to handle a case where two adjacent keys (like s and d) are
> both high-probability.
> 
> The UX spec also makes the sensitive area of the space bar unconditionally
> smaller than what is actually displayed on the screen, which I fear will be
> a usability issue, unless it is time based, like what we see in the
> Microsoft video.
> 
> Another option, of course, is to leave the sensitive areas of the keyboard
> alone, and just change autocorrect to use touch coordinates directly and
> create its own interpretation of those touches. In that scenario, you would
> see exactly what you typed, but autocorrect would fix everything for you. 
> There would be no issue of "I typed s but the keyboard input d", but
> autocorrection would become smarter.
> 
> Would that be as good as what Microsoft does? I think it would be easier,
> but I don't think we can know if it would be better without trying it to
> see. I think this is an area where research is still needed. And it seems
> premature to be having UX drawing pictures and telling us how to implement
> it.
> 
> I think we can do great things with the keyboard, and I think we should work
> hard on it. I just don't want to over-promise, or to commit to a feature
> that is still in the research stage, or even commit to a particular
> implementation approach without digging deeper into this.