kenianbei - the problem with making characters in the search field tappable is that there are too many other things there to tap on. The iPhone has a very funny way of processing touch events - buttons have a sort of "magnetic" effect, and often seem to pull touches away from other buttons or non-button objects - so while in a large block of text like a definition / reader document it's easy to make characters tappable since there's nothing else to tap on, in the input field there's too much potential for tapping on the wrong thing.
js96 - true, might be worth experimenting with dual-panel input here at least, though maybe we really just need an easier way to toggle between handwriting / keyboard input (it's very fast, as character says, but the finger movement up to the search bar each time could get annoying).
And yes, Palm/WM flashcard database or export files for version 2.0 should transfer seamlessly over to iPhone; for version 1.0 you'd need to run them through the 2.0 converter utility on your Palm/WM device first.
character - I think in that case we'd be better off showing you the results for all of the parts in one big list; searching the database to break down the search query into segments with valid dictionary entries would take about as long as pulling results from it for those entries. Since in the 毛血旺 case you're really only interested in the single-character entries for 毛 and 血, we'd have an iPhone list header "entries for 毛," followed by single-character 毛 entries, then "entries for 血" followed by its entries, etc, with only the last part of the search covering words beginning with that search term too (in case what you entered was only a prefix for something longer).
I think this would only be for character searches, though, not for Pinyin ones - too much ambiguity in the Pinyin case, and anyway with that you can easily see that you've hit the longest match that Pleco can give you and backspace, review it, then clear and enter the next part of the search term.
As far as scrolling with the left hand, interesting idea but I'd rather right-align the characters / Pinyin instead of sticking them in the middle; if we're going to move the interface around for easy thumb scrolling we might as well go all the way. A "looks like" search might be possible with our character component database, but it would be a lot of work - I guess one option might be to pull the strokes for the character out of that database, feed them to the handwriting recognizer, then see what results it comes up with other than the original character, but that would be tough to control and would probably pick up a lot of characters that didn't look at all alike but happened to have similar stroke shapes / orders.
I think the handwriting partial-sensitivity option has already been mentioned once or twice; I think it would work best if we disabled stroke capture in that area when the box was blank but enabled it once you started writing, though that'll require some tricky event-passing code.
