Thoughts on the Evolution of Pleco

[ryan erwin]

Mike, you know I've been using Pleco since my Palm Treo, and recommend it as the key to learning Chinese to anyone who will listen. It's a great tool. I've been thinking about how Pleco may evolve over time, especially in the mobile world, and have the following thoughts....

FLASH CARD APP
I frequently use Pleco's "flash cards" feature to note interesting words. I occasionally review these flash cards, but having to "enter/exit" the "flash card mode" is a bit cumbersome. Would greatly prefer having a separate "Pleco Flash Card" app that I could open, allowing me to resume the flash card review that I was last doing, without the 4 step (click menu button, click flashcards, click flashcard testing, click resume test in progress) launch procedure. The killer app of mobile is "killing time". If I can easily jump back into my Pleco flashcards whenever I'm waiting in line somewhere, it would be far better than jumping into another round of Angry Birds...

READER/CLIP BOARD APP
I run into the same situation with the reader/clip board App that I run into with the dictionary --- if I'm reading a long article, say more than 30 minutes, there's a 90% chance that I'm going to be interrupted before I finish, perhaps even wanting to check something else in my dictionary. I use my phone to take a call, look up a word in the dictionary, then copy something into an email... When I go back to the Pleco reader, I press the 3 steps (menu button, reader/ocr, pasteboard reader) to launch my reader, but the thing I was reading is now long gone. Would be beneficial if like the Flash Card app, there was a way to jump directly back to the reader, bypassing the normal app launching process. Also, clipboard history might as well store the last things that were on the clipboard --- just in case it got wiped off the clipboard while I was copying and pasting something else.

NOT ONE APP - BUT THREE APPS
Also, reader has 6 different options (in my version) and flashcards have 11. Might take a look at the FaceBook app or LinkedIn app for how they deal with choosing from a set of options... They have the "grid/menu" button on the top left, and pages of icons that you can flip... Makes a lot of sense based on the way the regular iPhone launcher works.

Actually, if you broke Pleco into 3 separate Apps: PlecoDict, PlecoFlash, and PlecoRead, and internally those Apps had menus more like the FaceBook/LinkedIn apps, I think much of the confusion of using Pleco would vanish. This way, settings and add-ons could either be on the "2nd page" of the FaceBook/LinkedIn/iOS style menu --- keeping it uncluttered, or you could move these into the iOS System Settings area.

DICTIONARY - SOUND RECORDING?
Only some of the cards in my Pleco dictionary have actual sound recordings. I would like to be able to EASILY extend my user dictionary with additional recordings. For example, 政企 (zheng4qi3) only has the syllable-per-syllable pronunciation. I would like to be able to Click and Hold the Sound Button, just like I can for the "+" button, and have a menu that allows me to record the proper pronunciation for a word.

Additionally, I think the entire pronunciation/verification process for syllables, words, and sentences could be an entire "PlecoSpeak" module... Your iPhone already has input (Onboard Mic/Headset) and output (Speakers/Headphone), and a fast enough CPU to process the incoming voice and compare it to the existing voice reference files. You can do this for single syllables, for words, for sentences, and then for paragraphs. That is really the definition of fluency --- and based on my experience living in China, it's the part that foreign speakers suffer the most on.

PLECO ONLINE
Finally, I would like to see Pleco really take advantage of the internet to update new words on a daily basis. Via the Pleco website, I would like to be able to see the history of all of the words that I've searched for, and to easily, as a community, create a living dictionary of english <=> chinese. If a word can't be found in the local dictionary, searching online should be automatic. The local dictionary should be augmented with online entries... Though Pleco's offline strengh doesn't need to be compromised --- just use the online method to augment Pleco when able to connect, but without slowing down the experience, ie do all Internet queries in the background with a visual indicator that the web search is under way and more data may show up on screen when it's complete.

SUMMARY

• Flash/Read: Reformat the Pleco Flash and Pleco Reader "Menus" to be more "iOS Style", akin to the default Springboard launcher or even the FaceBook/LinkedIn default app menu
• Flash: Allow creation of Flash Cards from inside Pleco Dict and Pleco Reader, but lauch "Pleco Flash" to do testing as a separate app that maintains state independant of Pleco Dict and Pleco Read
• Read: Allow Pleco Read to store recent clipboard history, and run as a separate app that maintains state outside of Pleco Dict and Pleco Flash
• Dict: Automatic online search for words, especially new words or words from recent days news during dictionary queries
• Dict: Simply/speed up process to add new entries to the dictionary
• Dict: Easily add new "sound recordings" to dictionary entries by pressing and holding on the "speaker" button for each entry
• Develop "Pleco Speech" module that enables visual comparison of sound waves for syllables, words, phrases, and even entire passages
• Develop "Pleco Net" website area where we can see all the words we've search for, when we searched for them, our flash card history, definitions that we've changed or added --- basically store the history of each of our Chinese language skill development and our contribution back to the community.

What do you think? ;-)

Ryan Erwin
Shanghai, China

 

[mikelove]

SUMMARY

• Flash/Read: Reformat the Pleco Flash and Pleco Reader "Menus" to be more "iOS Style", akin to the default Springboard launcher or even the FaceBook/LinkedIn default app menu
• Flash: Allow creation of Flash Cards from inside Pleco Dict and Pleco Reader, but lauch "Pleco Flash" to do testing as a separate app that maintains state independant of Pleco Dict and Pleco Read
• Read: Allow Pleco Read to store recent clipboard history, and run as a separate app that maintains state outside of Pleco Dict and Pleco Flash
• Dict: Automatic online search for words, especially new words or words from recent days news during dictionary queries
• Dict: Simply/speed up process to add new entries to the dictionary
• Dict: Easily add new "sound recordings" to dictionary entries by pressing and holding on the "speaker" button for each entry
• Develop "Pleco Speech" module that enables visual comparison of sound waves for syllables, words, phrases, and even entire passages
• Develop "Pleco Net" website area where we can see all the words we've search for, when we searched for them, our flash card history, definitions that we've changed or added --- basically store the history of each of our Chinese language skill development and our contribution back to the community.

Ryan,

Thanks for the detailed feedback!

