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.

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.

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.

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.

I'm attaching a zip file for a keyboard app that does dynamic hit target resizing and should also feel more responsive. I'd love some feedback about whether it improves typing accuracy and whether it feels faster. After pushing it to your phone, I suspect you'll have to reboot before you'll be able to see the new keyboard (called "Demo Keyboard") in the settings app. But enable the Demo Keyboard english layout, pull up a keyboard and tap the globe icon to switch to the new keyboard. Autocorrection and some other features are not in there yet, but basic typing works. Flagging Stephany for feedback since I can never remember the generic gaia ux buzilla alias.

Comment on attachment 832362 [details] a demo keyboard app with dynamic hit target resizing Found the right address.

Also attaching a pull request for this demo keyboard app

I've landed my demo keyboard pull request to master: https://github.com/mozilla-b2g/gaia/commit/6dca3a92ed578b17f7c7dea2676ef19276eaa288 All but 2 lines of this pull request are in test_apps and is not part of the build. I've landed it without review in order to make it easier to gather feedback and get others collaborating on this. The other two lines are in build/ and were reviewed by Jan Jongboom.

I've landed another update to my demo keyboard app: https://github.com/mozilla-b2g/gaia/commit/9470d15828db48a5558c63a3d9981df9e72eb624 It now has word suggestions, auto correction, etc, and should actually be usable.

We've decided not to attempt to land the keyboard refactoring that includes dynamic hit target resizing in 1.3. I've landed my current work in progress to test_apps/demo-keyboard/: https://github.com/mozilla-b2g/gaia/commit/c61619156d49e49daaf5ba93b423bac8b9ef0f74 But now that the schedule is more relaxed I'll stop landing partial patches like this and do it by the book for 1.4.

(In reply to David Flanagan [:djf] from comment #10) > We've decided not to attempt to land the keyboard refactoring that includes > dynamic hit target resizing in 1.3. > > I've landed my current work in progress to test_apps/demo-keyboard/: > https://github.com/mozilla-b2g/gaia/commit/ > c61619156d49e49daaf5ba93b423bac8b9ef0f74 > > But now that the schedule is more relaxed I'll stop landing partial patches > like this and do it by the book for 1.4. Sounds like that makes this no longer a blocker for 1.3, so setting the flag as such.

Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]

Need info Carrie for attaching the feedback on current dynamic hit stat implementation. UX will also provide default offset position spec. for implementation reference.

Hi I've uploaded a user testing result of DHT and also a spec that we did in 1.3. Given that we have new KB layout already, the spec might be outdated, but we are very willing to help fine-tune the DHT for 1.4. Thanks!

Flagging Bruce to see if we intend to ship the refactor (and also these dynamic hit targets) for 1.4. We'll also cover this in the UX-PM joint work week this week.

Per discussion with Bruce, we move this feature to v1.5 with refactoring works due to the resource shortage. Update the whiteboard accordingly.

on hold, to do after v2.0.

Flagging Bruce as, per comment #18, this was supposed to be in 1.5/2.0 (two releases later than anticipated). Bruce, I know the team is focusing on copy-paste and some other things they want to get in for 2.0, so just let me know if this is slipping and then we should also let a QA lead know, as they're updating test cases right now. Thanks!

Comment on attachment 832362 [details] a demo keyboard app with dynamic hit target resizing Carrie or Juwei can review this.

Stephanie: I'm not sure why you're asking for feedback on that 6 month old attachment of mine. That was based on my failed keyboard refactoring attempt. If we're going to do dynamic hit targets it will have to be on top of the existing keyboard. Having implemented it once, I think we might be able to do it with the existing keyboard. If the system team wants to prioritize this for 2.0, I can make a little bit of time in this cycle to work on it, I think.

Yes, the new plan now is to do this on top of the existing keyboard. However it doesn't look like the team will be able to get to it in time for this release.

Comment on attachment 832362 [details] a demo keyboard app with dynamic hit target resizing remove flag, since it's outdated.

Bruce - thanks. Given your comment, should we resolve this as invalid?

I am not actively working on this, and the keyboard code has changed a lot since I last looked at it, so I'm unassigning myself. One of my attachments does have useful code in it, in particular the code to add to the autocorrect engine to have it return a list of predicted next characters. If anyone wants to take this, I can explain my existing work-in-progress.

Firefox OS is not being worked on