2.3 / User Interface Enhancements

[mikelove]

1) I still miss the Palm version's ability to mix character-drawing and pinyin on lookup input. Having to the HWR and KEY buttons to go back and forth on iphone has always felt a little painful. Especially for 4 or 6 character phrases. Certainly there's a screen real estate problem on iphone (not ipad), and you'd have to draw in a cramped space, but for me this tradeoff would be well worth it.

My thinking on that has long been that we'd eventually get around to adding some sort of keyboard-y background to the HWR box; show all of the letters in the lower half of the box when the box is empty, tap on one of them to enter it, begin drawing a stroke to hide the letters and proceed with handwriting input - how would that work for you?

2) Would like to see the various "Reader" options integrated. Instead of choosing these at the beginning (Optical Char Recognizer; Document File Reader; Web Reader; Lyrics Reader; PasteBoard Reader), I'm imagining a single Reader, with multiple possible sources, analogous to running your browser, then selecting file or URL content sources, so once in Reader (which opens optionally with your last loaded source), you can select (File - document or Lyrics; Pasteboard; URL). And if Document is an image file you can OCR it from there.

That one I'm not so sure about... it'd be a convenience boost for heavy users but it would confuse the heck out of new ones, especially given Apple's efforts to downplay the whole file/folder concept in general on iOS.

3) Would love to see the Pasteboard/Live modes in Web Reader disappear. It would be much nicer to have them both available all the time, one with tap and one with tap-hold. I imagine IOS 4.3 could perhaps have some improvements in chinese handling to make this easier.

Impossible at the moment given the way WebKit handles text selection in linked text, but hopefully they'll be making improvements in this area soon.

4) Again related to screen real estate: on iphone, you have this terrible situation with web reading, where most pages are too small to be legible without blowing up the font, but if you blow up the font you have lots of scrolling to do. THe solution is to process the page to be like a document page - newlines removed, and font sizeable. You can do this now through selecting text, copying to pasteboard, making a file, and loading it into reader. But that's 3 or more steps that could all be done automatically.

Do the mobilizers linked from our iPhone web browser home page do a good job with this sort of reprocessing for you? We've been thinking about integrating them into our software more closely.

5) Another screen real estate issue that's been suggested elsewhere on the forum: auto-hide all the navigation and menu bars when in Reader mode, and redraw them on a tap anywhere on screen. All the pixels are precious reading space.

Lately I've been feeling more inclined to go with Apple's approach on this - have just one toolbar but keep it visible all the time - though the Kindle approach is worth considering too; again, though, a small convenience / ergonomics boost for heavy users may not be enough to offset the intimidating aspects of this for everyone else.

6) (sneaking in a feature request) Night mode is a great help in reducing eyestrain and increasing readability. Instapaper has a setting using (sensor or clock - not sure) to go into Night mode and out automatically. Saves repeated trips to Settings.

Probably the clock... good idea.

7) This is more of a question. In reader, I'm often tapping on words I pretty much know, have already made a flashcard for but at that reading moment am not absolutely positive of. Each time I tap on those words I'd like Pleco to note that fact on the flashcard, and perhaps increase the "staleness" score of the word so I can pop them up during my next flashcard review. If it does that now, great; if not, it would be a desirable small addition.

A "times added" statistic of some kind has been on our to-do list for a while now, we just have to come up with the right formulas to make use of it in our score algorithm.

When doing a tap-hold on the add button that lets you change the multi-level category, you are not asked for any confirmation when you select the category. It's easy to pick the wrong category when trying to expand to a deeper level with the arrow buttons. Once you do that, it's a big hassle to to manually edit the card categories to fix it. It would be a big help if there were some kind of screen that would let you confirm your selection.

How about if we just added an "undo" command for flashcard add operations? We've had a lot of requests for that and it seems much less annoying in this scenario than a confirmation prompt.

 

[jiacheng]

The undo command operation for flashcards would probably be sufficient to save me from any major frustrations should I add a flashcard to an incorrect category, although I'm not quite sure how it would be implemented, maybe a popup menu for the + button when you tap and hold it? I'm assuming it would be implemented and easily accessible in any mode that provides a + button, such as OCR mode.