Multiple Apps - unfortunately, there's no practical way for us to do this on iOS while still allowing them to share their data; in theory we could have three separate apps that synced with a server somewhere, but the lag / delays that would impose would more than cancel out any speed benefits from being able to launch them more quickly. We could create an app that would simply launch the main Pleco app and tell it to jump right into flashcards, but Apple would never approve it; that might be an option for jailbroken iPhones, though, and it's certainly possible on Android.

We could make the process of getting into these screens a bit more convenient, though. We already have, actually; if you go into Settings / General / Startup and turn on "restore last tab" that will save you two of those four taps by bringing you back into the tab you were in before. Options to auto-resume flashcard / reader sessions might be possible in a future release too.

Grid - this is certainly doable, but my concern with it is that it takes away the opportunity for us to put helpful explanations below each item (something we'd been planning to do more of in general since our settings screens are so confusing). I do like the feel of that, though, particularly in a case like the reader where you're really looking at a bunch of independent mini "apps."

Clipboard history - good idea, and not too difficult to implement.

Sound recording - much-requested; we've actually just licensed a text-to-speech library that should help a little on this front (it'll read a lot of words more smoothly), but embedded audio and images in flashcards are a very popular feature request.

Audio comparison - this is really tough; we saw a demo of the state-of-the-art in this a couple of years ago (something originally developed for US military linguists) and it was so unreliable as to be almost useless. We'll keep an eye on it but I don't think it works well enough for us at the moment.

Pleco Online - this one's a licensing problem; displaying entries from licensed dictionaries on a website would require a new license for each dictionary, much as Apple had to go around and negotiate new licenses with all of the music companies for iTunes Match. And that probably means we'd also have to charge for said website.

As far as using a website to create / edit dictionaries, that's certainly on our radar (we'd also use it for existing dictionary review / editing in cases where we do have the necessary licenses), but I think frequent offline database updates would make more sense than online integration; if we come up with a good way to do delta updates (only download the bits that have changed, like in Google Chrome) we could push new entries and revisions down very very efficiently and end up using up a lot less of your bandwidth than we would going online for every search. But in any case, since there'd need to be some sort of a review / editorial process for changes it's unlikely the database would be continuously updated anyway, so the benefits of fetching it online would be limited.

Easier dictionary entry creation - you mention this in the summary but not anywhere else; how could we make it easier than it is now? Auto-filling in pinyin / alternate character sets, or are there just too many button presses in the current version?

 

[numble]

Having to constantly press the "fan" to get to navigation is poor UI design in my opinion. Especially on the iPad with all that extra space. Having to manually dismiss the keyboard before you can even press the "fan" is even worse. Other apps seem to be able to contextually know when to bring up the keyboard and dismiss the keyboard.

I think one of the reasons I like Anki on my iPhone is that I can bring it up and start flashcard testing immediately. It was designed for that purpose and I don't need to muck about in the settings to do it. Turn on iPhone, press the Anki icon, and have at it. Very useful when you're standing in a line, I've even used it a lot when stopped at a long red light.

 

[mikelove]

Having to constantly press the "fan" to get to navigation is poor UI design in my opinion. Especially on the iPad with all that extra space. Having to manually dismiss the keyboard before you can even press the "fan" is even worse. Other apps seem to be able to contextually know when to bring up the keyboard and dismiss the keyboard.

Keeping the fan visible with the keyboard might be possible, especially once we drop support for iOS 3, but the issue with eliminating it altogether on the iPad is that we effectively also have to kill the bottom toolbar - the problem of hitting buttons stacked on each other is even more acute on iPad than on iPhone, we've tested it quite a bit and you simply can't reliably tell whether you're hitting a toolbar button or switching tabs.

I think one of the reasons I like Anki on my iPhone is that I can bring it up and start flashcard testing immediately. It was designed for that purpose and I don't need to muck about in the settings to do it. Turn on iPhone, press the Anki icon, and have at it. Very useful when you're standing in a line, I've even used it a lot when stopped at a long red light.

I guess I'm just not seeing how a couple of taps make a difference in that... I suppose we could always try building a fast Pleco flashcard launcher app and submitting it to Apple - 90% chance they'll reject it, but you never know - but is it really that big a mental block to have to go through three or four taps instead of just one to get to flashcards? Would customizable toolbars help with this, so that you could (for example) replace one of the bottom dictionary toolbar buttons with a "begin flash session with currently selected profile" button?

 

[radioman]

I wanted to weigh in on this. Others opinions may vary, this is mine.

A few taps to bring up critical functions is too many taps.

If you asked me a few weeks ago, my opinions might have not been quite the same. But since starting the university classes, I have adjusted my opinion of Pleco, and specifically the OCR feature from fun "novelty" to a radically impressive must-have tool.

I will attempt to break this down to two major scenarios - 上课 and 下课。

*******************************
WHILE IN CLASS

OCR - Sitting in class reviewing one of 5 books, there is a paragraph I need to read out loud to the class - I know 95% of the words. I take a picture using OCR and within seconds convert it in the iPhone and have the whole thing converted to text in the reader function. Now I can read everything, save flashcards, and everything else. Very cool indeed.

DICTIONARY - When I am in class, the teacher might say a word I want to look up and store for later study. Obviously, Pleco handles this very well.

THE PROBLEM: In class, I use Pleco and need to real-time collect information, including OCR and keying input into the dictionary. The current program configuration leaves me jumping to get things set up right, bringing up modules, etc. One 50 minute class, I might look up 8 words via keyboard, and OCR a paragraph and 5 other words at separate times. This adds up to 6 switches to OCR and 6 switches to the dictionary. With 4 classes a day, this is like 50 switches a day, with each switch requiring a "reconfiguration". Even if there was only 10 switches a day, I would respectfully argue that it is still a lot of reconfiguring.

