2.3 / User Interface Enhancements

mikelove

皇帝
Staff member
mikeo said:
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.

It'd be a very minor item on the feature list - not something people would be likely to leak - and might actually fit with the other changes they've made to JavaScript - there've been a few reports that the JavaScript improvements in iOS 4.3 don't work in web browsers embedded in apps, some people have suggested Apple's sabotaging third-party browsers but I think it's much more likely they're either a) making sure they don't change expected behavior in apps that rely on it or b) working on a new API for apps to interact with Safari and not wanting to backport the old one to the new browser.

mikeo said:
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.

Good idea - we already do this in OCR (since we don't have arrows but want to make the highlight resizable) so it makes sense to extend it to the reader too.
 

mikeo

榜眼
mikelove said:
mikeo said:
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...

BTW, the Instapaper iphone app handles Chinese (or other) websites very nicely - you can expand text size without inducing horizontal scrolling, adjust inter-line spacing, margins, choose black on white or white on black.

I copy URLs directly into the Instapaper app, and I suppose it's processing the text on the server side using their mobilizer. Of course, Instapaper has no Pleco-esqe features, so adjustments to Pleco Reader are still fondly wish'd.

See http://world.people.com.cn/GB/8212/1916 ... index.html in Instapaper
 

mikelove

皇帝
Staff member
mikeo said:
BTW, the Instapaper iphone app handles Chinese (or other) websites very nicely - you can expand text size without inducing horizontal scrolling, adjust inter-line spacing, margins, choose black on white or white on black.

I copy URLs directly into the Instapaper app, and I suppose it's processing the text on the server side using their mobilizer. Of course, Instapaper has no Pleco-esqe features, so adjustments to Pleco Reader are still fondly wish'd.

Does the mobilizer work less effectively when it's used in the Pleco web browser? Perhaps we need to interface with it at a lower level...
 

mikeo

榜眼
mikelove said:
Does the mobilizer work less effectively when it's used in the Pleco web browser? Perhaps we need to interface with it at a lower level...

I've found the Google mobilizer a bit less reliable - a couple of times it's had problems with a page here or there which the Instapaper mobilizer handled fine.

The Instapaper mobilizer that's linked on the Web Reader default page does the basic stuff well, no problem there. It needs to be more integrated with Pleco -- e.g., it ignores the Reader font size set in Settings, and there's no way to adjust the font size on the page being displayed.

Would be nice to have, as the Instapaper app provides, adjustable margins and inter-line separation, but these aren't really necessary.
 

jlnr

进士
This post is mostly a careless interface enhancement request without reading all 14 pages…不好意思!

I noticed a few times now that going from flashcard mode to the dictionary is pretty complex on the iPad. Most of the time, the grey bar is only on-screen to show the button for the black mode change bar. It would be much appreciated if the black bar was always there instead of the grey bar, which saves one tap.

With all the space on the iPad, I would even support an 'always show black bar' mode which makes Pleco much more discoverable imho. Right now, other people who want to use my iPad/Pleco as a dictionary just put it back when the flashcard screen jumps at them :)
- and where the grey bar only contains the Pizza pie 'reveal black bar' button, it could disappear altogether.
 

mikelove

皇帝
Staff member
mikeo said:
The Instapaper mobilizer that's linked on the Web Reader default page does the basic stuff well, no problem there. It needs to be more integrated with Pleco -- e.g., it ignores the Reader font size set in Settings, and there's no way to adjust the font size on the page being displayed.

Would be nice to have, as the Instapaper app provides, adjustable margins and inter-line separation, but these aren't really necessary.

Actually none of these would necessarily be difficult if Instapaper gives us a reasonably standard format for CSS - we can simply tweak it as it comes in to apply a different font size / margins / etc.

jlnr said:
I noticed a few times now that going from flashcard mode to the dictionary is pretty complex on the iPad. Most of the time, the grey bar is only on-screen to show the button for the black mode change bar. It would be much appreciated if the black bar was always there instead of the grey bar, which saves one tap.

With all the space on the iPad, I would even support an 'always show black bar' mode which makes Pleco much more discoverable imho. Right now, other people who want to use my iPad/Pleco as a dictionary just put it back when the flashcard screen jumps at them - and where the grey bar only contains the Pizza pie 'reveal black bar' button, it could disappear altogether.

