2.3 / User Interface Enhancements

[Entropy]

Re: 2.2 / User Interface Enhancements

Aside from the fact that it highlights the radical, what major advantages do you see in eStroke's system over ours?

One thing is that it puts the SOD on the front page, so to speak, so you can't forget to check that you know the right SO for what you're trying to write.

eStroke also lets me input simplified and see the traditional character immediately and its SO at the press of a button, which is a big help on iPad where you can't input the trad without buying the FS HWR module. This is kind of a guessing game--hmm, that might be it, let's choose it and see what it looks like in the other "alphabet".

Maybe, but I think there could also be reason to consider some more fundamental changes in the way we handle the interface for Pinyin searches; for example, we could really use our own customized Pinyin keyboard

Why do I think Pleco has an option for showing Pinyin tone buttons in the keyboard?

It already does save the current page, though we really need to break it up into more, smaller pages.

A split screen for viewing settings + the manual is interesting, but I think I'd rather just add an (i) button to each Settings option that popped up an explanation for what that particular option does.

I want it the open to the place I was reading when I switched to the settings, which is why it occurred to me to just have the settings in the manual itself. (Of course they can also live where they are now, this being a computer and all.) In fact, putting it that way makes it much more obvious that it's a good idea. Just include the settings right in the manual.

That is an embarrassing omission - not sure why it isn't in CC-CEDICT at least - but =aside from licensing more dictionaries there isn't much we can do on that - can't magically generate content that isn't already there.