IDEA FOR SOLUTION:
I am wondering if there might be a simple way to have a stripped down OCR utility without the full dictionary functions (or maybe NO dictionary functions) - Where once the character is captured with confidence, you write it to the pasteboard (Pleco's pasteboard input function works great). The same could be done with block capture.

After capture, the user would then hot-swap to the dictionary function where the the pasteboard input is handled just as the current product handles it. No mods would need to be made to the main program as it sits now. As for Advanced OCR functions, like word list capture, etc, they would still only be accessible through the OCR interface on the main program.

*****************************
AFTER CLASS

FLASHCARDS: After class, its time to really study - flashcards. My general view is that, outside of class, flashcards should be running 100% of the time. When I have time, I just bring the flashcard session out of the background. Having it up and running means I can start it fast, and am more likely to use it.

In reality, outside of the classroom, 98% of my Pleco time might be spent on flashcards where hours of continuous use is not uncommon.

DICTIONARY: When out and about, I need to look things up. Therefore I need access to the dictionary many times a day. OCR as well.

THE PROBLEM: When I do look-ups of words in the dictionary, I need to exit my Flashcard Sessions.

IDEA FOR SOLUTION:
With the bulk of the time being spent in flashcard sessions, I am thinking that if there was a way to during a flashcard session to gesture and bring up a full-feature, full-screen dictionary screen, this would address my issue. Bottom line is that, if there was a way to get rid of the multi-prompting, I believe it would be very helpful.

Separate flashcard and dictionary programs would be great, but I am guessing this technically is no small challenge. Maybe iCloud would provide an easy way to move around/API the data.


*****************************************
READER
The reader is great, and a bit of a different animal. I use it in and out of the class. However, I consider it a more focused activity, where I am not walking around or doing other things. When using it, I am much more likely to not be interrupted with a need to do an unrelated dictionary look-up. Maybe as I use it more, my perspective on this will change.

 

[mikelove]

THE PROBLEM: In class, I use Pleco and need to real-time collect information, including OCR and keying input into the dictionary. The current program configuration leaves me jumping to get things set up right, bringing up modules, etc. One 50 minute class, I might look up 8 words via keyboard, and OCR a paragraph and 5 other words at separate times. This adds up to 6 switches to OCR and 6 switches to the dictionary. With 4 classes a day, this is like 50 switches a day, with each switch requiring a "reconfiguration". Even if there was only 10 switches a day, I would respectfully argue that it is still a lot of reconfiguring.

IDEA FOR SOLUTION:
I am wondering if there might be a simple way to have a stripped down OCR utility without the full dictionary functions (or maybe NO dictionary functions) - Where once the character is captured with confidence, you write it to the pasteboard (Pleco's pasteboard input function works great). The same could be done with block capture.

After capture, the user would then hot-swap to the dictionary function where the the pasteboard input is handled just as the current product handles it. No mods would need to be made to the main program as it sits now. As for Advanced OCR functions, like word list capture, etc, they would still only be accessible through the OCR interface on the main program.

I'm not quite seeing the issue here - right now you can flick between OCR and the dictionary with exactly two taps; tap on the menu ("fan") button, then tap on the Dict tab to switch back into the dictionary, or tap on the menu button and tap on the Read+OCR tab to switch into OCR. At an absolute minimum, switching between apps would also require two taps - press the home button and tap on the app's icon - and that's assuming that both apps' icons are on the same screen and that neither one is buried in a folder. There's also a significant likelihood of extra loading time if iOS decides to evict one app while it's running in the background, which when you're talking about still image OCR (which uses a TON of memory) is likely to happen quite often.

THE PROBLEM: When I do look-ups of words in the dictionary, I need to exit my Flashcard Sessions.

You actually don't; you can tap on the same menu "fan" button to switch from the Flash tab to the Dict tab, then back to Flash afterwards. Again, two taps, so there's no way that a separate app could possibly make this faster.

Is your problem maybe that the menu button on both of those screens is located at the top right corner rather than the bottom right? We did that for ergonomic reasons (in both of those screens we're trying to keep the buttons at the bottom as big and easy-to-hit as possible) but it's proven to be enough of a usability issue that we're planning to move the fan to the bottom right in 2.3 (carving out a corner out of the rightmost button in each screen).

 

[ryan erwin]

NOT ONE APP - BUT THREE APPS
Also, reader has 6 different options (in my version) and flashcards have 11. Might take a look at the FaceBook app or LinkedIn app for how they deal with choosing from a set of options... They have the "grid/menu" button on the top left, and pages of icons that you can flip... Makes a lot of sense based on the way the regular iPhone launcher works.

Actually, if you broke Pleco into 3 separate Apps: PlecoDict, PlecoFlash, and PlecoRead, and internally those Apps had menus more like the FaceBook/LinkedIn apps, I think much of the confusion of using Pleco would vanish. This way, settings and add-ons could either be on the "2nd page" of the FaceBook/LinkedIn/iOS style menu --- keeping it uncluttered, or you could move these into the iOS System Settings area.

Now that iCloud support has gotten very good, it seems that breaking Pleco into PlecoDict, PlecoReader and PlecoFlash could be a good option.

Another shorter term option to consider is enabling swipe leftup and swipe right to swap between Dict, Reader and Flashcard functions inside Pleco. If someone actually needs to go into Settings or Add-ons, they can hit the strange little "fan menu" and still get to the original options.

Swiping should allow me to keep the active flash card session exactly where it was, while I go to look up a word or read something I copied in reader. We definitely never need to see a dialog saying "Flashcard Testing: Start: Resume Test In Progress? Cancel Test In Progress?". Just resume --- If I need to cancel I can always hit the "X" on top. Also, clipboard reader should have built in clipboard history (at least most recent 10 entries that Pleco saw), maybe swiping up/down could allow you to quickly toggle between them.

Last up, I think you should enable Google Analytics or something similar in Pleco so that you can track how people are actually using it. There's a ton of functionality in Pleco, but the interface always feels strange --- sort of the way Java apps built for all platforms always had this strange, awkward feeling. Evernote for iOS has a similar amount of functionality, but the interface seems much cleaner.

No offense Mike, but as the years go on, the more I hit that fan menu, the more annoying it is. Putting the fan menu button in a different location in Flash Card mode makes it even more annoying. Pleco is the only app that uses this sort of mechanism, but it certainly isn't the most complicated App in the App store. If swipe for next screen is good enough for millions of homescreens, I think it's good enough for Pleco. If you really want to give users power, you can let them configure which screen is which feature somewhere in their settings. For me, I would do:

1. Dict
2. Pasteboard Reader (swipe up/down for history)
3. Flashcards

I could open up the menu thing if I actually need to use OCR mode (nifty gimmick to impress friends, but doesn't really work if you ask me), Document Reader, Web Reader, Lyrics Reader, Manual, Add-Ons, and Settings.

 

[mikelove]

Now that iCloud support has gotten very good, it seems that breaking Pleco into PlecoDict, PlecoReader and PlecoFlash could be a good option.

It's not nearly good enough for that, I'm afraid. And to be honest the administrative hassles for both us and our users associated with that move would be MASSIVE, to a point where they'd be really difficult to justify.

Another shorter term option to consider is enabling swipe leftup and swipe right to swap between Dict, Reader and Flashcard functions inside Pleco. If someone actually needs to go into Settings or Add-ons, they can hit the strange little "fan menu" and still get to the original options.

Swipes just don't work reliably enough for this - they really don't. They interfere with other gestures and other gestures interfere with them, and to be honest, if they did work well enough for this we'd probably use them for some screen-specific function (a command that people were likely to access all the time) instead.

Swiping should allow me to keep the active flash card session exactly where it was, while I go to look up a word or read something I copied in reader. We definitely never need to see a dialog saying "Flashcard Testing: Start: Resume Test In Progress? Cancel Test In Progress?". Just resume --- If I need to cancel I can always hit the "X" on top.

You shouldn't be seeing that now - the only reason you would would be if the system forced us to unload your flashcard test for memory reasons. Is this happening when you just switch tabs into the dictionary, or are you doing some other things too (say exiting the app)? In general we do want to get it reloading more seamlessly, though, since this transition ought to be imperceptible to the user regardless (the app should act like it's always open).

Also, clipboard reader should have built in clipboard history (at least most recent 10 entries that Pleco saw), maybe swiping up/down could allow you to quickly toggle between them.

This could be useful but I'm afraid it's a huge security issue - users don't want copies of their previous clipboard texts there without their knowledge; people copy-and-paste passwords, sensitive personal messages, corporate email... so it would have to be an off-by-default option, and and for the moment we're trying to avoid adding significant numbers of those, at least until we get through a few rounds of UI revisions to benefit everybody.

Last up, I think you should enable Google Analytics or something similar in Pleco so that you can track how people are actually using it. There's a ton of functionality in Pleco, but the interface always feels strange --- sort of the way Java apps built for all platforms always had this strange, awkward feeling. Evernote for iOS has a similar amount of functionality, but the interface seems much cleaner.

That's really just a matter of putting in the time to refine the UI, which we're doing now. We'd scarcely finished getting flashcards and OCR working on iPhone before we had to turn right around and do an Android version and we're only finally catching up on this...

No offense Mike, but as the years go on, the more I hit that fan menu, the more annoying it is. Putting the fan menu button in a different location in Flash Card mode makes it even more annoying.

That's changing - it'll go in the bottom right corner now, in OCR too.

Pleco is the only app that uses this sort of mechanism, but it certainly isn't the most complicated App in the App store.

Actually a variation on it has gotten to be extremely popular now, the top left corner menu button popularized by Facebook but also used in thousands of other apps. We make much heavier use of hierarchy than most of those apps do (going several layers deep into settings / dictionary entries / etc), so we prefer not to force users to go back to the root screen of a particular section before they can switch to a different screen, which is why our button lives at the bottom right corner instead, but it's the same principle - a hidden menu of alternate screens to jump to.

If swipe for next screen is good enough for millions of homescreens, I think it's good enough for Pleco.

Again, it just doesn't work well enough - if our app was like a homescreen in that it could only be scrolled horizontally and not vertically, we could certainly do it, but since we do make extensive use of vertical scrolling there's just no way to reliably distinguish a vertical from a horizontal scroll gesture - we inevitably end up mixing up one with the other and creating a tremendous amount of user annoyance in the process.

It sounds like your basic problem here is that you can't get to the dictionary as quickly as you'd like from flashcards - is that the case? When you do go to the dictionary from flashcards, is it because you want more information on a word you're already looking at, or is it because you want information on a totally different word that you just happened to wonder about in the middle of a flashcard session? Would it maybe help if we added a universal "go to dictionary" / "go to last non-dictionary screen" command, e.g. tapping-and-holding on the "fan" icon?

 

[Bendy-Ren]

Hi, Pleco user for several months here, this app is an indispensable part of my daily life. For what it's worth I agree with Ryan on the swiping thing. Mike, you mention Facebook as an example of another popular app with the "fan" -like functionality for making a menu appear, but in Facebook this menu can also be dragged open by swiping to the right. Both Facebook and Pleco use vertical scrolling, not horizontal, so I'm not really understanding why a horizontal swipe would be hard to implement.

I have two different options in mind for how this could work. One (the simpler way) would be just removing the "fan" button from the bottom menu bar. Instead, swiping horizontally to the right would reveal a new menu on the left side, in which would be all the options now contained in the bottom fan-out menu.

The other way would be even more intuitive, I think. You could have different "screens," one for each of the different modes, that you could swipe between from left to right. Dict, reader, flashcards, add-ons, and settings. You could even let the user rearrange them, or better yet, put add-ons inside the settings page so there are less screens to swipe between.

Maybe there's something I'm not thinking of, but I really hope you'll consider something like this in the future, as it could seriously improve the usability of the app. Just my two cents.

And hey, thanks for all your work! again, I wouldn't survive without Pleco.

 

[radioman]

A couple points on my side.

First, I am much more likely to be working for extended periods of time in a module than I am to be switching to another module. That is, the further I have to move away from the lower right to initiate a function, the more effort that is required.

Based on the above, I would offer that the extreme lower right should perhaps be reserved for high frequency current module activity (e.g., changing/selecting dictionaries, arrowing to the next definitions or pages).

The concept of swiping between modules I mentioned in the past (http://goo.gl/nwdhb), and I still think it would be intuitive. But given the integrated nature of Pleco's modules, I am guessing this would be very difficult to implement. My vote would be for directing development to (1) PDF reader and (2) optimizing OCR accuracy.

 

[mikelove]

Hi, Pleco user for several months here, this app is an indispensable part of my daily life. For what it's worth I agree with Ryan on the swiping thing. Mike, you mention Facebook as an example of another popular app with the "fan" -like functionality for making a menu appear, but in Facebook this menu can also be dragged open by swiping to the right. Both Facebook and Pleco use vertical scrolling, not horizontal, so I'm not really understanding why a horizontal swipe would be hard to implement.

When I try that swipe gesture in Facebook I find that it doesn't trigger about half the time - very often it turns into a scroll gesture instead. I've had a similar experience in other mixed horizontal swipe / vertical scroll apps. I try not to interpret my own fondness for a particular UI affordance to mean that everybody else would automatically like it too - that's why you can clear characters in more than one way in our handwriting input box - but if I can't get something working reliably then I usually take that as a sufficient argument not to include it, or at least not to rely heavily on it.

I have two different options in mind for how this could work. One (the simpler way) would be just removing the "fan" button from the bottom menu bar. Instead, swiping horizontally to the right would reveal a new menu on the left side, in which would be all the options now contained in the bottom fan-out menu.

That's no good for reasons of discoverability - people don't realize that gesture is there, or if they learn about it and then forget it it's hard for them to remember / find it again. I myself didn't know that gesture worked everywhere in Facebook until you just pointed it out (though I'll admit I'm not a particularly frequent Facebook user); absent the dedicated menu button I'm not sure if I'd know that Facebook has a menu at all.

The other way would be even more intuitive, I think. You could have different "screens," one for each of the different modes, that you could swipe between from left to right. Dict, reader, flashcards, add-ons, and settings. You could even let the user rearrange them, or better yet, put add-ons inside the settings page so there are less screens to swipe between.

Add-ons inside of Settings has been suggested lots of times, but we're not doing that because it's how we get paid (in fact it was originally the rightmost option but we eventually bowed to pressure to move it because people were hitting it by accident too often)

Swiping between screens like Safari does it - i.e., you zoom out and can scroll left or right - might be nice and intuitive, but it would actually slow things down - go from two taps to two-taps-plus-a-couple-of-swipes - so I don't think it would meet the needs of "power users" better than our current system.

Maybe there's something I'm not thinking of, but I really hope you'll consider something like this in the future, as it could seriously improve the usability of the app. Just my two cents.

Honestly I'm just not convinced that this would make things any more efficient - two taps to me feel more concrete and discoverable than a swipe, and they aren't even any slower unless you're swiping to a screen immediately adjacent to the one you're on and you can swipe reliably enough that it always works correctly on the first try.

So if you don't mind my asking, why do you think this would be an improvement? Do you very often find your finger far away from the menu button when you want to switch between screens? Does the Facebook swipe trigger correctly for you 100% of the time?

First, I am much more likely to be working for extended periods of time in a module than I am to be switching to another module. That is, the further I have to move away from the lower right to initiate a function, the more effort that is required.

Which functions do you find are too far away from the lower right now that might potentially be moved there?

The concept of swiping between modules I mentioned in the past (http://goo.gl/nwdhb), and I still think it would be intuitive. But given the integrated nature of Pleco's modules, I am guessing this would be very difficult to implement. My vote would be for directing development to (1) PDF reader and (2) optimizing OCR accuracy.

Actually not that difficult - we have one "master" view controller that could theoretically intercept / dispatch swipe events from anywhere - but I'm just not convinced yet that it's necessary or that it works well.

OCR accuracy for still images is mostly waiting on improvements to the library we license - there's a limited amount we can do unless we license another library just for still image recognition (possible) or they get around to improving the existing one. PDF reader is already done and just being refined now.

 

[dcarpent]

Could you say a little more about the PDF Reader being already done? Will it be in the "big update" that we are all awaiting? I find it helpful to scan Chinese books so that I can read them in Pleco. But my method results in an unformatted text that looks nothing like the published original. It is easy enough to scan a text to a pdf that preserves the look of the original, and then use Acrobat to OCR that page image to make it readable. Will the resulting PDF file then be readable in Pleco with this new feature? Any chance that the PDF file will be searchable?

 

[mikelove]

Could you say a little more about the PDF Reader being already done? Will it be in the "big update" that we are all awaiting? I find it helpful to scan Chinese books so that I can read them in Pleco. But my method results in an unformatted text that looks nothing like the published original. It is easy enough to scan a text to a pdf that preserves the look of the original, and then use Acrobat to OCR that page image to make it readable. Will the resulting PDF file then be readable in Pleco with this new feature? Any chance that the PDF file will be searchable?

It's still a little slower and more memory-intensive than we'd like, but I think it's probably in good enough shape now that we'd at least release it as an "experimental" feature even if we can't get polished up completely for that update.

We wouldn't actually be parsing the PDF - we're basically just treating it as a collection of image files - so no, I'm afraid it won't be searchable unless Apple adds code to do that for us.

 

[radioman]

Which functions do you find are too far away from the lower right now that might potentially be moved there?

This is what I am thinking.

I break the reader down into 2 scenarios that I use.

Scenario 1) I know a very high percentage of material (e.g.,the user has to "look up" a word or character maybe 5 times over the course of reviewing an entire iPad page of Hanzi.

Scenario 2) Large percentage of characters is not known (e.g. > one character per line). In reading in this mode, I want to:
- review the text using one hand.
- keep hand movement to a minimum.
- gain an understanding of the text being reviewed.
- store unknown words quickly for future review.

It is this second scenario that I will focus my comments.

In Scenario 2, when reading through the text, I do not want to spend a lot of time drilling down on character components, etc. That is left for a review of unknown words after the text and its meaning have been assimilated.


Current Approach to Scenario 2 -

When reading from a scanned PDF using the Block OCR reader with the green box, Pleco behaves differently than when using the Pasteboard Reader mode. Specifically, when using the Block OCR reader, the popup dictionary popup box cannnot be anchored to the bottom of the screen. The achored box provides a level of protection when using the arrow keys. Without the anchored box, if I am looking at text and hitting the advance-arrows, and inadvertently touch the screen just above the arrow, then
- 1) the cursor falls out of position,
- 2) the text where the cursor last resided is no longer highlighted, and
- 3) I need to reposition the cursor back to where it was within the text being displayed.

The ability to just press the arrows is very useful. Even if I only am only reviewing 1 or two characters on a given line of text, it is relatively easy to just hit the arrow a number of times to advance to the next characters of interest or even arrow through characters to take me to the next line or even a second line. As well, this method is very controlled.

I also find advantage to the fact that the definitons are anchored at the bottom and do not cover up the the paragraphs. It is less distracting when reading, even if I am advancing over text that is already highlighted.

When using the iPad in this mode, there are some ideas I believe that could enhance the overall interaction of the block recognizer as well as the upcoming PDF module, listed as follows.

1) Have the ability to anchor the dictionary window to the bottom for all "reading" type modes.