The problem here is that it's really really hard to accurately tap buttons that are vertically stacked on top of each other on iOS. We've done experiments with this - with the black bar visible all the time, people inevitably end up accidentally switching tabs when they want to invoke one of the bottom toolbar commands, or hitting one of those commands when they want to hit a tab. This is, if anything, an even bigger problem on iPad, since the toolbar is the same size but people's finger positioning accuracy is lower on the larger / more distant screen.

We do need a better approach to the extra command / menu problem, if for no other reason then because we've got way more functions than it makes sense to squeeze into 5 tabs, but having two stacked toolbars at the bottom of the screen probably isn't the right way to do it.
 

Trickyt57

秀才
Enhancements wish list:
Card statistics: the score ranges are geometric, I.e 0 to 100, 100 to 200, 200 to 400, 400 to 800 and so on. Is there any way to turn them into linear, I.e. Ranges 0 to 100, 100 to 200, 200 to 300, 300 to 400, 400 to 500 and so on?

How about adding progress charts. Eg to see how many words we knew by date?

Can we add a French dictionary?

How about adding Cantonese?

Can we add a legal, business, financial, banking, investment, trust law, company administration, accounting type dictionary?
 

mikelove

皇帝
Staff member
Trickyt57 said:
Card statistics: the score ranges are geometric, I.e 0 to 100, 100 to 200, 200 to 400, 400 to 800 and so on. Is there any way to turn them into linear, I.e. Ranges 0 to 100, 100 to 200, 200 to 300, 300 to 400, 400 to 500 and so on?

The statistics screen is actually long overdue for a redesign, but your comment about a linear progression is interesting... are you studying flashcards in a way in which the scores are likely to increase linearly? The default Automated scoring system does geometric progression, as do most of the other popular flashcard systems that we're familiar with.

Trickyt57 said:
How about adding progress charts. Eg to see how many words we knew by date?

In the works, though keeping track of the necessary data is going to expand the size of our flashcard databases a good bit.

Trickyt57 said:
Can we add a French dictionary?

There's an open-source one that we're planning to include in our next big round of dictionary releases, just taking a while to get all of those lined up.

Trickyt57 said:
How about adding Cantonese?

We're working very very hard to get the licensing lined up for that - ongoing discussions for 3 different titles so hopefully one of them will actually result in a license.

Trickyt57 said:
Can we add a legal, business, financial, banking, investment, trust law, company administration, accounting type dictionary?

The C&T one is in that vein - you can search it Chinese-to-English with a full-text search.
 

mikeo

榜眼
I go through a lot of steps in Reader to add custom cards. If there's some setting or sequence that would reduce these steps, that would be great. If not, it would be fairly easy to automate them.

It's common that proper names aren't in the dicts: e.g., 赫尔岑。

To make a card for that, I

1) select 赫尔岑in Reader
2) tap "Copy" on popup menu
3) Go to Flashcards/Organize
4) Tap "New Card"
5) Paste in the characters
6) TYpe in the pinyin
7) Type in the romanized version of the name

Would be a lot easier to have an extra "make Card" menu item, that would fill in all the selected characters and their pinyin (which could, of course, be corrected by the user if the guessed pinyin is wrong), and prompt for the definition, then send an email about the entry to whomever is maintaining the dictionary so via the irresistable power of crowdsourcing subsequent dictionary versions would include all those submissions.
 

mikelove

皇帝
Staff member
mikeo said:
I go through a lot of steps in Reader to add custom cards. If there's some setting or sequence that would reduce these steps, that would be great. If not, it would be fairly easy to automate them.

Already exists, newly added in 2.2.2; go into Settings / Reader / Popup Reader and change "Unknown flashcard" to "Custom Card." (or "Custom Dict Entry" if you want to create a new user dictionary entry and a new card linked to it instead of just creating a custom card) After that, any time you attempt to create a card based on a text selection that doesn't have a matching dictionary entry you'll get the standard custom card creation box. No Pinyin guessing yet, though.
 

mikeo

榜眼
mikelove said:
Already exists, newly added in 2.2.2; go into Settings / Reader / Popup Reader and change "Unknown flashcard" to "Custom Card." (or "Custom Dict Entry" if you want to create a new user dictionary entry and a new card linked to it instead of just creating a custom card) After that, any time you attempt to create a card based on a text selection that doesn't have a matching dictionary entry you'll get the standard custom card creation box. No Pinyin guessing yet, though.

I had "Custom Card" set when I did the sequence above.

It still seems necessary to exit document reader in order to add the card, which is undesirable because it's more clicks and a distraction from the reading.

Is there a way in the current version to add a custom card from inside Reader?
 