There still might be value in implementing a 'save' button or something at the top of the screen after you select a category. My personal feeling is that it would not take anything significant away from the elegance of the UI and would probably be simple enough to implement. I don't think that most other operations that modify the flashcard database actually take any action directly after selecting a category.

Another suggestion might be on a tap and hold of the + button, provide the option to set the default category without actually doing the add. Then tap again to actually add the word to the category.

 

[mikeo]

1) I still miss the Palm version's ability to mix character-drawing and pinyin on lookup input. Having to the HWR and KEY buttons to go back and forth on iphone has always felt a little painful. Especially for 4 or 6 character phrases. Certainly there's a screen real estate problem on iphone (not ipad), and you'd have to draw in a cramped space, but for me this tradeoff would be well worth it.

My thinking on that has long been that we'd eventually get around to adding some sort of keyboard-y background to the HWR box; show all of the letters in the lower half of the box when the box is empty, tap on one of them to enter it, begin drawing a stroke to hide the letters and proceed with handwriting input - how would that work for you?

Sounds like a clever way of getting double use out of the same screen space. Yes, that would probably be grand (but of course one would have to try it on an actual system to be sure).

2) Would like to see the various "Reader" options integrated. Instead of choosing these at the beginning (Optical Char Recognizer; Document File Reader; Web Reader; Lyrics Reader; PasteBoard Reader), I'm imagining a single Reader, with multiple possible sources, analogous to running your browser, then selecting file or URL content sources, so once in Reader (which opens optionally with your last loaded source), you can select (File - document or Lyrics; Pasteboard; URL). And if Document is an image file you can OCR it from there.

That one I'm not so sure about... it'd be a convenience boost for heavy users but it would confuse the heck out of new ones, especially given Apple's efforts to downplay the whole file/folder concept in general on iOS.

It's not so much about files/folders - I find it kind of odd to be asked to choose what kind of thing I want to read FIRST, then, if I want to read something else, to have to back out of the menu 3 levels deep, then traverse down the menu again. To me the experience of reading is just reading, regardless of where the content comes from. That's why the browser analogy came to mind - the browser put all kinds of reading in one place - newsgroup, rss feeds, blogs, pdf files, etc.

4) Again related to screen real estate: on iphone, you have this terrible situation with web reading, where most pages are too small to be legible without blowing up the font, but if you blow up the font you have lots of scrolling to do. THe solution is to process the page to be like a document page - newlines removed, and font sizeable. You can do this now through selecting text, copying to pasteboard, making a file, and loading it into reader. But that's 3 or more steps that could all be done automatically.

Do the mobilizers linked from our iPhone web browser home page do a good job with this sort of reprocessing for you? We've been thinking about integrating them into our software more closely.

Yes, they help a lot. But a) they don't address the text size issue. You can force a document to be displayed (through settings) at any font size, without scrolling (assuming the document has no line breaks). You can't do that with the mobilizers - try to read a newspaper through one and you'll see that in webkit EITHER you can have a larger fontsize with horizontal scrolling, or a tiny (12 points or less) font size without horizontal scrolling. So even with mobilizers the goal of having both legible font size and no horizontal scrolling is NOT met. b) since I can't get Live/Pasteboard mode working reliably on my iphone 4, to make a text useable (i.e., font size big enough, no horizontal scrolling, tappable, and hold-tappable) I still have to turn it into a document. I'm just suggesting that the software do these things for me.

5) Another screen real estate issue that's been suggested elsewhere on the forum: auto-hide all the navigation and menu bars when in Reader mode, and redraw them on a tap anywhere on screen. All the pixels are precious reading space.

Lately I've been feeling more inclined to go with Apple's approach on this - have just one toolbar but keep it visible all the time - though the Kindle approach is worth considering too; again, though, a small convenience / ergonomics boost for heavy users may not be enough to offset the intimidating aspects of this for everyone else.

Personally I prefer how Kindle and GoodReader handle this (make the whole screen available to text) to iBooks' handling (which as you say hides all but the bottom toolbar). Either approach would give more lines of text then Pleco Reader does now. Instapaper, like Pleco, maintains two non-text lines, top and bottom (though the bottom menu is shorter than Pleco's in height).