2) Make the arrow keys a bit bigger so that they are easy to hit when looking at the screen (and not necessarily the arrows themselves), perhaps the size of the clip/capture/hide_text buttons in height.

3) Utilize a protection mode that if you do not hit the arrows, the user will not loose the cursor position.

4) When reading text, as you advance down the page, allow a "swipe-up" or down gesture to scroll the text up while maintaining the cursor position within the text. And during this time, do NOT close the definition bubble (i.e., permanent anchor). If you do not swipe, but simply touch a character, it will move the cursor highlight to the new character/word.

5) With regard to cursor positioning, it might be worthwhile to implement an enhanced scrolling method that will allow the cursor to be rapidly advanced (something similar to Textilus, where 1 inch slide translates to approximately advancing 100 characters). The control is basicially placed between the arrows. And in the case of the Textilus implementation, seems to maintain good control.

6) In keeping with getting through a document, place the Plus sign for the flashcards toward the bottom of the screen above the left arrow (above the right arrow would be the dictionary switcher (see attachment).

Summarizing my thoughts on the attached,
- 1) Dictionary is permanently anchored.
- 2) + is above the arrow keys to quickly add unknown character to flashcard list
- 3) Dictionary key would be above the right arrow to easily cycle dictionaries
- 4) Arrow keys a bit taller

