Google Android

[Sparkletron]

Interesting to hear that nobody else has released a Chinese dictionary for Android yet, but given all of the talk of Chinese phone manufacturers embracing Android I can't imagine that'll last very long.

At the time you posted this we were finishing up (link deleted) (link restored:QuanWei), the first Chinese dictionary for Android. It may interest you and your readers to know that I agree with your sentiment and business savvy. QuanWei has not had a lot of downloads and from a business perspective will never justify the months we put into it. But we love Chinese and we love Android and we love developing mobile applications and doing something no one else has done before. So there's the motivation.

-S

 

[mikelove]

Sorry about the link deletions but I have to draw the line somewhere on that - I'm sure you wouldn't want me coming on to your site and plugging Pleco to your customers, and particularly as this is your first post here I have to be a little wary of that sort of thing - we get a couple of posts a month from brand-new users mentioning some great new Chinese learning website / textbook series / tutoring program / etc they've "found" and in those cases I usually delete them altogether.

I appreciate your thoughts on this, though. I do think the market for Chinese dictionaries is going to expand considerably as more Android phones become available, but it remains to be seen if Google can build up a third-party software store on the scale of Apple's. And kudos on the Pinyin disambiguation feature in (name deleted), we had a suggestion come in about that a few years ago but it's been sitting on our to-do list since then - I don't have an Android phone to test on but I'm sure it's a nice enhancement. Also interested to see a magnified-character feature, that's something we were pretty much alone in offering before now.

(we should talk, actually, since we're not particularly interested in porting Pleco to Java / Android perhaps there's a way we could work together here)

 

[Sparkletron]