Right, which is why I said whatever it was I said earlier in this thread. (I think I said I didn't look into using flashcards because I would have to write the cards myself, which I plan to do using McCawley... Someday.) The dictionary entries don't always exist.

I'd expect there to be a lot of these, like "shredded three kinds" and "Buddha jumps over the wall" and even things as mundane as 辣盐 which is known by Chinese to be a deep-fried dish, but badly translated on an astonishing number of menus, AND when translated as "salt and pepper" misunderstood by Americans as being white salt and black pepper, when it's really fresh small hot pepper and [seasoned] salt.

I'm in a lot of places - can probably order one from UofC press anyway.

Much like the settings could be in lots of places.

Flashcard Testing / Test type = Stroke Order. Handwriting quality test would be dicey because poor handwriting doesn't always correlate with inaccurate handwriting, and because the templates used by our handwriting recognizer were designed to deal with badly-written characters

Ah, in a module I haven't gotten yet. And I misspoke again--I want to be tested on the human legibility of my HW. As anyone who mastered Newton HWR knows, you can have absurdly illegible writing and still be recognized (I have some screenshots of how bad you can be on iProds.)

The design of the character database certainly might support replacing the individual strokes with prettier / more calligraphic ones following the same basic start / end / inflection points, though

That would be a big improvement.

I guess I'm just not as aesthetically offended by the stroke order diagrams as a lot of people seem to be

Clearly not.

Would you find even a font that used thick, homogenous-width lines in place of strokes preferable to the current one? (that would be really easy to implement)

I want the font to help me figure out stroke direction, which eStroke's is somewhat better at doing. I also find that seeing the calligraphic font makes it easy to recognize the non-calligraphic, but not the other way round. Also, I think I'd prefer a combination of coloring the parts and color-scale to show you the stroke order in each part. In fact, the colors of the parts could follow the rainbow. That could either communicate really well, or be horribly ugly, or both.

{quote="Entropy"]I turned on something that lets me add words to a list. A list I can't figure out how to access.[/quote]

Only readable if you've bought the document reader add-on, strangely enough

Amusing. Something to look forward to.

The $100 bundle is missing the NWP dictionary from the $50 bundle, so it would have to be a $60 upgrade or else everybody would buy the two $50 ones to save money.

<nod> The devil is not in the details. That would still be better than the $75 for the three dictionaries. It seems unfair to penalize people because they can't buy the biggest bundle up front. This reminds me of what my friend Vinson Bushnell (who ran the late lamented Glass Harmonica classical music store in Bloomington, IN) used to say when people asked if there was a volume purchase discount: "We don't like to give people discounts because they have more disposable income."

~ Kiran <entropy@io.com>

 

[radioman]

Re: 2.2 / User Interface Enhancements

Wont bother pulling out the quote, but maybe additional benefit might be derived by having a way of showing direction on a static picture for individual strokes. So as the character sits there on the screen (no drawing movements taking place), having the strokes fade from black to red or yellow on individually drawn strokes (different than the actual variation in opaqueness).

Not stroke order, just direction.

 

[mikelove]

Re: 2.2 / User Interface Enhancements

eStroke also lets me input simplified and see the traditional character immediately and its SO at the press of a button, which is a big help on iPad where you can't input the trad without buying the FS HWR module. This is kind of a guessing game--hmm, that might be it, let's choose it and see what it looks like in the other "alphabet".

How does that work for simplified characters that have more than one traditional mapping? Not a huge number, but we'd still have to deal with them, and that can be very tricky with a character that's out of context.

Why do I think Pleco has an option for showing Pinyin tone buttons in the keyboard?

We do, but we don't change the keyboard at all, we just stick a row of number buttons in a toolbar on top of it - a custom keyboard would do a whole lot more than that.

I want it the open to the place I was reading when I switched to the settings, which is why it occurred to me to just have the settings in the manual itself. (Of course they can also live where they are now, this being a computer and all.) In fact, putting it that way makes it much more obvious that it's a good idea. Just include the settings right in the manual.

The problem is that that's neither easy to implement nor a standard iPhone UI idea - people are a lot more accustomed to help buttons than they are to changing application settings inline on a web-based manual page.

Ah, in a module I haven't gotten yet. And I misspoke again--I want to be tested on the human legibility of my HW. As anyone who mastered Newton HWR knows, you can have absurdly illegible writing and still be recognized (I have some screenshots of how bad you can be on iProds.)

That one's really hard - we can check your stroke order / direction, but there's not a whole lot we can do about human readability.

Also, I think I'd prefer a combination of coloring the parts and color-scale to show you the stroke order in each part. In fact, the colors of the parts could follow the rainbow. That could either communicate really well, or be horribly ugly, or both.

I'm inclined to think the latter given what I've seen in other apps, but perhaps even if we didn't use a full rainbow we could pick a nice palette (e.g. something out of Adobe's free Kuler service) and distinguish color with that - might provoke some well-deserved indignation from color-blind users, though.

The devil is not in the details. That would still be better than the $75 for the three dictionaries. It seems unfair to penalize people because they can't buy the biggest bundle up front. This reminds me of what my friend Vinson Bushnell (who ran the late lamented Glass Harmonica classical music store in Bloomington, IN) used to say when people asked if there was a volume purchase discount: "We don't like to give people discounts because they have more disposable income."

Fair point, but I don't view it as an unfair penalty - on Palm/WM at least we get a LOT of tech support from installing upgrades, so we've tried to encourage buying everything on those at once since it reduces our support workload considerably. Not as big a problem on iPhone, though, so I suppose we could re-evaluate this policy on that.

Wont bother pulling out the quote, but maybe additional benefit might be derived by having a way of showing direction on a static picture for individual strokes. So as the character sits there on the screen (no drawing movements taking place), having the strokes fade from black to red or yellow on individually drawn strokes (different than the actual variation in opaqueness).

Good point, though I'd really like to find a way to indicate it more clearly than a gradient (say, a programmatically-generated arrow or number marker); people don't seem to notice many of our gradients as-is.

 

[Entropy]

Re: 2.2 / User Interface Enhancements

How does that work for simplified characters that have more than one traditional mapping? Not a huge number, but we'd still have to deal with them, and that can be very tricky with a character that's out of context.

