Editing is a critical part of any ink-based application. It’s easy to lay down ink strokes, but what if the user makes a mistake? Or the recognizer misinterprets what is written? Both of these are very likely to occur.
The new Service Pack 2 TIP is one excellent example of how powerful and useful a correction (or editing) user interface can be. In real time you can see what the recognizer thinks you are writing and you can easily correct it as you go. The SP2 TIP is great for handwriting into edit fields, NotePad, Word, and the like.
One “drawback” to the TIP-style user-interface is that the user has to write in the TIP-panel in order to benefit from the correction UI. What I’ve wondered about is a correction UI that is minus the “input panel.” Instead, the user would lay ink down on the application’s window directly and a correction window would track the user’s input showing what has been recognized. From this window the user might be able to select the correct recognized string. A lot else could go on in the window too.
After some sketching in OneNote and them some keyboard time in Visual Studio, Bryan and I came up with this prototype that illustrates one way that a correction window might appear. In this case, it’s for an experimental math solver.
Like many of the other concept apps I’ve shown here, there’s nothing to download right now. And I’m still playing with the interaction to see if it really solves the problem–or at least what’s been a challenge for me :-).
As you can gather from this screenshot, as the user handwrites an equation the math recognizer goes to work and displays a pop-up window with the top results. In this app, I’m just interested in displaying the solution, so from the list of choices the user can tap on the checkmark to select the correct interpretation and solution. Alternatively, they can click to remove choices. Not sure how useful this part is yet. I probably need a “select and insert as recognized text” mode too.
Note: for a quick test of a correction window, there really isn’t any correction code implemented yet. It may turn out that after putting in some correction logic that the window needs to be reorganized. I don’t know. I’ll keep experimenting. In the meantime, maybe this gives you some ideas for your app.
And maybe someday the built-in TIP could have a correction mode where an app can manage its own ink input and display and the “TIP” would provide quick editing. It could be interesting.
Tablet development is fun.
Allen asks me: “Where’s the close button?” Yeah, the window is in prototype state. I like doing little “toy” apps like this so I can get a feel for how things might work. This is particularly effective when I’ve never done something like it before. This is one of those cases.