7) This is more of a question. In reader, I'm often tapping on words I pretty much know, have already made a flashcard for but at that reading moment am not absolutely positive of. Each time I tap on those words I'd like Pleco to note that fact on the flashcard, and perhaps increase the "staleness" score of the word so I can pop them up during my next flashcard review. If it does that now, great; if not, it would be a desirable small addition.

A "times added" statistic of some kind has been on our to-do list for a while now, we just have to come up with the right formulas to make use of it in our score algorithm.

I would count it as a wrong guess on a flashcard test, if I had to look it up again while reading.

 

[mikelove]

The undo command operation for flashcards would probably be sufficient to save me from any major frustrations should I add a flashcard to an incorrect category, although I'm not quite sure how it would be implemented, maybe a popup menu for the + button when you tap and hold it? I'm assuming it would be implemented and easily accessible in any mode that provides a + button, such as OCR mode.

Yes, I think we'd do it as a tap-hold command since people seem to really dislike the iOS-standard shake-undo gesture.

There still might be value in implementing a 'save' button or something at the top of the screen after you select a category. My personal feeling is that it would not take anything significant away from the elegance of the UI and would probably be simple enough to implement. I don't think that most other operations that modify the flashcard database actually take any action directly after selecting a category.

I think this is more of a sign that we need to redesign that screen - either confine ourselves exclusively to the iOS standard of having multiple levels of screens in cases like this, or find some way to make it harder to select a category when you really just want to expand it.

It's not so much about files/folders - I find it kind of odd to be asked to choose what kind of thing I want to read FIRST, then, if I want to read something else, to have to back out of the menu 3 levels deep, then traverse down the menu again. To me the experience of reading is just reading, regardless of where the content comes from. That's why the browser analogy came to mind - the browser put all kinds of reading in one place - newsgroup, rss feeds, blogs, pdf files, etc.

True, but I'm more inclined to look at this as a sign that we need a simpler menu structure for opening document files (the only place where you'd run into that 3 level problem) - maybe a screen that lists all of your most recently opened documents in reverse order? Or recently added ones? Or just do away with the file browser altogether when opening document files and simply give people a flat list of every Pleco-compatible document we see in the file system (as with flashcard import files)? The <= button metaphor is very logical and well-established on iOS, so I don't really think it's a good idea to make life more confusing for new users by adding some sort of file chooser button menu thingy in the place of that easily-recognizable one.

So even with mobilizers the goal of having both legible font size and no horizontal scrolling is NOT met. b) since I can't get Live/Pasteboard mode working reliably on my iphone 4, to make a text useable (i.e., font size big enough, no horizontal scrolling, tappable, and hold-tappable) I still have to turn it into a document. I'm just suggesting that the software do these things for me.

Fair enough, but very very dicey to implement - LOTS of work on our end unless somebody knows of a good open-source library to extract only the interesting text content from a web page - so I think we may have to wait for help from Apple on this one.

Personally I prefer how Kindle and GoodReader handle this (make the whole screen available to text) to iBooks' handling (which as you say hides all but the bottom toolbar). Either approach would give more lines of text then Pleco Reader does now. Instapaper, like Pleco, maintains two non-text lines, top and bottom (though the bottom menu is shorter than Pleco's in height).

I think this is a classic functionality versus user-friendliness debate - for actually reading text you're probably better off with as much text display space -> as few toolbars as possible, but hidden toolbars confuse the heck out of users, while even a single always-visible one gives them a nice straightforward anchor point from which they can find their way to anything else they want to do. One of my biggest UI gripes with Android and before it with Palm OS is/was their hidden menu bars - I can't even count the number of emails we received over the years from Palm users who couldn't find the menu button on their devices.

Now admittedly we hide the very important tab bar in Pleco, but the button to access that tab bar is always visible and we bug you every time you open the app until you tap on that button at least once - it's also similar enough to the well-established window button in Safari that a lot of users are likely to be familiar with it.

I would count it as a wrong guess on a flashcard test, if I had to look it up again while reading.

Makes sense - my worry there is that people might look up a known word by accident (say by ->ing over it while reading) and get annoyed that there was not necessarily an easy way to undo that wrong guess flag once it happened.

 

[character]