Well, there are some things they call "semantic variants" but I'm not sure that's what you mean, because I'm not sure what *they* mean. But in the case of chicken, they just show you both traditional characters, and if you click one then they write it for you. Hmm, if you click one of those (do it now!) then the other one gets called a semantic variant, and a third semantic variant appears, which has the LHS from the simplified, and the RHS is the traditional bird radical.

(I've never actually *seen* that one, or the trad chicken with the trad bird radical. I've only seen the simplified one, and the one which Pleco shows as traditional, until you click on it and then the popup shows the third variant.)

Why do I think Pleco has an option for showing Pinyin tone buttons in the keyboard?

We do, but we don't change the keyboard at all, we just stick a row of number buttons in a toolbar on top of it - a custom keyboard would do a whole lot more than that.

So you DO have such a thing! I looked for it in vain while also trying to demo the OCR in vain.

The problem is that that's neither easy to implement nor a standard iPhone UI idea - people are a lot more accustomed to help buttons than they are to changing application settings inline on a web-based manual page.

New ideas are never standard UI. But this one would make sense for anything with complicated settings, and has a "why the heck didn't anyone think of that before?" flavor for me. In fact, Apple thought of it before, when they had active help in OS 8 or so, but they never went so far as to actually put the settings in the manual. I think even now the HTML-based help doesn't do as much as that old help system did--it could open the control panel for you and point to the settings, and probably even change them for you. On a small-screen device, this doesn't work, so you come up with something new that does.

And it's a *computer*. You can do *both*. And track the metrics to see how popular the new idea is.

That one's really hard - we can check your stroke order / direction, but there's not a whole lot we can do about human readability.

OCR on handwriting.

Also, I think I'd prefer a combination of coloring the parts and color-scale to show you the stroke order in each part. In fact, the colors of the parts could follow the rainbow. That could either communicate really well, or be horribly ugly, or both.

I'm inclined to think the latter given what I've seen in other apps, but perhaps even if we didn't use a full rainbow we could pick a nice palette and distinguish color with that - might provoke some well-deserved indignation from color-blind users, though.

They can switch back to greyscale and patterns, or something. I'm thinking of iPad now. But the idea of colored (or patterned) parts and colorscales for each part does appeal to me. Or, keep the greyscale, add a second copy of the character with colored parts, then click the parts to get an expanded shaded diagram, as well as a list. On iPad, you have plenty of space to play with.

"We don't like to give people discounts because they have more disposable income."

Fair point, but I don't view it as an unfair penalty - on Palm/WM at least we get a LOT of tech support from installing upgrades, so we've tried to encourage buying everything on those at once since it reduces our support workload considerably. Not as big a problem on iPhone, though, so I suppose we could re-evaluate this policy on that.

Well, this would encourage people to buy in two chunks rather than piecewise, which IIUYC would mean fewer support requests.

And it certainly seems like an unfair penalty to me to say "If you can't afford to just pay us $100 up front, you'll have to pay *even more* later."

Good point, though I'd really like to find a way to indicate it more clearly than a gradient (say, a programmatically-generated arrow or number marker); people don't seem to notice many of our gradients as-is.

It's a computer, you can do both. I'm used to seeing number and arrows, but after turning on the gradient I really like it, at least when there aren't too many indistinguishable black strokes connected together. Note that I had to first find it and turn it on in order to like it, which once again serves to emphasize the value of a well-chosen set of defaults. And I still want some way to easily distinguish parts.

It might also be the case that the defaults should change based on what you plan to do. Reading documents is probably quite different from translating menus, for example.

~ Kiran <entropy@io.com>

 

[mikelove]

Re: 2.2 / User Interface Enhancements

Well, there are some things they call "semantic variants" but I'm not sure that's what you mean, because I'm not sure what *they* mean. But in the case of chicken, they just show you both traditional characters, and if you click one then they write it for you. Hmm, if you click one of those (do it now!) then the other one gets called a semantic variant, and a third semantic variant appears, which has the LHS from the simplified, and the RHS is the traditional bird radical.