Thanks for the kind words, Mike. I think it just goes to show that even with all the competing software out there, there's still room for innovation and differences in style and focus. We decided early on to focus on maximum readability--even at the expense of design elements that might further sales. We also focussed on Android-specific features since we couldn't compete as far as dictionaries go (Pleco, for example, has a killer dictionary that few packages can match; even my favorite desktop dictionary, which I suppose I'm also not allowed to mention--it starts with a "W" :wink:--doesn't have the width and breadth of Pleco's). But it's easy enough to turn weakness into strength by simply charging less (we have no licensing fees to pay). Doubtless the most popular dictionary will ultimately be the one that costs nothing, even if it offers fewer entries and features overall. And that's just fine; we'll continue to make the sort of dictionary that we would want to use, and welcome others to do the same.

-S

 

[mikelove]

Wenlin you can mention, actually, since they're longtime business partners of ours and we have a very friendly relationship - we direct people asking for a desktop version of Pleco towards their product and they direct people asking for a handheld version of Wenlin towards ours.

But yes, not paying license fees is a definite advantage - we're trying to move towards paying flat annual royalties for a few dictionaries in order to allow us to charge a bit less for them, but there's still no way we can compete with you guys or other CEDICT-based titles on price. And ultimately I imagine even much of the ABC's advantage will be eroded as people continue contributing to CEDICT. Other content that we currently have to license is also starting to crop up in open-source form; there are a couple of good stroke order diagram projects going now, for example. Open-source Chinese handwriting recognition may never happen, but as that gets built into more and more operating systems it becomes much less significant - if it's not already supported in Android I imagine it will be in another release or two (there's probably a team at Google working on it even now).

 

[character]

Open-source Chinese handwriting recognition may never happen[....]

Actually, it's been available for a while: http://kiang.org/jordan/software/hanzilookup/ And it's in your favorite language, too. :wink:

It's under the GPL, unfortunately, not a more business friendly-license like Apache/MIT. And for Android it would need a new UI.

 

[mikelove]

I should have added a "commercial-quality" before that (as the author himself notes on that page) - CEDICT is already at the level of some of the low-end printed Chinese dictionaries (albeit still a long way from the top-of-the-line ones like ABC), but there's a much bigger gap between open-source and commercial handwriting recognition. And a difficult gap to close, since it takes millions of dollars in R&D to come up with a recognizer like Hanwang's - producing a Chinese-to-English dictionary isn't cheap either but it's a lot less than that.

But yes, particularly on Android this could be very useful as there's no built-in system to fall back on like there is on iPhone.

 

[mikelove]

Sparkletron - not sure if you're still reading this, but I should have mentioned that the ABC dictionary actually isn't unique to Pleco - Wenlin uses the same thing (just a slightly older version and without characters in example sentences), and they license it to other companies, so if you're not completely set on being royalty-payment-free you might want to look into that.

 

[Sparkletron]

I'm a huge Wenlin/ABC fan. I even own the ABC hardcovers from the University of Hawaii Press. So we're aware of licensing opportunities. But the truth is that we consider our Android efforts to be more of an avocation than a business. Indeed, I'll be traveling to China this year (first time!) and will see if our product is truly as useful as I hope it is.

Beyond that there are technical issues with Android and large data stores. The general feeling at Google seems to be: this is a cell phone--not a computer; don't write huge apps. And they've made it challenging to do so. For example, applications acquired via the Android Market are stored using the G1's internal 256MB Flash. Short of hacking, there's no way to move these apps to external flash. As you can imagine, folks fill up their phones pretty quickly, and are then unable to download additional apps (despite having perhaps 16GB of space available via microSD). For large apps, the obvious solution is to store resources like dictionaries on the SD. But there are problems with that as well. In short, the G1 is somewhat crippled when it comes to third-party apps.

We're going to wait for the release of additional Android phones and see how the platform develops before we make any architectural decisions that may allow us to expand the dictionary. In the meantime, we still have a number of new features we're working on and don't feel as if CC-EDICT is constraining us. One thing that *is* constraining us is the Android Market itself. But that's another story...

 

[mikelove]

Interesting - I didn't realize that the lack of large data storage was such a big problem on Android, though given Google's corporate strategy is pretty much built around owning everyone's data I guess it's not surprising they'd be trying to discourage people from storing that data offline and out of their reach. I imagine there'll be Android phones with a lot more built-in memory out in short order, though. And the ABC's more compact than you might think, our version's 19 MB but with more aggressive compression and a more space-conserving index that could probably be reduced to 10 or 12.

Given all of the issues with Android Market, though, has there been any talk of opening up a third-party software store for Android? Since apps don't have to be signed by Google it seems like that would at least be theoretically possible, though getting that store app onto non-technical users' phones might be a bit of a challenge.

(I went back in and restored your links, BTW - starting to worry that I'm turning into something of a dictator here, and we're not even on the same platforms anyway)

 

[Sparkletron]

We've compressed our dictionary to 6MB or so and even that's too much. But I agree Android storage will increase with time (and on that belief I rip all my CDs at the highest possible quality; cheaper HDs will make file sizes negligeable, but who has the time to rerip all their music every time Moore's Law kicks in?!).

Third-party Android markets exist but I have issues with them as well. They all seem to work by requiring a "phone home" design pattern, meaning without network-based authentication the apps won't even launch. Even worse, if their authentication servers fail or if they go out of business then *our* customers are screwed. Finally, the morality of collecting usage stats seems pretty tenuous--it's just not what we're about. I love Wenlin but I wouldn't want them to know every time I launch the app...

And then there's the issue of THE VIG. Not exactly sure what their 30% cut buys us but whatever it is I'm seriously not impressed. We have our own servers, can host our own apps, can code our own authentication and distribution systems, can use PayPal or any of a number of vendors to facilitate monetary transactions--all of whom charge significantly less. The Android Market currently reaches three countries--not exactly a world market. And it's not even (officially) accessible from the Web!

Freeing ourselves from our Google overlords is a high priority for us--if only to reach folks who cannot acquire our software through normal means.

(I went back in and restored your links, BTW - starting to worry that I'm turning into something of a dictator here, and we're not even on the same platforms anyway)

Thanks, Mike. I completely understand your caution. Managing a forum is no easy task--particularly when you have a million other responsibilities. Sometimes you just have to make a judgment call.

 

[ipsi]

Completely off-topic: Are you ripping them to FLAC or to high-quality MP3s? You may be better off trying to convert them to FLAC (Free Lossless Audio Codec) files, and then it will be relatively trivial to batch-convert them to MP3 or OGG or AAC (or whatever) files at whatever quality you want.

Anyway, I find this discussion interesting, though I've not got a huge amount to add myself.

Do the third-party Android markets really require an App to phone home *each and every time* it tried to launch? That's pretty insane. I would have thought they'd learned from the huge number of other examples (Microsoft's Music Store comes to mind, forget what it was called) where the DRM server was turned off and customers were suddenly down large sums of money with *nothing* to show for it. It'd be even worse in this situation, as at least with music DRM there are plenty of ways to acquire any given song, but if an application developer has decided that they'll go only with the market that's just failed, well, what are you going to do? Pray there's an equivalent app somewhere?

As to their percentage, I'd say you're doing better than most if you can code your own authentication and distribution systems, as well as being able to afford to host them. I've been working with web service security for the past little while and it's driving me insane.

 

[mikelove]

Agree with you about the 30% cut, and honestly those systems aren't that expensive to develop / deploy if you're doing it on the scale of a few moderate-volume titles - for years we were hosted on a $10/month Dreamhost account, and still had excellent uptime and an online store that was fulling orders automatically within seconds of their being placed. (and nobody trying to push our customers into paying an extra $10 for "Extended Download Service")

The thing that makes me OK with paying 30% on iTunes at least, though, is that enabling people to buy something with a single button tap seems to have a pretty big psychological impact; there've been many many cases of companies making tiny tweaks to their shopping carts to remove a step or two and seeing sales skyrocket as a result. In Pleco's own history, when we switched (in early '04) from making people wait a day for us to check their orders / send out their registration codes manually to fulfilling orders instantly on our server we saw a very big bump in sales, one that couldn't really be explained by anything else (this was during the ill-fated Berlitz Phrase Books experiment, but the sales bump applied to our Chinese dictionaries too, in spite of the fact that they hadn't been significantly updated in a year and wouldn't be significantly updated until a year after that).

This is also one reason why I love the idea of In-App Purchase, since even now some of our add-ons - Tuttle for example - are small and cheap enough that they're exactly the sort of thing that someone might buy and enjoy if it were made easy, but would hesitate about with as complicated an ordering process as we have now (go onto Pleco.com, discover you have to log into My Orders to order add-ons, search vainly for your My Orders password, request a new password, wait for that e-mail to arrive, log in, find the link to order Tuttle, go through multi-stage checkout procedure, download keyfile, consult instruction manual for reminder of how one goes about installing these darned keyfile thingies, fight with HotSync Manager for half an hour and finally after all that get to enjoy your new dictionary). Depending on how well Microsoft's application store turns out we might even think about listing Pleco for Windows Mobile on there, in spite of the fact that we can sell software for Windows Mobile without it.

Mandatory phone-home is nuts, though; either you render your software unusable without a network connection by refusing to start up if you can't connect to the server (so good luck if you want to, say, practice Chinese on an airplane flight to China), or you allow it to start up if it can't connect and thus enable even the most obtuse of 11-year-old computer hackers to break it by putting his/her phone into "airplane mode" whenever they want to use it.

 

[Sparkletron]

I'd say you're doing better than most if you can code your own authentication and distribution systems, as well as being able to afford to host them. I've been working with web service security for the past little while and it's driving me insane.

I didn't mean to imply that rolling your own system is trivial; if it was we'd be done already. But a 30% vig is a good motivator to get the work done. I'm also no authority on Android e-commerce; I was merely describing my own observations after reading some of the technical reqs.

I expect that as mobile application development becomes mainstream and fewer phones are locked down, the 30% vig will not last. Competing vendors will drive the cost down to something more reasonable. I'm still amazed that 30% is considered a bargain from the past, where 40, 50 and even 70% was not unheard of. Mike, you would know more about this than I as you've been in the biz for some time.

The difference between iPhone and Android is that with iPhone there's no choice; short of jailbreaking, Apple's market is the only market in town. So naturally Apple can charge whatever they want.

 

[mikelove]

Yeah, PalmGear was I believe 25% for a very brief period after we started selling there but then quickly ramped up to 30, then 40, and then even more for branded stores like Palm's. And then they blew a couple of months' worth of developers' revenues defending themselves against a lawsuit from Handango (we only ever got paid back 20% of what they owed us from those months), at which point we stopped selling anywhere outside of our own store and never looked back.

With them, however, aside from the catalog listing they didn't really offer any benefits over processing orders yourself with PayPal / Yahoo Store / etc, while Apple and Google also offer streamlined installation and payment. I suppose Apple and Google could jack up their rates eventually too, but I think the fact that all of these new stores are tied to the makers of the phone OSes may help to prevent that - if Apple raises their rates to 40% then lots of people switch move development resources from iPhone to Android, if Google jumps to 40% them lots of people move development resources from Android to iPhone, if they both raise rates at the same time that's a lovely little antitrust lawsuit. PalmGear and Handango didn't have to worry about whether their actions would hurt Palm OS, but that's no longer the case with manufacturer-controlled stores.

But certainly I wouldn't want Pleco to be completely dependent on Apple to stay in business, which is why we're continuing to develop on Windows Mobile and planning / working on desktop and online products too.

 

[westmeadboy]

This would be nice - dual boot smartphone:

http://www.itechnews.net/2009/01/05/qig ... l-hands-on

 

[mikelove]

Well ARM are supposedly adding some virtualization instructions to their instruction set (like IVT on Intel - the reason why VMWare/Parallels can emulate Windows on a Mac at respectable speeds) so you wouldn't necessarily even need to dual-boot, you could just emulate. Presumably you'd want to base this on Android since then you'd get the flexibility of having everything open-source at the lower levels, but within a year or two the processor speeds will probably be about where they'd need to be to let you boot up an emulated version of Windows Mobile and run WM apps on a (modified-to-run-non-Java-apps) Android phone with satisfactory performance. (heck, a 2003-vintage iPAQ still runs Pleco nice and fast, so 2009 ARM chips may already be speedy enough for this)

 

[westmeadboy]

Oh hello, calling into native code:

http://android-developers.blogspot.com/ ... ase-1.html

 

[mikelove]

Yow... still haven't gone over all of the details, but from the basic description at least this looks like an absolute game-changer - I'd venture to guess that thanks to this Android will now become the next mobile platform we support after iPhone, though the desktop version (at least in "preview" form) will likely appear in between them since we've already kept people waiting a long long long long LONG time for that. Kudos to Google for finally getting their act together about native code.

 

[mikelove]

In fact, honestly, if this had been announced 8 months ago we might not even be doing an iPhone version of Pleco - in general I'd much rather support a platform that lets developers distribute apps without the manufacturer's approval, our biggest reason for doing iPhone was that it was a native-code mobile platform other than Symbian.

 

[ipsi]

Be aware that it's JNI - while it's nice to be able to run native code, JNI is not exactly the most amazing way to go about it. And you'd likely still need at least a small amount of java for the front-end (though I don't imagine it'll be much more than any other platform-specific code).

Still very nice to see though - really wish I'd won one of the HTC Magics Vodafone was giving away... When I finally get some money, I may have to look into getting an Android Device.