Thoughts on the Evolution of Pleco

[radioman]

@character, not sure if this helps clarify, but the overarching theme is to have the option to keep you "on the track" when reading.

Here is the original list:

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).

I'm quoting myself - but the fact of the matter is that Pleco, as it stands now, is almost where I want it to be with regard to the OCR block reader, and what I anticipate and hope would be the functionality for the PDF reader.

The protected mode (item h) would be nice, but f and g in and of themselves both would aid in maintaining the cursor position when interacting with the screen in locations other than directly on top of the positioning arrows. While not foolproof, it's probably enough.

Prioritizing the list to the 5 main items:
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.
...
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).
###

 

[radioman]

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

I agree with this. Having a dedicated definition area at the bottom (or left side, right, or top I guess...) makes a lot of sense to me. I always envisioned this kind of dedicated side-by-side panel arrangement for for both reader/dictionary or flashcards/dictionary. In all cases, the dictionary would bring up a definition and remain static (non-popup) until called upon again.

 

[mikelove]

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.

Oh it doesn't sound that way at all, cognitive load is a very big deal in UI design now.

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.

I don't think we would use that box - that UI is designed to emphasize the fact that it's a temporary overlay, which this wouldn't be - but I guess I misunderstood the context break here; I thought it had to do with the box actually covering up part of the sentence rather than it simply acting as a distraction in general.

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.
...
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).

Got it. Though the PDF reader and the OCR block reader are going to have exactly the same interface except for page scroll buttons, at least initially.

 

[radioman]

Got it. Though the PDF reader and the OCR block reader are going to have exactly the same interface except for page scroll buttons, at least initially.

Understood. My wish list for the PDF reader will be able to, out of the gate, do the following:

1) page sequentially,
2) go directly to a page via tying the page number or scroll bar,
3) some way to add a flashcard without having to run to the top of the screen (gesture, lower toolbar button, hack, etc.??), and
4) have (at least) a Anchoring mechanism similar to the current text reader. This is interesting as the current text reader anchoring method removes the fan from the lower right already.

Anyway, thats my two cents. I realize that the PDF is part of a much larger, all encompassing update, where my suggestions (especially #4) might be in reference to an interface that has already been retooled, and therefore no longer be in any relevant context. And I don't loose sight of the fact that the reader as it stands now is a life saver. Of special note is the horizontally cascaded png pages I currently use have really made things an order of magnitude easier. And of course, any PDF functionality will provide another great step. Basically... I'll take what I can get !!

 

[character]

I don't think we would use that box - that UI is designed to emphasize the fact that it's a temporary overlay, which this wouldn't be - but I guess I misunderstood the context break here; I thought it had to do with the box actually covering up part of the sentence rather than it simply acting as a distraction in general.

It's both, but the former is worse than the latter. I imagine having the definition change as one arrows through the document will be distracting, but at least what's displayed of the document will remain fixed, other than the moving highlight. So I'd like to see the option to fix the definition box so it is present whether or not one has tapped on a word.

a) Keep the arrows next to each other, and at the far right (where the fan is now).
c) Have the word-shortening arrows to the left [...]

So this is the way it is when a word has been tapped?

b) Move the flashcard plus button to the bottom toolbar next to the left arrow.

I don't know, it's hard to argue with the current placement with other definition/character-related tasks at top. OTOH, if there is a fixed definition area with a dictionary change button, perhaps there could be an option to add another button above it. If one is trying to go through the document and add a bunch of flashcards, one can two-hand the iPad, hitting the arrow key with one hand and the plus button with the other.

f) Anchor definitions to the bottom of the screen, permanently (have it optional).

Amen.

e) Add arrow press-and-hold acceleration functions to rapidly advance the cursor.

It does seem that there's a (non-configurable) delay on the arrow buttons; perhaps if that was eliminated/made configurable that would be sufficient? I'd rather not have modal behavior on arrow buttons; I suspect they would not work nearly as well in real life as you think they might.

g) Add a swipe gesture that will scroll the page without repositioning the cursor (a form of protection)

Would rather see an option of a 'scroll gutter,' where the document does not go all the way to the right edge and one could scroll the document there.

h) Add Protected Mode function to prevent the user from tapping any characters for lookup (i.e., falling off the track).

I apologize for not understanding this. Why is not losing cursor position so important? Is it possible there's a need which could be better met outside of the current document reader, such as a new function on the Reader main screen for Pleco to programatically to go through a selected document and make a list of recognized words, which the user could then add some/all to flashcards or export?

Thinking out loud: there's two modes in the current reader, the gray one with the fan and pg up/pg dn buttons and the black word lookup mode. It seems hard to merge the two, given the large number of buttons in total and the small number of buttons which can usefully be on on a touch screen at once. The gray screen seems fine the way it is, and probably works well for reading material at/below one's level. I guess the best way for this to work is if the current grey/black modes are left alone and there's a variation of the black mode (Assisted Reader?) which is made for fighting through advanced-for-the-user material. It should be possible to arrow one's way through the document without artificial delays on the arrows. It would be nice if there was an option of centering the highlighted word so the line it was on was in the center of the document's view. There should be a fixed definition area at the bottom. Perhaps its font should be configurable separately from the document. There should be a way to enter this Assisted Reader directly from the Reader main screen; there would also need to be a way to exit.