There are a few dozen very common ones, cases where they consolidated multiple older characters in the process of simplifying them - 干 for example can be 乾 or 幹 or just stay 干 in traditional depending on meaning, 面 can stay 面 or become 麵... you can translate most multi-character words using word lists / dictionaries, but with a single character there's not really any good way to know which traditional character is correct, so we'd need an interface that lists all of them.

So you DO have such a thing! I looked for it in vain while also trying to demo the OCR in vain.

Yes, buried in the last group of options in Settings / Panels at the moment, though it's on by default on iPad.

New ideas are never standard UI. But this one would make sense for anything with complicated settings, and has a "why the heck didn't anyone think of that before?" flavor for me. In fact, Apple thought of it before, when they had active help in OS 8 or so, but they never went so far as to actually put the settings in the manual. I think even now the HTML-based help doesn't do as much as that old help system did--it could open the control panel for you and point to the settings, and probably even change them for you. On a small-screen device, this doesn't work, so you come up with something new that does.

I guess I'm just not seeing the advantage over inline help, then - HTML takes longer to load and if you want it to be readable on iPhone you need to keep it simpler anyway. Even if we didn't add an (i), couldn't we just add a toggle button to the Settings screens that would show an explanation below every item?

And it's a *computer*. You can do *both*. And track the metrics to see how popular the new idea is.

Yes, because we've got a vast army of idle programmers sitting in a basement somewhere just waiting for us to give them something to do...

They can switch back to greyscale and patterns, or something. I'm thinking of iPad now. But the idea of colored (or patterned) parts and colorscales for each part does appeal to me. Or, keep the greyscale, add a second copy of the character with colored parts, then click the parts to get an expanded shaded diagram, as well as a list. On iPad, you have plenty of space to play with.

I suppose the easiest thing would just be to add two more settings options for now, one for stroke gradients and one for coloring different strokes instead of simply lightening them.

Well, this would encourage people to buy in two chunks rather than piecewise, which IIUYC would mean fewer support requests.

And it certainly seems like an unfair penalty to me to say "If you can't afford to just pay us $100 up front, you'll have to pay *even more* later."

Well that's true, and we actually have had a semi-official policy of offering upgrades on Palm/WM for the difference in cost if requested within a few months after the original purchase.

But the big problem is that on iPhone we can only create a small number of static catalog items with specific prices / contents; creating an item for someone with every conceivable combination of upgrades isn't really possible. So we could create, for example, a Basic-to-Professional and a Professional-to-Complete add-on for $60 and $50 each, but then what do we do for someone who bought Basic and also paid $30 to add on the ABC C-E dictionary? Seems unfair that they should have to pay more than $30 for the 21st Century + ABC E-C dictionaries that they're still missing when someone who bought Basic and nothing else can get all three for $60. And what about someone who just bought the HWR add-on, or bought that plus audio? And even that Basic-to-Professional-to-Complete path is costing you an extra $10 - I suppose at the very least we'd need a Basic-to-Complete for an even $100.

But my point is, once we make it our policy to let you upgrade for the difference in price, it gets harder and harder to justify not extending that policy to every iPhone user regardless of which upgrades they've purchased. The only way we could really make this "fair" would be to lower module prices / raise bundle prices to the point where bundles would cost exactly the same amount as separately purchasing the items they contained, at which point the bundles become nothing but conveniences.

 

[Entropy]

Re: 2.2 / User Interface Enhancements

you can translate most multi-character words using word lists / dictionaries, but with a single character there's not really any good way to know which traditional character is correct, so we'd need an interface that lists all of them.

Ahah. Based on your examples, that's what eStroke does, though it gets a bit quirky when they show a trad, and then when you choose that they show you two semantic variants and a Z-variant, whatever that is.