Fair enough, but very very dicey to implement - LOTS of work on our end unless somebody knows of a good open-source library to extract only the interesting text content from a web page - so I think we may have to wait for help from Apple on this one.

I hear the Readability app has one, and it's not using it. :lol:

IIRC, if you tap-hold at certain points on a web page, the column of text will be selected. So perhaps the user could use that to copy the text.

 

[mikeo]

True, but I'm more inclined to look at this as a sign that we need a simpler menu structure for opening document files (the only place where you'd run into that 3 level problem) - maybe a screen that lists all of your most recently opened documents in reverse order? Or recently added ones? Or just do away with the file browser altogether when opening document files and simply give people a flat list of every Pleco-compatible document we see in the file system (as with flashcard import files)? The <= button metaphor is very logical and well-established on iOS, so I don't really think it's a good idea to make life more confusing for new users by adding some sort of file chooser button menu thingy in the place of that easily-recognizable one.

Good points, and thinking about it more I'd say there's really not a big problem with the document menu. The problem is that a) if you're reading a document and then want to read a web page or vice-versa, you have to traverse back out through document menus and down again through web menus (or vice-versa) to do it, and b) see below, web reading itself on the iphone is really problematic. Perhaps, a history list of recently opened documents AND web pages, available in both web reader and document reader, and the system knows how to open each? Probably there are better ways to make the web/document menu systems integrated or unified.

Fair enough, but very very dicey to implement - LOTS of work on our end unless somebody knows of a good open-source library to extract only the interesting text content from a web page - so I think we may have to wait for help from Apple on this one.