###

 

[mikelove]

Sorry for the slow response.

1) Have the ability to anchor the dictionary window to the bottom for all "reading" type modes.

Makes sense, though I have to double-check on the scrolling behavior with images in that case. (i.e., how difficult it would be to make the entire image still able to scroll into view - some of that code is extremely hairy)

2) Make the arrow keys a bit bigger so that they are easy to hit when looking at the screen (and not necessarily the arrows themselves), perhaps the size of the clip/capture/hide_text buttons in height.

This I'm a little less sure about since the iPad already does a pretty good job of redirecting presses to them from just outside of the toolbar - I'll double-check if we can expand the tappable area, though.

3) Utilize a protection mode that if you do not hit the arrows, the user will not loose the cursor position.

What sort of protection mode? Show some sort of lingering marker of the last position read? In general I still think this sort of scanning-along is something we want to discourage - if you're only reading the English definitions and aren't aware of what Chinese you're reading then maybe you ought to go back and review the whole sentence - but it might be simple / popular enough to justify an option in spite of my pedagogical objections.

4) When reading text, as you advance down the page, allow a "swipe-up" or down gesture to scroll the text up while maintaining the cursor position within the text. And during this time, do NOT close the definition bubble (i.e., permanent anchor). If you do not swipe, but simply touch a character, it will move the cursor highlight to the new character/word.

