2.3 / User Interface Enhancements

[Alexis]

When you go into "Organize Flashcards" and click on a flashcard (text tab), it would be nice if the Chinese/Pinyin/English fields had word wrap. I am currently using a C-E deck to test Pleco Sentences, and it would be really nice to see the full sentence. So far my sentences are short enough that only the pinyin is getting chopped off.

 

[mikelove]

When you go into "Organize Flashcards" and click on a flashcard (text tab), it would be nice if the Chinese/Pinyin/English fields had word wrap. I am currently using a C-E deck to test Pleco Sentences, and it would be really nice to see the full sentence. So far my sentences are short enough that only the pinyin is getting chopped off.

They should already - go into Settings / Flashcards, is the layout for lists under List Views configured to have very few lines / to combine everything on one line?

 

[Alexis]

When you go into "Organize Flashcards" and click on a flashcard (text tab), it would be nice if the Chinese/Pinyin/English fields had word wrap. I am currently using a C-E deck to test Pleco Sentences, and it would be really nice to see the full sentence. So far my sentences are short enough that only the pinyin is getting chopped off.

They should already - go into Settings / Flashcards, is the layout for lists under List Views configured to have very few lines / to combine everything on one line?

The word wrap is working fine in the listing. But when you click on a individual flashcard, and it opens up the screen with the "text/categories/statistics" tabs, the pinyin is getting cut off in the text box, both in landscape and portrait mode. I attached a screen capture.

 

[mikelove]

The word wrap is working fine in the listing. But when you click on a individual flashcard, and it opens up the screen with the "text/categories/statistics" tabs, the pinyin is getting cut off in the text box, both in landscape and portrait mode. I attached a screen capture.

Hmm, not sure what's going on there - thanks!

 

[goldyn chyld]

Btw, will 2.3 (or the new batch of dictionaries) include the latest version of ABC?

 

[mikelove]

Btw, will 2.3 (or the new batch of dictionaries) include the latest version of ABC?

Yes, updates have been relatively minor compared to more rapidly-iterating dictionaries like CC-CEDICT but we get the new versions as soon as Tom checks them in so we'll have the latest along with our other new dictionaries. (ABC E-C has been improved a lot more, since it now separates a lot of its former sub-entries into their own entries for easier searching) We've finally replaced ~s too, which I know was a popular request.

 

[radioman]

I had commented on Skritter's board with regard to joint display of Pleco and Skritter simultaneously on iPad. (How I did it can be found at http://goo.gl/4BYVf)

In general, I had always hoped that when the iPad came out that there would ultimately be ability to display flashcards on the right (or left) and having a dictionary or document search lookup on the other side.

I see value in following Display/Feed configurations.
1) Source > Targetictionary
2) Source > Target:Reader
3) Source > Targetictionary Reader + Jukuu Lookup, etc., maybe via tabbed configuration.

Source could be Flashcards, Reader (web or document), or some other feed like voice, movie subtitles, news, etc.

And I brought up in the past that Source and Target also do not necessarily need to be the same device. So, for example, a flashcard session on an iPhone can update the reader on the iPad. But I also believe there were technical challenges associated with bluetooth with regard to reliability, but maybe the new bluetooth standard would simplify it. Maybe WiFi would work, as long as there was not more than a few second delay.

 

[mikelove]

In general, I had always hoped that when the iPad came out that there would ultimately be ability to display flashcards on the right (or left) and having a dictionary or document search lookup on the other side.

We were partly waiting for Apple to make this a bit easier with enhancements to UISplitViewController (the official API for managing split views on iPad), which they still haven't done - there are more flexible third-party alternatives, but those introduce some future-proofing concerns. But given that we're selling more copies of Pleco on iPad than on all Android devices combined, we definitely need to invest more time into taking advantage of the iPad's screen, and split-screen views are an extremely logical way to do it.

I'm mainly thinking of this in the context of reading than anything else - an expanded version of the popup reader function to some extent; was there something you had in mind for this besides having some kind of text in one half and a dictionary definition in the other? Or is there some aspect of that flashcard integration I'm not getting?

And I brought up in the past that Source and Target also do not necessarily need to be the same device. So, for example, a flashcard session on an iPhone can update the reader on the iPad. But I also believe there were technical challenges associated with bluetooth with regard to reliability, but maybe the new bluetooth standard would simplify it. Maybe WiFi would work, as long as there was not more than a few second delay.

That one's still wonky in iOS 6 from what we can tell so far. I'm also not sure if enough people would use it to make it worthwhile, honestly; the split view is easier to justify programming-time-wise.

 

[lechuan]

Just a wish/request for the "Pleco Reader" in edit mode:

Is it possible to be able to click to place the cursor between every character? Currently it seems to parse words, so that you can only place the cursor at the end of a "word". Also if a character is followed by a comma, you have to place the cursor at the comma, then backspace to delete the comma, to put the cursor after the character.

I ask because I have been OCRing some texts and doing manual edits on them. The current text selection makes it such that I have to delete "good" characters in order to access the "bad" ones.

Thanks!

 

[mikelove]

Is it possible to be able to click to place the cursor between every character? Currently it seems to parse words, so that you can only place the cursor at the end of a "word". Also if a character is followed by a comma, you have to place the cursor at the comma, then backspace to delete the comma, to put the cursor after the character.

I ask because I have been OCRing some texts and doing manual edits on them. The current text selection makes it such that I have to delete "good" characters in order to access the "bad" ones.

That's all on Apple's end, unfortunately - there's no way to customize the text editing behavior since we're basically just dumping the OCR output into one of iOS' built-in text edit boxes. However, if you tap-hold on a character while still on the OCR screen, you can use handwriting to draw the correct character (or pick from a list of other possible matches).

 

[lechuan]

