User Interface Feedback Thread

[djderdiger]

I should add that as a (struggling) Cantonese speaker, I appreciate the recent moves toward Pleco's accomodation of that troublesome dialect, and never would have thought of pushing Mike in such a direction. Though if Pleco is going to expand to accomodate more than Putonghua, then emphasis on Cantonese and, in the future, Shanghainese and other Chinese dialects, is more the way to go than toward unrelated East Asian languages.

I am moving to Hsinchu, Taiwan soon and would love the ability to hear pronunciations in a Taiwanese dialect. I know there are a handful of differentness from Putonghua that make it sound somewhat like a Sichuanese dialect, but I am rarely exposed to native speakers.

 

[mikelove]

It's a possibility, but in general if we're going to spend money on developing Taiwan-specific data I think a higher priority would have to be better support within our dictionaries for Taiwan pronunciation changes (particularly tones) - already about to get a bit better with an official release of MoEDict but there's plenty of room to improve further.

 

[Yiliya]

It's a possibility, but in general if we're going to spend money on developing Taiwan-specific data I think a higher priority would have to be better support within our dictionaries for Taiwan pronunciation changes (particularly tones) - already about to get a bit better with an official release of MoEDict but there's plenty of room to improve further.

Huh? You're finally making MOE an official add-on? When was this awesome party that I missed?

 

[mikelove]

@Yiliya - they changed their licenses a few weeks ago to allow commercial use, just waiting now for a few tweaks to come back from (Pleco) editorial.

 

[giokve]

I would love to see an official release of 兩岸詞典 too, but I know nothing about its licenses. In my opinion, it's as good as 規範, but since it is only available in traditional characters it might put some people off.

 

[ziggy]

Hello,

Just a suggestion - apologies if it's out of topic, I do'nt know the best place to do it.

In the flashcard mode, it would be very useful (especially for beginners I think) to know which wrong character you have chose when your attempt to respond to a definition prompt has failed. What I mean is that when the right character is disclosed, it would be very nice to touch the upper left boxes where the mistaken characters are displayed, and have a "bubble" telling me what my wrong answer means : so I could understand better my mistake, and possibly establish a mnemonic pattern to avoid the same mistake in the future with this definition/entry.

 

[mikelove]

@giokve - working on that one too, actually.

@ziggy - this is already supported on iOS, no idea why it isn't in Android but we'll make sure we add it in the next update.

 

[Abun]

they changed their licenses a few weeks ago to allow commercial use, just waiting now for a few tweaks to come back from (Pleco) editorial.

Awesome! Does this mean there's a chance to get their Minnan and Hakka dictionaries as well?

 

[mikelove]

Not 100% sure if those are under the same license - if they are then it's possible though it might take some time to get the coding done. (romanization systems are tricky, took us days to get Yale right for Cantonese)

 

[Abun]

Oh I see. I thought the main problem with Cantonese was the implementation of other romanization systems besides Hanyu Pinyin in general, and that new systems would be easier now^^'

Another problem I can imagine with Minnan is that some characters used there are not yet recognized by either the handwriting input or the radical tables, e.g. (亻因), (敖 over 力) ect.). They are included in newer Unicode extensions and can be found in the chars tab of their components but they are impossible to enter directly, so it might be difficult to search for those words, even if the dictionary is implemented. I don't speak Cantonese, so I don't know if the same problem exists for some special Cantonese characters. Can the corresponding words only be searched by entering their pronunciation in Yale then? Or were the input tools updated at the introduction of Cantonese to Pleco?

 

[Captain Planet]

Not 100% sure if those are under the same license - if they are then it's possible though it might take some time to get the coding done. (romanization systems are tricky, took us days to get Yale right for Cantonese)

It'd be great to have the MoE Taiwanese Minnan dictionary in Pleco. The license is CC-BY-ND-3.0, so it's the same as MoEDict: http://twblg.dict.edu.tw/holodict_new/compile1_6_1.jsp

二、 本網站之「文字內容」部分以 創用CC姓名標示-禁止改作 3.0 臺灣 授權條款釋出，欲取得資料者請填寫表件。

One difficulty is that Taiwanese writing is not standardized and there are many variant characters in use, so a good conversion should probably catch all of these and redirect them to their canonical entries. There are lists of these character variants compiled here: http://www.edu.tw/pages/detail.aspx?Node=3682&Page=25954&Index=6

1. 臺灣閩南語卡拉OK正字字表及內容說明
2. 臺灣閩南語推薦用字700字詞

And there's a dump of the whole dictionary here: https://github.com/g0v/moedict-data-twblg

 

[Abun]

One difficulty is that Taiwanese writing is not standardized and there are many variant characters in use, so a good conversion should probably catch all of these and redirect them to their canonical entries.

True, although that would exceed the features of the MoE dict as it is now (it does list a couple of 異用字 but they don't influence the search, i.e. you won't find m̄ 毋 by searching for 呣, even though that character is listed as 異用字). I agree that this is a feature which would be very nice, but at the same time, I think it's hard to be implemented in an exhaustive manner. There are some words for which there are a LOT of 異用字, most used only by one or two authors, quite a few not Unicode-compatible (I'm thinking of (入 over 下) for the attribute particle ê for example), and at every minute, somebody might come up with yet another one. Nevertheless, it would be nice to have at least a few of the most common ones listed.

 