Again I really don't like it pedagogically - you shouldn't be reading so much text with the popup that you're concerned about page scrolling; even at one character per line it's better to strain yourself to remember every character without the reader giving you a hint as you move through words. But we do get quite a lot of feedback about anchored / always available definitions, so it may be something we have to consider even if it's something I would never ever make a default.

5) With regard to cursor positioning, it might be worthwhile to implement an enhanced scrolling method that will allow the cursor to be rapidly advanced (something similar to Textilus, where 1 inch slide translates to approximately advancing 100 characters). The control is basicially placed between the arrows. And in the case of the Textilus implementation, seems to maintain good control.

Interesting reader possibility in general, though not the easiest thing to implement.

6) In keeping with getting through a document, place the Plus sign for the flashcards toward the bottom of the screen above the left arrow (above the right arrow would be the dictionary switcher (see attachment).

How about in between the right and left arrows? Putting above runs into the whole inaccurate-vertical-positioning problem I've mentioned here and in a few other places before.

 

[character]

Again I really don't like it pedagogically - you shouldn't be reading so much text with the popup that you're concerned about page scrolling; even at one character per line it's better to strain yourself to remember every character without the reader giving you a hint as you move through words.

"Reading with definitions" might be the fastest way to get through advanced/native material for a learner. While the market for graded reading material has exploded, it still looks to me like one will have to wade through material with lots of unknown words to get to literacy.

But we do get quite a lot of feedback about anchored / always available definitions, so it may be something we have to consider even if it's something I would never ever make a default.

IMO the big problem with popup definitions is that it breaks the context of the word/phrase. The user is looking at the characters in context, and then BOOM! the context is broken by having part of the document obscured by a popup. I think it makes it harder to choose the right definition because one can no longer see all the characters around the ones looked up. This is probably the only UI decision where I prefer Wenlin over Pleco.

 

[radioman]

What sort of protection mode? Show some sort of lingering marker of the last position read? In general I still think this sort of scanning-along is something we want to discourage - if you're only reading the English definitions and aren't aware of what Chinese you're reading then maybe you ought to go back and review the whole sentence - but it might be simple / popular enough to justify an option in spite of my pedagogical objections.

This is more a matter of convenience, along the lines of running down a predefined track, where the track is the text. Basically, in the protected mode, you would be destined to traverse through all of the characters. So if I tap outside the arrow area, I would not fall off the track.

This is a bit like the current "tap the sides to advance" mode, with two differences. First, you could only disable the new mode via some or button gesture, conveniently placed so there is no need to access a menu to turn the function on and off. Second, there is not this middle area that you use to turn the screen live again. So if I venture from the arrows in this mode, I would not fall of the track. As well, I would be able to reposition/scroll the text without having to reposition the cursor.

Mind you, I am in no way advocating the looking up of every word along the "track". That would be another issue entirely. But I can arrow through about 6 lines of text in about 12 seconds (16-20 words per line) and not "fall off track". Maybe it is just me, but Its much less laborious for me to press the arrow key rapidly 20 times than it is to reach up and touch the next character. And I always press the same place, conveniently in the lower right.

Using this method with a electronic document, you would read through the text. You then highlight a word because you do not know the definition of that word. Pleco gives you the definition. You now understand and move on. With the old word still highlighted and it's definition still anchored to the bottom, you continue reading the text. 18 characters later, you find another word you want to look up simply because you do not know the Pinyin tone. So rather than reach up across the iPad screen to try and target that exact word at the exact position on the screen, you would simply press the arrow 18 times. You would now, with confidence, arrive at the location of the word targeted for lookup.

To summarize, the process for electronic docs goes something like this "while" loop:

While Document still not finished reading {
- Read electronic doc
- Come across a word that requires look-up (for pinyin, for definition, etc.)
- Arrow quickly to the word in Pleco.
- Read info for word of interest in Pleco (Pinyin / Definition, etc.)
- Save word into flashcards (if interested)
}

Using this method with Pleco to mark up a paper document is more or less the same (I do this a lot). One of the nice things about the OCR Block function presentation is that the document on the paper and its rendering in Pleco are the same. So it's easy to tell where you are in the paper document and where you are in Pleco OCR block reader.

Basically, you bring up the document in OCR block function and have the paper doc on your desk. You read through the paper document. And as you run across words you do not know, you just advance via the arrow keys in Pleco to that word, and then mark up the paper. No reaching across the iPad to strike the character at the exact place. No falling off track. And with the dictionary entry anchored at the bottom, this becomes very convenient. You simply place the iPad above or next to the paper document you are going through. I personally place it so that the anchored definition at the BOTTOM of the iPad becomes the anchored definition at the TOP of the paper document. As most of my documents are sheets of paper, I can actually put the sheet partially under the iPad during this process so that I do not have to move my eyes very far from the active reading area on paper to the iPad definition.

The process for paper docs goes something like this:

While Document still not finished reading {
- Read paper doc
- Come across a word in Paper doc that needs to be looked up (for pinyin, for definition, etc.)
- Arrow quickly to the word in Pleco.
- Read info for word of interest in Pleco (Pinyin / Definition, etc.)
- Mark up paper doc with info of interest
- Save word into flashcards (if interested)
}

… and then BOOM! the context is broken by having part of the document obscured by a popup.

I also agree with this. Anchoring serves to place the definitions out of the way of the text so the text remains in context. I also think it makes it easier to justify simply anchoring the definition and leaving the last looked up word up in the anchored definition box, where it is out of the way of the text being read.

When reading text, as you advance down the page, allow a "swipe-up" or down gesture to scroll the text up while maintaining the cursor position within the text. And during this time, do NOT close the definition bubble (i.e., permanent anchor). If you do not swipe, but simply touch a character, it will move the cursor highlight to the new character/word.

Again I really don't like it pedagogically - you shouldn't be reading so much text with the popup that you're concerned about page scrolling; even at one character per line it's better to strain yourself to remember every character without the reader giving you a hint as you move through words. But we do get quite a lot of feedback about anchored / always available definitions, so it may be something we have to consider even if it's something I would never ever make a default.

I hopefully clarified this a bit further in my above explanations with regard to swiping up to allow simple repositioning of text on the screen.

5) With regard to cursor positioning, it might be worthwhile to implement an enhanced scrolling method that will allow the cursor to be rapidly advanced (something similar to Textilus, where 1 inch slide translates to approximately advancing 100 characters). The control is basicially placed between the arrows. And in the case of the Textilus implementation, seems to maintain good control.