That's all on Apple's end, unfortunately - there's no way to customize the text editing behavior since we're basically just dumping the OCR output into one of iOS' built-in text edit boxes. However, if you tap-hold on a character while still on the OCR screen, you can use handwriting to draw the correct character (or pick from a list of other possible matches).

Thanks Mike. If only Apple was accessible as you! Apple's cursor handling makes sense for English, but not as much for Chinese.

I'll try the tap-hold on the OCR screen for future OCRs.

 

[jamesquek]

Character Decomposition

This exisiing feature is a great idea but the implementation is not. I see that the implementation links it to the Unihan data instead of the main dictionary. So I get lots of odd and obscure characters when I use the future. Can you link this to the main dictionary and have it sorted by frequency of usage instead?

 

[radioman]

I would like to see a way to take the radical lookups, and just dump all the characters for the radical of interest into the Reader. In this way, you can go through the characters looking for patterns (similar phonentics / meanings / etc.).

And not to get too crazy, but I often utilize my iPad with an external keyboard. I seeing a number of situations where having keyboard control would be very useful. One in particular is the ability to use the keyboard to move from character to character in the Pleco Reader (or down arrow goes to the next line). Another might be during dictionary lookup. You type in the character and the definitions get displayed. "Arrowing" down allows you to effectively highlight the next definition.

 

[mikelove]

This exisiing feature is a great idea but the implementation is not. I see that the implementation links it to the Unihan data instead of the main dictionary. So I get lots of odd and obscure characters when I use the future. Can you link this to the main dictionary and have it sorted by frequency of usage instead?

Possibly - we're trying to improve the actual decomposition data first (almost done with that), since there are far too many common radicals that appear under two or three different codes and you end up not seeing all of the characters that share that component. But improving the presentation of results is next up once we're done with that.

I would like to see a way to take the radical lookups, and just dump all the characters for the radical of interest into the Reader. In this way, you can go through the characters looking for patterns (similar phonentics / meanings / etc.).

How about just displaying a list of results-with-definitions for them? (kind of a merger of the radical and character component listing screens, which ought to happen at some point anyway)

And not to get too crazy, but I often utilize my iPad with an external keyboard. I seeing a number of situations where having keyboard control would be very useful. One in particular is the ability to use the keyboard to move from character to character in the Pleco Reader (or down arrow goes to the next line). Another might be during dictionary lookup. You type in the character and the definitions get displayed. "Arrowing" down allows you to effectively highlight the next definition.

Impossible, sadly - Apple doesn't provide APIs for developers to interact with external keyboards directly.

 

[radioman]

I would like to see a way to take the radical lookups, and just dump all the characters for the radical of interest into the Reader. In this way, you can go through the characters looking for patterns (similar phonentics / meanings / etc.).

How about just displaying a list of results-with-definitions for them? (kind of a merger of the radical and character component listing screens, which ought to happen at some point anyway)

One concern that I have is that, when looking through 100 or more characters and looking for consistencies, unless they are nicely lined up vertically, it becomes difficult.

Hanzi <Space or Tab> Pinyin
Hanzi <Space or Tab> Pinyin
Hanzi <Space or Tab> Pinyin
etc.

If I put the definitions on the same line (right after the Pinyin) it starts to get too much as the definitions will run to the next line. This is especially the case on a small screen on the iPhone (unless you can force "single row"). However, if that list of Character + Pinyin exists in the reader, and if I really want to see a definition, I can just click on the character to do so. It works great.

I actually use this approach now with a list of related characters that I bring into the Reader, but its not the same as the radical lists and functions that exist in Pleco. Component parts in the mix would be very useful as well.

 

[mikelove]

If I put the definitions on the same line (right after the Pinyin) it starts to get too much as the definitions will run to the next line. This is especially the case on a small screen on the iPhone (unless you can force "single row"). However, if that list of Character + Pinyin exists in the reader, and if I really want to see a definition, I can just click on the character to do so. It works great.

I was thinking that this would look like the character component / characters containing listing in our Android app, in which characters are all on the left and take up the entire cell height.

 

[radioman]

I was thinking that this would look like the character component / characters containing listing in our Android app, in which characters are all on the left and take up the entire cell height.

Oh, well my Kindle Fire is in the U.S. so can't really see it. But as long as there are many cascading characters grouped and presented vertically, that would achieve the effect I was referencing.

One other thing I have found useful is the ability to take these lists and sort by Pinyin within the group. In this way, when looking at characters, you can see how certain radicals or parts are dedicated to sound.

 

[mikelove]

One other thing I have found useful is the ability to take these lists and sort by Pinyin within the group. In this way, when looking at characters, you can see how certain radicals or parts are dedicated to sound.

Maybe, but I'd tend to prefer supporting that more officially by actually providing a list of sound components (or some such thing). "Interesting character-learning material" is one of the top candidates for our first round of Pleco-developed content (on which we're planning to spend a lot of the money we'll hopefully make from this round of licensed content) - perfect since there are few enough characters to make it feasible for one or two people to develop some content for them.

 

[lechuan]

I have been OCR'ing some text with a lot of superscripted numbers (for footnotes). Unfortunately, these usually try to get recognized as characters, adding a lot of junk characters into the text.

Is there anyway to detect and ignore small superscripts? Maybe a size threshold?

 

[mikelove]

I have been OCR'ing some text with a lot of superscripted numbers (for footnotes). Unfortunately, these usually try to get recognized as characters, adding a lot of junk characters into the text.

Is there anyway to detect and ignore small superscripts? Maybe a size threshold?

We're looking at that, yes - it can be a little tricky with some texts / some characters but better layout analysis is far and away our top priority for OCR. (trying not to get more specific since I don't want to predict what will actually work well enough to release and when it'll be ready)