Just wanted to put that idea out as it might be easier to add such a reader than shoehorn conflicting priorities into the existing Document Reader.

 

[radioman]

a) Keep the arrows next to each other, and at the far right (where the fan is now).
c) Have the word-shortening arrows to the left [...]

So this is the way it is when a word has been tapped?

Yes, This would be the active configuration. To be clear, I am looking for one handed operation for reading a document in the iPad (more on the iPhone later).

b) Move the flashcard plus button to the bottom toolbar next to the left arrow.

I don't know, it's hard to argue with the current placement with other definition/character-related tasks at top. OTOH, if there is a fixed definition area with a dictionary change button, perhaps there could be an option to add another button above it. If one is trying to go through the document and add a bunch of flashcards, one can two-hand the iPad, hitting the arrow key with one hand and the plus button with the other.

I see the logic with regard to grouping of tasks onto the respective bars. However, addition of flashcards is a frequent activity which could be simply accomplished by moving my hand about an inch. I have been working with the iPad and iPhone and believe that putting the flashcard add button right in the middle of the bar navigation bar makes sense. So you would have 5 items: select char left; select char right; flashcard add; arrow left; arrow right. That I believe will make sense on the iPhone and iPad.

e) Add arrow press-and-hold acceleration functions to rapidly advance the cursor.

It does seem that there's a (non-configurable) delay on the arrow buttons; perhaps if that was eliminated/made configurable that would be sufficient? I'd rather not have modal behavior on arrow buttons; I suspect they would not work nearly as well in real life as you think they might.

Hmm… I figure this is a built in function for iOS, maybe its easy to test. Seems to work just fine for the delete key on the iOS keyboard, but that might be an oversimplification. But with that said, I figure this is a nice to have that does not sit at the top of my priority list.

Would rather see an option of a 'scroll gutter,' where the document does not go all the way to the right edge and one could scroll the document there.

The potentiall issue with this is that if there is a finger-sized area, then that is real estate that my PDF document or PNG OCR block document cannot utilize. The PDF files I constantly blow up in landscape mode to the full width of the page. This will be exacerbated with the iPad Mini (which I assume will be coming out) and smaller devices, where there will be a need to fight for all the screen real estate possible.

Scrolling in this manner I believe is relatively common. Most iOS document readers work in this way, and I know some maintain the the highlighted text position as well (e.g., GoodReader). I know Pleco has some additional things going on, but my hope is this can be acheived.

h) Add Protected Mode function to prevent the user from tapping any characters for lookup (i.e., falling off the track).

I apologize for not understanding this. Why is not losing cursor position so important? Is it possible there's a need which could be better met outside of the current document reader, such as a new function on the Reader main screen for Pleco to programmatically to go through a selected document and make a list of recognized words, which the user could then add some/all to flashcards or export?

The cursor position is important when running through a document, especially when marking it up. It makes it so I never have to go and find a word and tap it. It basically allows me to fully go through the document fast, sequentially, and in a well controlled and predictable way. And I only need one hand, located at the lower right.

I like the idea of a separate list. I was almost thinking that the list could be numbered as well. If you were marking up a document, you could just write a small reference number in the document, and then refer to your list. And of course, be able to add that list to your flashcard. I would consider this as a nice-to-have on my priority list.

It would be nice if there was an option of centering the highlighted word so the line it was on was in the center of the document's view.

I was thinking this as well. Not sure how it would look in practice (would it be disorienting as you went from line to line? But I suspect it would not be a problem. It would be especially helpful for the iOS devices with smaller screens where you constantly have to scroll to avoid moving the highlighted text to the bottom of the screen where it is then (1) no longer in context because you cannot see what is below it, and (2) so close to the definition being presented at the bottom of the screen as to be overly distracting).

Just wanted to put that idea out as it might be easier to add such a reader than shoehorn conflicting priorities into the existing Document Reader.

I believe what I have been referencing for the most part is this "Assisted Reader". But I would never request that the functionality be rolled into another module. The PDF and Block OCR Reader is the target. The PDF reader in particular is something I have been waiting for a very long time, and do not want to derail that in any way. I would much rather debate the virtues of the feature set that can reasonably be implemented into the current anticipated modules.

My condensed wish-list, as stated before is below. My sincere hope is that some of these are close at hand, and none of these would warrant the development a new module.

1) page sequentially,
2) go directly to a page via typing the page number or scroll bar,
3) some way to add a flashcard without having to run to the top of the screen (gesture, lower toolbar button, hack, etc.??), and
4) have (at least) a Anchoring mechanism similar to the current text reader. This is interesting as the current text reader anchoring method removes the fan from the lower right already.

 

[radioman]

EDIT - After using this a bit more, I am convinced this function would be very elegant and useful within the reader.
---------------------
I recently ran across "Swipeselection", a jailbreak add-on for iOS that allows you rapidly move the cursor and highlight text (I'm using it right now).

By using swipe movements across the keyboard or screen, you can rapidly move the cursor or even highlight text. It makes editing very simple, and seems to be an elegant way to move the cursor without having to move my hands from the bottom of the screen.

As best as I can tell, this type of swiping motion is currently not in use across the various buttons that constitute the current Pleco Reader GUI. But that is just a subjective view/comment on my part. Reality may vary.