mikelove

皇帝
Staff member
mikeo said:
It still seems necessary to exit document reader in order to add the card, which is undesirable because it's more clicks and a distraction from the reading.

Is there a way in the current version to add a custom card from inside Reader?

It shouldn't be necessary - what exactly happens when you try to add a flashcard with a word-that's-not-in-the-dictionary selected?
 

mikeo

榜眼
mikelove said:
It shouldn't be necessary - what exactly happens when you try to add a flashcard with a word-that's-not-in-the-dictionary selected?

If the selection is in a dict, then the "+" menu item appears at the top. If the selection is NOT in a dict, then the popup menu appears with "Copy|Search|Translate" options. From that point, the only way I can figure out to make a new card/dict entry is to exit reader, go to Flashcards, and do it there, then go back to Reader. What am I missing?!
 

numble

状元
Have you ever thought of replacing those under-the-searchbar buttons with more user friendly labels?
The labels "HWR, Rad, Key, Full, Wild" aren't exactly intuitive as to meaning.
 

mikelove

皇帝
Staff member
mikeo said:
If the selection is in a dict, then the "+" menu item appears at the top. If the selection is NOT in a dict, then the popup menu appears with "Copy|Search|Translate" options. From that point, the only way I can figure out to make a new card/dict entry is to exit reader, go to Flashcards, and do it there, then go back to Reader. What am I missing?!

Sorry, I wasn't explaining the meaning of "selection" correctly; if you tap on a word in the reader to bring up the popup "bubble," then tap on the -> button to expand it beyond its original boundaries, you can then tap on the + button to create a custom flaschard based on the selected text.

numble said:
Have you ever thought of replacing those under-the-searchbar buttons with more user friendly labels?
The labels "HWR, Rad, Key, Full, Wild" aren't exactly intuitive as to meaning.

It's tricky to fit in more than 3-4 letters per button... do you think icons would be an improvement? HWR (pen) and Key (keyboard) would be easy, the other three are tricky since we're trying not to use any more Chinese character icons (Rad) and "full" and "wild" aren't entirely clear concepts.
 

numble

状元
mikelove said:
It's tricky to fit in more than 3-4 letters per button... do you think icons would be an improvement? HWR (pen) and Key (keyboard) would be easy, the other three are tricky since we're trying not to use any more Chinese character icons (Rad) and "full" and "wild" aren't entirely clear concepts.
Yeah, I think icons make more sense, but those other 3 are tricky...
 

mikeo

榜眼
mikelove said:
Sorry, I wasn't explaining the meaning of "selection" correctly; if you tap on a word in the reader to bring up the popup "bubble," then tap on the -> button to expand it beyond its original boundaries, you can then tap on the + button to create a custom flaschard based on the selected text.
原来如此!That works, thanks!

I'd been thinking the logic of the interface was: if in dictionary, the "+" will create a card with the dictionary entry, even when the selection is extended with the ">"; if not in dictionary, you have to tap-select (so that you get the copy menu) -- and that was the wrong interpretation. Still seems a fuzzy distinction between tap and tap-hold selection, in terms of what actions they perform -- if I'm not the only one thrown by this, it might be an area for some UI mods.
 

mikelove

皇帝
Staff member
numble said:
Yeah, I think icons make more sense, but those other 3 are tricky...

Well for Rad in the past we've used the character 部, but it seems that people get intimidated by Chinese character icons so we try to avoid them now... Full and Wild may not stay on the toolbar forever, though.

mikeo said:
I'd been thinking the logic of the interface was: if in dictionary, the "+" will create a card with the dictionary entry, even when the selection is extended with the ">"; if not in dictionary, you have to tap-select (so that you get the copy menu) -- and that was the wrong interpretation. Still seems a fuzzy distinction between tap and tap-hold selection, in terms of what actions they perform -- if I'm not the only one thrown by this, it might be an area for some UI mods.

Oh yes, we've been planning to merge those two ever since we started supporting tap-hold selection in 2.2.0 - should finally happen in the summer UI revamp.
 

numble

状元
Maybe something with a "building blocks" theme or something along those lines?

In other issues, I don't think the "fan" should ever be inaccessible on the iPad when keyboard or hwr mode. It's an extra step to get to it, especially if the user has open for input as a default. I also think that "fan" should always be accessible.
 

psucom

举人
Is it possible to automatically have the character play upon selecting it? Similarly, can pleco do text-to-speech over a large selection without having to select the audio button on each word? Thanks.
 
Top