Dictionary: Switching input method automatically when switching language

Shun

状元
I have a general usability question regarding dictionary search. If I have it set to Chinese with the "C" button and have handwriting input enabled, which is suitable only for inputting Chinese text, could a tap perhaps be saved by having Pleco automatically switch to the Latin keyboard when the user taps on one of the Western-language buttons?

I get the impression that when a user wishes to make a search, they usually very much have their search expression on their minds and feel held back by having to think about such things as switching the input method and the search language. I attach a video with the current behavior.

One could perhaps even add a setting for handwriting as a "preferred input method" for Chinese if one switches the dictionary search from a Western language to Chinese, where both handwriting and pinyin input would be possible. Apart from that, I think the language switching toolbar is a great innovation. Do you feel that this suggestion could improve it further?

Many thanks,

Shun
 

Attachments

  • Dictionary search input method.mp4.zip
    74.2 KB · Views: 111
Last edited:

mikelove

皇帝
Staff member
It's an interesting idea, but I think it could end up being confusing because we can only switch it when you go in that direction - to a language that uses a Latin keyboard exclusively - and not when going back to Chinese. So instead of some hard clear association between languages and input methods, it's a shortcut that happens intermittently and it's not as obvious to users where it happens. There's also the fact that sometimes the language switches while you're typing, which gets in the way of the "handwriting as preferred language for Chinese" idea - if you're in German mode and you start typing in a Pinyin phrase and it jumps you over to Chinese, obviously it shouldn't switch to the handwriting keyboard in that case, but then we're only changing it some times and not other times, so again, intermittent and not obvious to users.

In general I prefer the idea of this being driven by your input method selection - it occurs to you to type a new search, you tap on the clear button above the keyboard, you tap on the keyboard button above the keyboard, and you start typing in your new search and in most cases you don't even have to think to tap on a language because your search term is only valid in one language.

But we can certainly play around with this more and see if it might make sense as an off-by-default option.
 

Shun

状元
Thanks! I agree, if one only switches the input method, one usually gets what one wants in a single step, as well, thanks to the intelligent language switching.

Then it boils down to whether one prefers to teach users to do things in a particular way (always use the input method selector) or to offer them multiple different avenues for doing the same thing (let them use either the input method or the language selector).

Just to be absolutely precise, when in a Western mode, I don't see any possibility for confusion between entering pinyin with numbers (-> switches to Chinese pinyin) or tapping on the "C" button (-> switches to Chinese handwriting). Different inputs would lead to different results. The only case that should be avoided, in my view, is if the same input led to different results at different times.
 
Last edited:

mikelove

皇帝
Staff member
The confusion I'm worried about is that the input method won't always switch when the language changes - it's not that users won't understand what's going on, it's that it'll be inconsistent and therefore confusing. This is also for example why we've eliminated the option for Pleco to sometimes respect the mute switch and sometimes not (now you have the choice of always / never).

If every language had a single specific keyboard associated with it, and we switched to that keyboard when we switched that language, and languages never switched except when you tapped on the language bar, this would all make perfect sense. But with languages switching on their own and with Chinese supporting both keyboard and handwriting/radical input, I'm worried that keyboard changes will seem confusingly random.
 

Shun

状元
I understand, that's the principle of outward simplicity. It's too bad I can't try out my suggestion for myself to see if it would really not work—that's something only the developer can do. Thanks again.
 
Last edited:

cores

Member
I just want to add that I am very often frustrated with typing pinyin with the english or german latin iphone keyboard. I think this is because the virtual tap size of each key changes according to what the keyboard predicts you will type. As it never predicts the pinyin with an english keyboard, it is very hard not to make typos. but changing the keyboard for each time i change from english to pinyin/hanzi also feels too slow.

So I would love some dynamic keyboard switch when I click the language buttons.

I am not sure there is a clear solution for that, but I would already love a button that just quickly switches between my two favorite keybaords. (The apple switch is so slow when you have more than two keyboards active)

Cheers, Tobi
 

Shun

状元
Hi Mike and Tobi,

thanks, I didn't realize the predictive aspect when entering pinyin with an English/German keyboard.

I just wanted to add two more basic, slightly power-user UI suggestions for the record.
  • Pleco could clear the search input field automatically when the user taps on a language in the language selector or an input method button right after a successful search has been completed. Right now, the finger also needs to travel to the "x" button at the right end of the search box every time one wishes to enter a new search term. When the search input field is automatically cleared, the search history list could appear like it does now.

  • One could perhaps replace the "C" (Chinese) button with a "CP" (Chinese Pinyin) and a "CH" (Chinese Hanzi) button. Since Pleco is a Chinese dictionary app, Chinese would deserve two buttons that would be easily learned by users, always produce a predictable result, and often reduce two taps to one. The buttons could also be called "PY" and "HZ". Right now, if Latin characters are in the search field, the "C" button is grayed out. In such a case, the "PY" and "HZ" buttons could clear the search field.

Do you feel that these might make some sense? (No problem if not.)

Cheers,

Shun
 
Last edited:

mikelove

皇帝
Staff member
I just want to add that I am very often frustrated with typing pinyin with the english or german latin iphone keyboard. I think this is because the virtual tap size of each key changes according to what the keyboard predicts you will type.
Maybe for this we could add an option to use a forced ASCII keyboard or otherwise configure it so that it no longer assumes you're typing any particular language?

@Shun - at the moment I'm pretty firmly against the idea of the scope bar doing anything but selecting a particular set of search results.
 

Shun

状元
@mikelove I see, I couldn't really wrap my head around the language bar just being a scope bar instead of something more. UI preferences of different people can be quite tricky to bring into line. I'm sure you can tell by now that I aim for a fast UI with as few taps as possible. :)

I appreciated the hamburger long-press shortcut in Pleco 3.2, which now isn't really possible due to the absence of the hamburger. Any desktop version of Pleco will surely be ideal in terms of UI responsiveness.
 
Last edited:

Shun

状元
@mikelove Apologies, I only now noticed the new round "X" button in the dictionary screens near the keyboard which quickly clears all search inputs. This goes a long way. So it's "First look, then think."
 
Last edited:

cores

Member
Maybe for this we could add an option to use a forced ASCII keyboard or otherwise configure it so that it no longer assumes you're typing any particular language?

@Shun - at the moment I'm pretty firmly against the idea of the scope bar doing anything but selecting a particular set of search results.
It seems keyboards can now be bilingual with iOS18. So maybe this problem kind of disappears on its own or, almost as likely, a lot of new problems get introduced :)
 
Top