Without using webkit to display the final page, the mobilizers get you 95% of the way there, and Readability gets you maybe 100% -- the difference between a mobilized web page and a document is only the line endings (and perhaps the links, which most of the time one doesn't care about - if you do care, you can read it as a web page). Pleco already does all of this with manual user intervention - load a web page, copy, and paste, and you have a document that you can display at any font size without horizontal scrolling. So with a web page visible, tapping a button to have it transformed into a document for display (whether saved to the filesystem or not) is all I'm really looking for. Most of the web pages are short, so all the software has to do is mobilize it, remove linefeeds (and maybe links and pictures), copy all, paste, and open in a document window.

I think this is a classic functionality versus user-friendliness debate - for actually reading text you're probably better off with as much text display space -> as few toolbars as possible, but hidden toolbars confuse the heck out of users, while even a single always-visible one gives them a nice straightforward anchor point from which they can find their way to anything else they want to do. One of my biggest UI gripes with Android and before it with Palm OS is/was their hidden menu bars - I can't even count the number of emails we received over the years from Palm users who couldn't find the menu button on their devices.

Now admittedly we hide the very important tab bar in Pleco, but the button to access that tab bar is always visible and we bug you every time you open the app until you tap on that button at least once - it's also similar enough to the well-established window button in Safari that a lot of users are likely to be familiar with it.

Pleco is already setting-abundant, but there do seem to be real contradictions in the use cases, so a default to the current behavior, with a setting to auto-hide the navigators during Reading, would maybe be justified.

Makes sense - my worry there is that people might look up a known word by accident (say by ->ing over it while reading) and get annoyed that there was not necessarily an easy way to undo that wrong guess flag once it happened.

There are many settings tied to flashcards and testing (which personally I appreciate, because it offers a lot of self-testing options) so one more for this might (defaulted off) might be ok.

 

[mikelove]

I hear the Readability app has one, and it's not using it.

I believe that uses JavaScript to basically just reformat the page, so I don't know if it would actually clean it up to the point where we could pull the text out of it and nothing else.

Perhaps, a history list of recently opened documents AND web pages, available in both web reader and document reader, and the system knows how to open each? Probably there are better ways to make the web/document menu systems integrated or unified.

There is some logic to unifying those two, I suppose... maybe we could go all FTP-y and let you display a directory listing within the web browser and open documents from that?

Pleco already does all of this with manual user intervention - load a web page, copy, and paste, and you have a document that you can display at any font size without horizontal scrolling. So with a web page visible, tapping a button to have it transformed into a document for display (whether saved to the filesystem or not) is all I'm really looking for. Most of the web pages are short, so all the software has to do is mobilize it, remove linefeeds (and maybe links and pictures), copy all, paste, and open in a document window.

The problem is that that manual user intervention is essential - we don't know of any other way to seamlessly pull all of the text from the web page, there's no way to access Safari's built-in ability to extract text from a web page without the user manually selecting text. We could try to hack together something with JavaScript, but it would be very slow and likely fail on precisely the sorts of complicated web pages that you're most likely to want to use it on.

Pleco is already setting-abundant, but there do seem to be real contradictions in the use cases, so a default to the current behavior, with a setting to auto-hide the navigators during Reading, would maybe be justified.

True, but a lot of effort to implement for an off-by-default option.

There are many settings tied to flashcards and testing (which personally I appreciate, because it offers a lot of self-testing options) so one more for this might (defaulted off) might be ok.

Reasonable enough, and probably a good thing to plan around now while we're re-thinking the flashcard statistics / history system anyway.

 

[mikeo]

Perhaps, a history list of recently opened documents AND web pages, available in both web reader and document reader, and the system knows how to open each? Probably there are better ways to make the web/document menu systems integrated or unified.

There is some logic to unifying those two, I suppose... maybe we could go all FTP-y and let you display a directory listing within the web browser and open documents from that?

Sounds fine to me.

The problem is that that manual user intervention is essential - we don't know of any other way to seamlessly pull all of the text from the web page, there's no way to access Safari's built-in ability to extract text from a web page without the user manually selecting text. We could try to hack together something with JavaScript, but it would be very slow and likely fail on precisely the sorts of complicated web pages that you're most likely to want to use it on.

Maybe the Javascript wouldn't be so slow - it's not really doing much other than copying, skipping everything but text.

Probably not an option, but noticed this jscript for selecting all text in form: http://www.javascriptkit.com/script/scr ... tall.shtml.

 

[mikelove]

Maybe the Javascript wouldn't be so slow - it's not really doing much other than copying, skipping everything but text.

I suppose... we could give it a try at least, though it'll definitely have problems with more complicated / dynamically-generated pages.

 

[ben_gb]

A flashcard suggestion...

It would be useful if, when you are adding a new flashcard, you could immediately go to the 'card settings' section of the new card so you can do things like Force Add to Pool, edit the card or change the dictionary used, at the time you add it, rather than having to remember to deal with it later.

Ben

 

[mikeo]

Maybe the Javascript wouldn't be so slow - it's not really doing much other than copying, skipping everything but text.

I suppose... we could give it a try at least, though it'll definitely have problems with more complicated / dynamically-generated pages.

Apple says IOS 4.3 Safari is 2X javascript speed, maybe that will help, at least 4.3-capable devices.

 

[mikeo]

Visibility of "Copy to Input"

I often use "copy to input" to fill in the search terms, delete one character, and search for the substring, for example, if the phrase is “绦虫病”，and the returned English is cestodiasis, you know the CHinese root will tell you the real meaning, so you "Copy to input“， delete the last character leaving 绦虫， and discover it's tapeworm. Where the definition is long, however, on iphone you'll need to scroll to bottom to get to the "Copy to Input" link. It would save taps and make scrolling unnecessary if that "Copy to Input" was placed optionally on a menu button or higher on the screen. Or even if there was a "delete last character and re-lookup".

Another plug for ｏｐｔｉｏｎａｌｌｙ　concatenating all definitions from all dictionaries on one results page - often the different dictionaries are good in their own ways -- some more up to date, some with more examples, some with better translations. I find myself often cycling through all the dictionaries on a single word/phrase, just to see all the entries. If these various dictionary entries were concatenated it would save these taps (though at the expense of scrolling, why can't lunch be free?).

 

[mikelove]

It would be useful if, when you are adding a new flashcard, you could immediately go to the 'card settings' section of the new card so you can do things like Force Add to Pool, edit the card or change the dictionary used, at the time you add it, rather than having to remember to deal with it later.

Good idea - would dovetail with some other things people have asked for post-flashcard-add (undo, option to display the duplicated card in the event of encountering a duplicate, etc).

Apple says IOS 4.3 Safari is 2X javascript speed, maybe that will help, at least 4.3-capable devices.

The question is what exactly they've improved - this isn't really a question of raw processing / math / etc, but of XML parsing / data access; have they sped up the parts of JavaScript that scan through the DOM pulling out pieces of text?

I often use "copy to input" to fill in the search terms, delete one character, and search for the substring, for example, if the phrase is “绦虫病”，and the returned English is cestodiasis, you know the CHinese root will tell you the real meaning, so you "Copy to input“， delete the last character leaving 绦虫， and discover it's tapeworm. Where the definition is long, however, on iphone you'll need to scroll to bottom to get to the "Copy to Input" link. It would save taps and make scrolling unnecessary if that "Copy to Input" was placed optionally on a menu button or higher on the screen. Or even if there was a "delete last character and re-lookup".

What about just tapping on that matching entry, then tapping on the headword? You can look up single characters instantly that way, or tap on the |-> button to look up additional characters without looking up the whole word.

Another plug for ｏｐｔｉｏｎａｌｌｙ　concatenating all definitions from all dictionaries on one results page - often the different dictionaries are good in their own ways -- some more up to date, some with more examples, some with better translations. I find myself often cycling through all the dictionaries on a single word/phrase, just to see all the entries. If these various dictionary entries were concatenated it would save these taps (though at the expense of scrolling, why can't lunch be free?).

That one's been a goal for years - concatenating the definitions is actually easy, but we feel like this feature only really works well if we're also concatenating search results; showing you every word from any dictionary that matches the search term you entered, but only showing each unique word once. We're working on some performance improvements to the database engine to help with that (2.2.3 has about a 5% speed boost but we think there's room for bigger gains) and hopefully soon it'll be working well enough even on very large result sets to make this feasible. Dropping support for iOS 3 will actually help somewhat, since we can start taking advantage of iOS 4's ability to do multi-threaded UI so that complicated searches won't make things as choppy as they do now.

 

[mikeo]

Apple says IOS 4.3 Safari is 2X javascript speed, maybe that will help, at least 4.3-capable devices.

The question is what exactly they've improved - this isn't really a question of raw processing / math / etc, but of XML parsing / data access; have they sped up the parts of JavaScript that scan through the DOM pulling out pieces of text?

With IOS 4.3 and Pleco 2.2.3, I noticed some speed improvements on web pages. More importantly, there's an improvement in Live/Pasteboard switching in Web Reader - I can usually get it to work (though it is still a bit finicky and does require enlarging the text in order to select) -- possibly this is due to improvements in IOS and isn't directly related to changes in Pleco.

To pick up an earlier thread:

4) Again related to screen real estate: on iphone, you have this terrible situation with web reading, where most pages are too small to be legible without blowing up the font, but if you blow up the font you have lots of scrolling to do. THe solution is to process the page to be like a document page - newlines removed, and font sizeable. You can do this now through selecting text, copying to pasteboard, making a file, and loading it into reader. But that's 3 or more steps that could all be done automatically. .

Do the mobilizers linked from our iPhone web browser home page do a good job with this sort of reprocessing for you? We've been thinking about integrating them into our software more closely..

Yes, they help a lot. But a) they don't address the text size issue. You can force a document to be displayed (through settings) at any font size, without scrolling (assuming the document has no line breaks). You can't do that with the mobilizers - try to read a newspaper through one and you'll see that in webkit EITHER you can have a larger fontsize with horizontal scrolling, or a tiny (12 points or less) font size without horizontal scrolling. So even with mobilizers the goal of having both legible font size and no horizontal scrolling is NOT met.