Interesting reader possibility in general, though not the easiest thing to implement

I really don't know what it would take. But with the concept of advancing rapidly through horizontal text, it seemed like it could be useful. This is the type of thing I would think would go between the arrows, rather than the flashcards plus sign. The reason I say this is that, if you are rapidly advancing the cursor and overshoot, then you would want to hit the back arrow. With the arrow keys adjacent, this is a simple matter where you probably do not even have to be looking at the arrow keys to reposition your finger from forward arrow to reverse arrow.

I like the Textilus idea. And I also like discretely hitting the arrow (I find it fast and accurate). But I think another complimentary way to approach this is to have the arrows have a press-and-hold mode, where if you hold the arrow it will quick-advance. And if you hold it for more than 3 seconds (or some settable number?) it will enter some rapid hyper-cursur-advance mode. And, as always, this could all be an "optional / non-default" setting.

6) In keeping with getting through a document, place the Plus sign for the flashcards toward the bottom of the screen above the left arrow (above the right arrow would be the dictionary switcher (see attachment).

How about in between the right and left arrows? Putting above runs into the whole inaccurate-vertical-positioning problem I've mentioned here and in a few other places before.

The reason I originally drew the box was to provide a concept of a small control panel. The 4 quadrants included: 1) flashcard add; 2) dictionary switch; 3) Arrow Left; 4: Arrow Right. I was really just trying to illustrate a simple way to implement this "track" concept that maintained the following ideas:
- The main theme is to keep everything lower right (for right handed), the more frequently used, the further right they go.
- keep the arrow keys in the lowest right quadrant positions, and
- keep the arrow keys together.

With the current interface, and with anchoring, the dictionary switch buttons appear placed in a reasonably good spot, right above the arrow keys. To round out the quadrant, it would seem to make sense to simply put the flashcard add in quadrant 1. But if it was alternatively placed at the bottom to the left of the left arrow, that would certainly provide the functionally I am trying to get implemented.


To summarize, the following modifications to the OCR block function (and subsequent PDF reader) would provide the functionality I have been describing in this continuing post.