I guess I'm just not seeing the advantage over inline help, then - HTML takes longer to load and if you want it to be readable on iPhone you need to keep it simpler anyway. Even if we didn't add an (i), couldn't we just add a toggle button to the Settings screens that would show an explanation below every item?

Yes, that would work. But I'd want to just expand them all, and I think they need to be fairly detailed, this is a pretty complicated set of interface choices, after all.

Yes, because we've got a vast army of idle programmers sitting in a basement somewhere just waiting for us to give them something to do...

Wait, you don't write the whole thing yourself? :shock:

I suppose the easiest thing would just be to add two more settings options for now, one for stroke gradients and one for coloring different strokes instead of simply lightening them.

Hmm, how about colored outlines and grey interiors? (Here I'm thinking of the thicker stroke that eStroke uses, which can certainly be outlined.) Screenshot mockups are someone's friend here (but I can't do them because I can't draw even on computers.)

But the big problem is that on iPhone we can only create a small number of static catalog items with specific prices / contents; creating an item for someone with every conceivable combination of upgrades isn't really possible. So we could create, for example, a Basic-to-Professional and a Professional-to-Complete add-on for $60 and $50 each, but then what do we do for someone who bought Basic and also paid $30 to add on the ABC C-E dictionary?

I think that you're making it much more complicated than it needs to be--a bundle upgrade price would probably be satisfactory for most users. But perhaps you should only have two bundles, basic and complete-forever, and price the second one at only a modest discount from the non-bundle prices, with the main perk being getting free upgrades later.

The only way we could really make this "fair" would be to lower module prices / raise bundle prices to the point where bundles would cost exactly the same amount as separately purchasing the items they contained, at which point the bundles become nothing but conveniences.

Well, it sounded like the reason you have them in the first place was to reduce support costs. Do dictionary add-ons generate as many support requests as the other stuff? If they don't, then it seems to me that only one bundle would be necessary, containing all the basic non-dictionary modules. Then you're giving people a break in exchange for them giving you a break, and you're giving them incentive to buy tools that will be useful to them *now* (where additional dictionaries might only be valuable in the future, which is why IMO they should all be a la carte) even though they don't realize how useful those features would be until they have them.

~ Kiran

 

[mikelove]

Re: 2.2 / User Interface Enhancements

Yes, that would work. But I'd want to just expand them all, and I think they need to be fairly detailed, this is a pretty complicated set of interface choices, after all.

Makes sense - in general we need more screens with fewer options per screen.

Wait, you don't write the whole thing yourself?

Not entirely, no.

Hmm, how about colored outlines and grey interiors? (Here I'm thinking of the thicker stroke that eStroke uses, which can certainly be outlined.) Screenshot mockups are someone's friend here (but I can't do them because I can't draw even on computers.)

I'm not liking the picture of that in my head at least... couldn't we just apply a gradient to each stroke's color?

I think that you're making it much more complicated than it needs to be--a bundle upgrade price would probably be satisfactory for most users. But perhaps you should only have two bundles, basic and complete-forever, and price the second one at only a modest discount from the non-bundle prices, with the main perk being getting free upgrades later.

Complete-forever isn't possible; we don't want to be handicapped in future licensing deals by the fact that we're going to need to pay new per-copy royalties for thousands of people who'd be entitled to a free copy of whatever-it-is. Eliminating Professional might streamline things, but I think a better bet would be to remove C&T and possibly Guifan from Complete, have only Basic and a bundle with all of our general-purpose dictionaries and then offer special / topical dictionaries (Classical and hopefully Cantonese coming soon, and perhaps some others as well) only as add-ons. Or go more full-on into difficulty level grading and offer an "Advanced" bundle with ABC C-E / 21C / Guifan, though when we did that with our old "Linguist" bundle it barely sold any copies at all.

Well, it sounded like the reason you have them in the first place was to reduce support costs. Do dictionary add-ons generate as many support requests as the other stuff? If they don't, then it seems to me that only one bundle would be necessary, containing all the basic non-dictionary modules. Then you're giving people a break in exchange for them giving you a break, and you're giving them incentive to buy tools that will be useful to them *now* (where additional dictionaries might only be valuable in the future, which is why IMO they should all be a la carte) even though they don't realize how useful those features would be until they have them.

Support costs are one reason - another is simply that bundles are a way to make things cheaper for users who want a lot of add-ons; if we lowered the price of add-ons so that the combinations would work out to about what we're charging for them in bundles, with many of them we'd make so little money after royalties that it wouldn't even be worth bothering to sell them. Basically, bundles net us a much lower profit margin than individual add-ons but make up for it by being much more expensive.

There's nothing about offering bundle-to-bundle upgrades for the difference in price that undermines that - the same basic rule applies - but I'm still not sure if that would be a full solution to the problem. We've actually gotten a lot more emails from people who bought one or two modules and would like "credit" for that than we have from people who bought Basic and want to upgrade to Professional or Complete, so I don't think that aspect of this can be easily dismissed. And with those new dictionary licenses coming soon, and the possibility of OCR becoming useful enough on non-camera-equipped devices that we can start building it into bundles too, there's likely to be a big shuffling in our bundles anyway, so I'm not eager to roll out a new, overhauled pricing strategy now only to have to roll out another one a few months later.

 

[Entropy]

Re: 2.2 / User Interface Enhancements

Hmm, how about colored outlines and grey interiors? (Here I'm thinking of the thicker stroke that eStroke uses, which can certainly be outlined.)

I'm not liking the picture of that in my head at least... couldn't we just apply a gradient to each stroke's color?

Well, that was my original idea. But now I'm wondering if the gradient should show the stroke direction. Gradients communicate very clearly. But, where do you use them if you can only use them once?

I think that you're making it much more complicated than it needs to be--a bundle upgrade price would probably be satisfactory for most users. But perhaps you should only have two bundles, basic and complete-forever, and price the second one at only a modest discount from the non-bundle prices, with the main perk being getting free upgrades later.

Eliminating Professional might streamline things, but I think a better bet would be to remove C&T and possibly Guifan from Complete, have only Basic and a bundle with all of our general-purpose dictionaries

That would work, if you had an upgrade price from one to the next. :-D

Or go more full-on into difficulty level grading and offer an "Advanced" bundle with ABC C-E / 21C / Guifan

I think that would end up overcomplicated. Two bundles sounds about right to me.

there's likely to be a big shuffling in our bundles anyway, so I'm not eager to roll out a new, overhauled pricing strategy now only to have to roll out another one a few months later.

<nod>

 

[mikelove]

Re: 2.2 / User Interface Enhancements

Well, that was my original idea. But now I'm wondering if the gradient should show the stroke direction. Gradients communicate very clearly. But, where do you use them if you can only use them once?

As long as we can come up with a color progression in which the order is immediately obvious, using gradients for direction would make more sense - much easier to see the difference between 5/20 and 6/20 on a color spectrum than on a gradient, I think.

I think that would end up overcomplicated. Two bundles sounds about right to me.

Or possibly a third with all of the special-purpose dictionaries too - some people really do want everything regardless of whether or not we think they're likely to use a dictionary of, say, metallurgical terms.

 

[Entropy]

Re: 2.2 / User Interface Enhancements

Well, that was my original idea. But now I'm wondering if the gradient should show the stroke direction. Gradients communicate very clearly. But, where do you use them if you can only use them once?

As long as we can come up with a color progression in which the order is immediately obvious, using gradients for direction would make more sense - much easier to see the difference between 5/20 and 6/20 on a color spectrum than on a gradient, I think.

So, color progression for stroke order, and gradient (light to dark?) for stroke direction?

How will you distinguish between the component parts in this scheme? (How many parts does the most complicated character have?) I'm more inclined to let stroke shape show stroke direction, but I'd need to see some mockups to really get this in my head.

~ Kiran <entropy@io.com>

 

[gato]

Re: 2.2 / User Interface Enhancements

Makes sense - in general we need more screens with fewer options per screen.

How about better defaults, fewer settings (with the possible exception of settings hidden away in an advanced user panel)?

I think a top UI priority probably still is to make the flashcard module more user-friendly. I think a lot of paying customers are probably not using the flashcards because they are intimidated by the interface. They could become even more enthusiastic evangelizers for Pleco if you could convert them into Pleco flashcard users.

 

[mikelove]

Re: 2.2 / User Interface Enhancements

How will you distinguish between the component parts in this scheme? (How many parts does the most complicated character have?) I'm more inclined to let stroke shape show stroke direction, but I'd need to see some mockups to really get this in my head.

Maybe boxes - I like the idea of boxing off each part of the character with a little explanatory text of the component's meaning appearing somewhere in / next to the box. Helps to emphasize the fundamental structure of the character (two components side-by-side versus three of them versus one enclosing another and so on).

How about better defaults, fewer settings (with the possible exception of settings hidden away in an advanced user panel)?

Any particular defaults you don't like? Removing settings is dicey because most of them are there for a reason, though we can certainly move a lot to "Advanced."

I think a top UI priority probably still is to make the flashcard module more user-friendly. I think a lot of paying customers are probably not using the flashcards because they are intimidated by the interface. They could become even more enthusiastic evangelizers for Pleco if you could convert them into Pleco flashcard users.

Oh yes, 2.3 is / should be all about flashcards; part of the reason we've dragged our feet about a free demo flashcard system is that we'd first like to make it easy enough to get into flashcards that people might actually be persuaded to do so by the demo

 

[gato]

Re: 2.2 / User Interface Enhancements

Any particular defaults you don't like? Removing settings is dicey because most of them are there for a reason, though we can certainly move a lot to "Advanced."

I was saying it more as a general principle than anything specific at this point. Luckily I haven't had to fiddle with the settings much since I posted those those earlier in this thread. Hehe. I am been mostly reading a book with the reader. On the few occasions with the the flashcards, I did notice that there were an almost overwhelming numbers of setting choices. There must be a way to give the beginner user a choice between three or four test type, without having to think about any of the other settings.

Having used Instapaper a lot lately, I think it would be great way to get files on to the reader, if you could implement that. Shouldn't require too much bandwidth on your own server if it's just text, right? Saving a file directly from the "live browser' in the reader doesn't seem to work properly right now. If I have an online book I wanted to read with the reader, I still have to copy the text onto a text file on the desktop and then upload it to Pleco.

 

[Entropy]

Re: 2.2 / User Interface Enhancements

The lack of a notepad is truly annoying.

I found another keyboard bug (on iPad) auto-rotation brings up the Apple keyboard over the FSHW one.

And, I want to see a list of characters that *contain* another character (the reverse of the parts breakdown) so I can translate fuzzy menu boards on which I can only read a component part.

It might also be nice to be able to specify where that part goes, but I assume that's a nontrivial programming project, since you'd have to be able to specify a quadrant or something. On the iPad, though, it seems like you have plenty of space for that--when I'm writing, I'd like to be able to confirm the recognition of a particular part, thus limiting the selection of future characters. For example, in xian, I *know* that's a fish radical, and want to limit the future list of characters to only those which have a fish radical on the LHS.

~ Kiran <entropy@io.com>

 

[mikelove]

Re: 2.2 / User Interface Enhancements

Having used Instapaper a lot lately, I think it would be great way to get files on to the reader, if you could implement that. Shouldn't require too much bandwidth on your own server if it's just text, right? Saving a file directly from the "live browser' in the reader doesn't seem to work properly right now. If I have an online book I wanted to read with the reader, I still have to copy the text onto a text file on the desktop and then upload it to Pleco.

It's actually quite a lot of work to set up a sync service like that - I'd more inclined to just improve our facility for saving web pages in the browser, at least for now, though it might sense to include document sync along with flashcard sync once we add flashcard sync support.

The lack of a notepad is truly annoying.

You can get one with the experimental text editor function in the document reader - Settings / Reader / Enable text editing.

I found another keyboard bug (on iPad) auto-rotation brings up the Apple keyboard over the FSHW one.

Known bug, thanks - fixed in 2.2.

And, I want to see a list of characters that *contain* another character (the reverse of the parts breakdown) so I can translate fuzzy menu boards on which I can only read a component part.

You can already get that, actually, tap on "Containing" at the bottom of the Character Info "Chars" tab.

It might also be nice to be able to specify where that part goes, but I assume that's a nontrivial programming project, since you'd have to be able to specify a quadrant or something. On the iPad, though, it seems like you have plenty of space for that--when I'm writing, I'd like to be able to confirm the recognition of a particular part, thus limiting the selection of future characters. For example, in xian, I *know* that's a fish radical, and want to limit the future list of characters to only those which have a fish radical on the LHS.

That's quite doable - a multi-component / multi-radical search in general is something we really need to work on adding, been wanting to do it for years but like a few other features (annotations, e.g.) it keeps getting pushed farther and farther back.

 

[jacky89]

Re: 2.2 / User Interface Enhancements

When is the expected release date for 2.2? I'm holding off on purchasing this software until the OCR feature is included or unless there's free upgrade. Thanks.

 

[Entropy]

Re: 2.2 / User Interface Enhancements

Following up on my earlier ideas about adding a miniature SOD to the main screen. eStroke has added support for drawing smaller characters--up to an 8x8 grid. Experimenting with this, i think that drawing a character in a space less than 1" square is sub-optimal. But if you don't *have* more space, you learn to live with sub-optimal. :-/

 

[mikelove]

Re: 2.2 / User Interface Enhancements

When is the expected release date for 2.2? I'm holding off on purchasing this software until the OCR feature is included or unless there's free upgrade. Thanks.

Within a few weeks, but we're not planning to add OCR to any of our existing bundles - the vast majority of iOS devices can't run OCR, unfortunately, and even in Apple's current product line only the iPhone 3GS/4 can (iPad lacks a camera, iPod Touch's camera isn't good enough), so it doesn't seem to fair to raise prices for everyone to pay for OCR when most people can't take advantage of it.

So OCR should either be a standalone add-on only, or be a standalone add-on plus part of a "Complete + OCR" bundle that costs exactly the same as the separate non-OCR Complete bundle + OCR add-on.

Following up on my earlier ideas about adding a miniature SOD to the main screen. eStroke has added support for drawing smaller characters--up to an 8x8 grid. Experimenting with this, i think that drawing a character in a space less than 1" square is sub-optimal. But if you don't *have* more space, you learn to live with sub-optimal. :-/

Maybe, but I still think we're better off just adding some nice friendly <- / -> buttons to Char Info to cover this on iPhone; view one character at a time but very easily switch between them.

 

[Entropy]

Re: 2.2 / User Interface Enhancements

Following up on my earlier ideas about adding a miniature SOD to the main screen. eStroke has added support for drawing smaller characters--up to an 8x8 grid. Experimenting with this, i think that drawing a character in a space less than 1" square is sub-optimal. But if you don't *have* more space, you learn to live with sub-optimal. :-/

Maybe, but I still think we're better off just adding some nice friendly <- / -> buttons to Char Info to cover this on iPhone; view one character at a time but very easily switch between them.

Or a scrolling area that you just flick right and left to move.

 

[mikelove]

Re: 2.2 / User Interface Enhancements

Or a scrolling area that you just flick right and left to move.

Right, which would save a lot of room in the toolbars.