On iphone Web Reader will default display (mobilized or not) web pages' Chinese fonts in 12 or 14 point type, too small to really be legible without some eyestrain- if you pinch to expand, then you're doing lots of horizontal scrolling. It would be much less painful for the Reader to (optionally) pre-process these pages and treat them as documents (whether they exist on the file system or not is irrelevant to me - I just want them to be legible once), displayable in whatever font size the document reader has set (for me it's usually 22-27 points), with no horizontal scrolling. All that's necessary is to remove the hard CR/LF line endings. That alone would make Reader usable for Web reading that is really difficult now.

 

[mikeo]

That one's been a goal for years - concatenating the definitions is actually easy, but we feel like this feature only really works well if we're also concatenating search results; showing you every word from any dictionary that matches the search term you entered, but only showing each unique word once. We're working on some performance improvements to the database engine to help with that (2.2.3 has about a 5% speed boost but we think there's room for bigger gains) and hopefully soon it'll be working well enough even on very large result sets to make this feasible. Dropping support for iOS 3 will actually help somewhat, since we can start taking advantage of iOS 4's ability to do multi-threaded UI so that complicated searches won't make things as choppy as they do now.

Hurrah! Look forward to that!

 

[mikelove]

On iphone Web Reader will default display (mobilized or not) web pages' Chinese fonts in 12 or 14 point type, too small to really be legible without some eyestrain- if you pinch to expand, then you're doing lots of horizontal scrolling. It would be much less painful for the Reader to (optionally) pre-process these pages and treat them as documents (whether they exist on the file system or not is irrelevant to me - I just want them to be legible once), displayable in whatever font size the document reader has set (for me it's usually 22-27 points), with no horizontal scrolling. All that's necessary is to remove the hard CR/LF line endings. That alone would make Reader usable for Web reading that is really difficult now.

We can certainly add an option to strip newlines in the Web Reader pasteboard mode - we just added support for that to OCR so it stands to reason we'd do it here too. But I continue to feel like as far as full-page text extraction, we're better off extracting text from a web page externally through a mobilizer than internally in Pleco - it's faster, less memory-intensive and saves bandwidth to let an outside server discard the unnecessary stuff and send only the text to your iPhone. If the mobilizers out there now are lacking we can even think about setting up our own, but the case for doing this in-app is still pretty iffy...

 

[mikeo]

We can certainly add an option to strip newlines in the Web Reader pasteboard mode - we just added support for that to OCR so it stands to reason we'd do it here too. But I continue to feel like as far as full-page text extraction, we're better off extracting text from a web page externally through a mobilizer than internally in Pleco - it's faster, less memory-intensive and saves bandwidth to let an outside server discard the unnecessary stuff and send only the text to your iPhone. If the mobilizers out there now are lacking we can even think about setting up our own, but the case for doing this in-app is still pretty iffy...

You may be right that handling it out of the app is the best way. However it is done, seems it's a relatively small buck for a lot of user pain relief bang.

 

[mikelove]

You may be right that handling it out of the app is the best way. However it is done, seems it's a relatively small buck for a lot of user pain relief bang.

Potentially quite a lot of work, actually... a number of possible 2.3 improvements are on hold until we find out what Apple's doing in OS 5; the last two OS updates have both done huge things for us through unexpected / seemingly minor features, OS 3's addition of In-App Purchases made our entire business model possible and OS 4's direct camera access API was what allowed us to do live OCR, so it's quite possible that something in OS 5 might allow for better direct access to web pages.

 

[mikeo]

Potentially quite a lot of work, actually... a number of possible 2.3 improvements are on hold until we find out what Apple's doing in OS 5; the last two OS updates have both done huge things for us through unexpected / seemingly minor features, OS 3's addition of In-App Purchases made our entire business model possible and OS 4's direct camera access API was what allowed us to do live OCR, so it's quite possible that something in OS 5 might allow for better direct access to web pages.

Rumor mill is grinding out feature-predictions for IOS 5. I haven't seen web page access improvements mentioned, but you never know. Hope it happens in early April as rumored. Until then, there's gool ol' Clipboard line stripping.

 

[mikeo]

In Web Reader Live and Document Reader popup, if you tap on a character that is part of a longer expression in the dictionary, the highlighting changes to the longer expression and the dictionary entry for that pops up. Which is nice.

If you want the definition of the component characters, you need to navigate back and forth with the -> and <- arrows, to select subsets of the longer expression.

I'd propose (unless there's some unknown setting that affects this, or some inherent inconsistency) adding an additional behavior that would mimic or replace the function of the -> and <- arrows as follows:

1. With a longer expression highlighted, currently when you tap the highlighted expression the highlight disappears.
2. I'd propose a modification of that behavior - every time you tap the highlighted expression it collapses to the next smallest subset for which there is an expression in a dictionary (equivalent to hitting <-).
3. When you tap a highlighted single character it removes the highlight.

This would allow you to keep your attention on the highlighted words, and save trips back and forth to do arrow taps.