a) Keep the arrows next to each other, and at the far right (where the fan is now).
b) Move the flashcard plus button to the bottom toolbar next to the left arrow.
c) Have the word-shortening arrows to the left of the flashcard plus button.
d) Make the arrows a bit taller (if possible).
e) Add arrow press-and-hold acceleration functions to rapidly advance the cursor.
f) Anchor definitions to the bottom of the screen, permanently (have it optional).
g) Add a swipe gesture that will scroll the page without repositioning the cursor (a form of protection)
h) Add Protected Mode function to prevent the user from tapping any characters for lookup (i.e., falling off the track). Have a button toggle that is easily accessible during a reading session (but can be at the top toolbar, but preferably not buried in a menu).

 

[mikelove]

IMO the big problem with popup definitions is that it breaks the context of the word/phrase. The user is looking at the characters in context, and then BOOM! the context is broken by having part of the document obscured by a popup. I think it makes it harder to choose the right definition because one can no longer see all the characters around the ones looked up. This is probably the only UI decision where I prefer Wenlin over Pleco.

Interesting - I've actually just had an email conversation with someone to this effect as well. And nobody complained when it worked this way in our Palm/WM apps. The context break can be fixed by the option to anchor the popup to the bottom of the screen, but certainly with an always-available definition it would be even less intrusive. And nobody can accuse us of copying their UI since we were already doing it this way years ago

Using this method with a electronic document, you would read through the text. You then highlight a word because you do not know the definition of that word. Pleco gives you the definition. You now understand and move on. With the old word still highlighted and it's definition still anchored to the bottom, you continue reading the text. 18 characters later, you find another word you want to look up simply because you do not know the Pinyin tone. So rather than reach up across the iPad screen to try and target that exact word at the exact position on the screen, you would simply press the arrow 18 times. You would now, with confidence, arrive at the location of the word targeted for lookup.

So pretty much the same thing as the Palm/WM reader, again.

I really don't know what it would take. But with the concept of advancing rapidly through horizontal text, it seemed like it could be useful. This is the type of thing I would think would go between the arrows, rather than the flashcards plus sign. The reason I say this is that, if you are rapidly advancing the cursor and overshoot, then you would want to hit the back arrow. With the arrow keys adjacent, this is a simple matter where you probably do not even have to be looking at the arrow keys to reposition your finger from forward arrow to reverse arrow.

Well the biggest issue I'm having with it is that I'm not sure when a user would want to reposition the cursor in this particular way - if you need to scan through a sentence word-by-word (however much we may discourage that) then you're going to want to control the timing of each word advance by yourself, and if you want to look up a particular problematic word then it's much easier to just tap on that word rather than scanning through all of them.

With the current interface, and with anchoring, the dictionary switch buttons appear placed in a reasonably good spot, right above the arrow keys. To round out the quadrant, it would seem to make sense to simply put the flashcard add in quadrant 1. But if it was alternatively placed at the bottom to the left of the left arrow, that would certainly provide the functionally I am trying to get implemented.

It's just that vertical stacking gets very awkward, both because users have difficulty positioning their fingers accurately and because iOS attempts to compensate for that by redirecting touches to a different row when we might not want it to.

 

[radioman]

Well the biggest issue I'm having with it is that I'm not sure when a user would want to reposition the cursor in this particular way - if you need to scan through a sentence word-by-word (however much we may discourage that) then you're going to want to control the timing of each word advance by yourself, and if you want to look up a particular problematic word then it's much easier to just tap on that word rather than scanning through all of them.

I personally am happy with pressing the arrow multiple times to advance to the next unknown word.

The ability to move the cursor "down the track" is especially helpful if you are marking up a paper document. Pleco has the document image, and you are simultaneously looking at the sheet of paper. So the sheet is the master doc for which you are reading. You read, and find a word 20 words down the line you do not know. So you just press the arrow keys and arrive at the word.

This is arguably a bit different where you are reading off of Pleco directly and are physically staring constantly at the characters within Pleco. Perhaps in this situation it might be convenient to tap the character. But in the case of marking up paper, where the paper is the "master", you would need to look up at the Pleco screen, find the position, and then tap the character - this takes time. However, if you are just arrowing down the track, you can qucikly position with the arrows, almost without looking at the Pleco screen and have the cursor pretty much where it needs to be. A small adjustment of one or two characters with the arrow and you are looking at the definition.

I was just studying again for several hours using this method and it is extremely useful and fast - much easier than tapping the words. Respectfully, if tapping the words was easier, I would be tapping the words.

Even in the case where you are strictly using Pleco as a reader (with no paper mark-up involved), there are many times where I just want to use the arrows rather than reaching up on the iPad screen. But - frankly, there are times when I do want to tap the words. For instance, when I am using the iPhone, with it's smaller screen, or if the document is not too challenging, with just a few characters on a page to lookup.

 

[character]

I realize we may sound like delicate flowers asking that everything be just so, given you probably learned to read Chinese using a paper dictionary and native material while we're pissing and moaning about popups obscuring our 300-character level book. All I can say to that is the more Pleco allows the user to focus on the reading material with fewer distractions, the easier it is for everyone to read, from delicate flowers to people who can read most material at native speed.

Well the biggest issue I'm having with it is that I'm not sure when a user would want to reposition the cursor in this particular way - if you need to scan through a sentence word-by-word (however much we may discourage that) then you're going to want to control the timing of each word advance by yourself, and if you want to look up a particular problematic word then it's much easier to just tap on that word rather than scanning through all of them.

I'm not sure I understand all of radioman's specific requests. I can see the value of allowing the user to advance through the document with the arrow buttons as they stand now. They keep the user's fingers out of the way, so the user can keep viewing the words in context (given a fixed definition area). One could view advancing through the document as a way to help learn the character combinations which form words (though understandably Pleco does not always guess the correct words in the context of the document).

The context break can be fixed by the option to anchor the popup to the bottom of the screen [...]

Just tried this, and have to disagree. There's still a change in what the user was looking at (the document) when tapping a character. If you do provide an always-available definition, please don't use the popup-style box you use now. Visually it indicates users should look at it, instead of the document, as it is hovering over the document. Whereas with a non-popup-style box (just a line separating the view of the document from the view of the definition) users can learn to ignore the definition box while reading the document, much like they have learned to ignore ads when reading an article on the web.