[mikelove]

Extremely difficult to handle at the moment, yes. One of many long-simmering editorial projects here is what we call the "Character bible" - an attempt to come up with a reasonably definitive list of character variations and how they relate to each other / where they're used / etc.

Nearer-term, we're looking at getting at least some variants to match automatically (through an option in settings) - not too hard to get that into our search pipeline (we use similar logic now to deal with strings that have multiple Pinyin parsings).

 

[ziggy]

Hi,
Thank you Mike for your answer regarding the (future) possibility to check which wrong character you have typed in a "Prompt-definition" flashcard (once the right answer is displayed).

I have another suggestion / request : when searching a word in the dictionary, sometimes only one word is returned in the "list" screen. In that case, wouldn'it be ideal to directly get - at least - the loudspeaker icon ?... and possibly, since there is onely one "choice", to directly get the complete dictionary entry (sliding screens : definition, strokes, chars, words,sents) ... so as to save an additional (useless) "click" ? And even when there are two or three words on the list, adding just this small loudpseaker icon would be very practical in my opinion.
Thanks for considering this suggestion.

 

[mikelove]

You can actually get at audio from the search screen now by long-pressing on any search result.

In general I'm wary of abruptly taking people to the definition screen when there's just one result because it feels like a jarring disconnect from the behavior with multiple results - it's not obvious when you perform a search when you'll see one result and when you'll see more than one and if you're not expecting an app to jump you somewhere it can be disorienting.

 

[ziggy]

Thank you for the reminder, Mike.
Actually, I can get the sound, but, unless I'm missing something, only through two steps : long-pressing + clicking "Play Audio" - not better than clicking on the word, then on the loudspeaker icon ?

Regarding the objection about "abruptly" taking users to the definition screen... But isn't it exactly what a digital dictionary user wishes when he enters a word in it ? It seems to me that a vast majority of systems of different kinds use the same pattern : if you launch a search, you get a choice only if there is more than one "solution", but if the request is met with only one solution, you directly get what you want : the result (the complete entry definition, in a dictionary) ?
I, for one, would not be disoriented at all.

 

[mikelove]

Yes, it does require two steps.

It's not obvious to a user when they enter a search that they're only going to end up with one result, so changing our app's behavior based on the number of results would be confusing; people expect the same set of gestures to produce the same result.

We've opted for a results-list-oriented interface rather than one oriented around the definition screen with search results in a popover mainly because of the greater level of ambiguity in Chinese searches - for an English dictionary app, focusing on the definition screen makes sense because you've probably only got two or three entries at most for a particular word, but if you type "jishi" in a Pinyin search box you'll end up with dozens of results to scroll through, so for us it's more logical to make the definition screen separate. (most other Chinese dictionary apps are likewise oriented around their search results rather than their definition screens, for the same reason)

If you don't mind a slightly cramped UI, we do offer an option to put the definition and search results on the same screen; Settings / Search Interface / Embed definition. With that enabled, you'd see your first result (taking up around 2/3 of the screen) as soon as you entered the search and could play audio for it immediately.

 

[ziggy]

Thank you for your explanations.

I try to understand, and I am sure that you have good reasons... However, for the sake of clarification, here is why I am not convinced :

"It's not obvious to a user when they enter a search that they're only going to end up with one result" :
Sure. But obvious or not ...- if there is only one result, they will get one result anyway. It's just that it could be more complete. I can't understand the advantage of having just the word, instead of the word AND example sentences, etc... and the possibility to see stroke order, etc, with one click instead of two. It's really a puzzling (non-)logic for me. I guess my logic is specific.

"if you type "jishi" in a Pinyin search box you'll end up with dozens of results to scroll through, so for us it's more logical to make the definition screen separate." : again, I'm not talking about the case where you have dozens or results (then, of course it's more logical to keep the definition screen separate), or even two ; I'm talking only about the single-result case.

Thank you for your suggestion. However, in Settings, I never found "Search Interface/ Embed definition", only found "Search screen / two-panel layout" - which is not what I wish, because the behaviour is the same whether I have one single, or more results. Is it what you meant ? Sorry to bother you with this rather marginal thing.

 

[mikelove]

Yes, sorry, I get mixed up about different versions of our UI - Search screen / Two-panel is correct.

Regarding confusion: consistent behavior is important, particularly in a heavily used app like Pleco where people are kind of working through the UI on autopilot; if we sometimes take you to another page and sometimes don't, every time you finish entering a search you have to pause for a moment to think about where you are in the UI now.

And what about a case where there's only one result and it's the wrong one? Either because you entered it in incorrectly or because our dictionary doesn't cover the word you were looking for? Now the software has dragged you into an extra screen you weren't expecting to be in and you have to go back to retype your search.

Also, for English or Pinyin searches, or non-fullscreen handwriting ones, there's zero savings in taps since we don't know when you're finished typing - you either tap on the "Done" button or tap on the first result, same number of taps.

 

[ziggy]

Thank you for the additional explanation.
You are obviously right for English and pinyin search, my request was only for chinese characters.

I understand your views on "intensive" use of Pleco, and also on the "ergonomic" disadvantage when the output is wrong ; this makes sense.
Thank you.