Pleco Desktop

JD

状元
@Bvo
Each of has our own set of experiences and life-learnings that we use to construct and support our conclusions. As a 20+ year veteran of IT, Project team management, application and software development I have my opinions that differ from yours.

Feel free to pursue your visions the way you see fit.

EDIT: Upon re-reading my above comment I realized it may sound condescending. That was not my intent. A better phrasing would be that I respect your right to have a different opinion than mine and that you should allow your own beliefs and dreams to drive you, not other’s.
 
Last edited:

Bvo

探花
@JD,
BTW, I'm 20+ IT-veteran too :))
As I'm pretty "not young" I do appreciate any thoughts, so I didn't consider any comment as "condescending".
I'm just expressing my opinion.
At an university I liked ASM/C++, later I loved Delphi, then .NET for Windows app development, currently I love Web applications (though I'm still developing for Windows and use latest .NET technologies).
By nature I'm very conservative (as most non-millennium people (especially developers) are), but IT world moves more and more faster, so we have to throw out our sweet habits if we don't want to become some kind of "experienced Cobol-developers" :))
 

mikelove

皇帝
Staff member
We already have shared cross-platform code, actually; I'm a crusty old C programmer and all of the interesting bits of Pleco are written in clean, fast, elegant C. Objective-C interoperates with it seamlessly and we've got a well-refined set of SWIG wrappers for Java to do so as well. It's even object-oriented - we're using a class generator script now, the four dozen or so different tables that make up the 4.0 flashcard system each have their own little object class, and since this is all happening in C we can do all sorts of crazy performance optimizations (customizing SQLite to use fewer mutexes in a way that made it roughly 50% faster); can process 100,000 flashcards' scores and other records and come up with a list of what's currently due to study in about 50ms on a not-very-fast iPhone.

Web-based apps are great for large teams but I can't fathom ever wanting to move the Pleco core to one - too little to gain and too much to lose.
 

Bvo

探花
@mikelove ,
50ms for 100K records processing on iPhone is a really amazing result.
And I thought I never meet a clean-C developer again :)))
Sure, Pleco works VERY fast, no doubts.
But as a note - "shared cross-platform code" here means just 2 platforms, even not including Windows or Linux or MacOS.

So do you think Web Pleco (fully functional dicts+flashcards) has no future and Android+iOS will be enough for a lifetime?
 
Last edited:

rizen suha

状元
to me the speed of pleco is absolutely key to its user friendliness and providing its functionality. lags of even fractions of a second, over time and use sums up to cognitive dissonnance and rejection. as it is today, pleco gives you a feeling of “yes, master, on your command”. speed _is_ functionality.
 

pdwalker

状元
Mike,

We have a lot of active users but not a lot of recurring revenue; I am firmly opposed to the idea of making our main product subscription-based, but getting even just a few % of our users to sign up for an add-on subscription of some sort would do a lot for our bottom line.

Solving this problem is what would really allow you to grow your development/editorial team, or at least keep the existing one running. I'd be inclined to think this would be a more useful direction for you to go rather than developing a desktop version that would certainly see less use than the mobile clients.

and Web based? Nah. 10 years ago, certainly. Now? No. The mobile clients have proven themselves to be much more convenient and accessible for people "on the go". Until the landscape changes (again), mobile is where it is at.
 

mikelove

皇帝
Staff member
@Bvo - I don't think Android + iOS will be enough for a lifetime, but I do expect that whatever replaces them will still support C/C++; too many important cross-platform libraries written in those languages, and a great many cross-platform Android + iOS apps with complicated algorithmic cores (image processing, e.g.) are written in them. And if it supports C then it should be pretty easy to write a script to automatically wrap up our APIs in whatever language higher-level stuff is written in, as we do now with JNI. If we wanted to support Windows or Linux, it would be considerably less work to build a Windows UI around our cross-platform C core than it would be to port that core to something web-based, and the results would be much more satisfying. (supporting Mac would be just a matter of retooling the iOS app a bit, as would supporting watchOS / tvOS / the new in-development VR headset OS / etc - Cocoa Everywhere is succeeding in ways that Windows Everywhere only ever dreamed of)

@rizen suha - thanks!

@pdwalker - Yeah, it's part of a long-running effort to find a way for Pleco to replace the functions of the traditional publishers we're helping to destroy, which in the case of reference titles like dictionaries means not just marketing and distribution but also putting in quite a bit of money / editorial time. We've released three big titles this year (Outlier, ABC Cantonese and Military Mandarin) without a traditional publisher involved, and one more actually coming next week (though it's not strictly speaking a dictionary), but we weren't involved in funding any of them; we'd like to get to a point where we can go through our New Dictionary Ideas thread (and other such lists) and develop a couple of those titles per year :)
 

Shun

状元
Yeah, it's part of a long-running effort to find a way for Pleco to replace the functions of the traditional publishers we're helping to destroy, which in the case of reference titles like dictionaries means not just marketing and distribution but also putting in quite a bit of money / editorial time. We've released three big titles this year (Outlier, ABC Cantonese and Military Mandarin) without a traditional publisher involved, and one more actually coming next week (though it's not strictly speaking a dictionary), but we weren't involved in funding any of them; we'd like to get to a point where we can go through our New Dictionary Ideas thread (and other such lists) and develop a couple of those titles per year :)

We live in interesting times, it won’t be long before there’s no kind of business that can’t be done over the internet, and the need for intermediaries is diminishing everywhere. But one thing did occur to me when reading this, will you be able to ensure the same quality for edited titles as traditional publishing houses? While traditional publishing houses may have experts in all kinds of areas working for them, Pleco may have to rely on a more loose network of experts. Or does it not matter much in your view? Thanks!
 

mikelove

皇帝
Staff member
One of my to-do list items for the next year or two is to hire a “managing editor” - I expect we can pay competitively to what a traditional publisher would (editors are a lot cheaper than programmers), so assuming we can come up with enough work for an editorial staff to do and make enough money from that work to pay them, I don’t think it should be too difficult to get a comparable level of talent.
 

Shun

状元
One of my to-do list items for the next year or two is to hire a “managing editor” - I expect we can pay competitively to what a traditional publisher would (editors are a lot cheaper than programmers), so assuming we can come up with enough work for an editorial staff to do and make enough money from that work to pay them, I don’t think it should be too difficult to get a comparable level of talent.

Makes sense! If the managing editor could come up with something completely new, like a proper Chinese-English food dictionary that includes pictures, that could be a real hit. (It could first be introduced wih 1000 basic foods to generate revenue and test the market, then be extended over time.) People might learn about Pleco just because of that, and I guess the traditional publishing houses aren’t nimble enough to make that kind of a dictionary.
 

Bvo

探花
@mikelove ,
Ok, I will not argue - you have your own vision.
Just want to notice that modern web-architecture consists not only of end-user interface, but of other good things, like web-services that could be published outside and be used by any person/organization in their own apps/services.
Though I don't know if it's applicable to your business and what parts of Pleco could be really useful outside of Pleco UI...

PS: but, as you want to be a "publisher" it makes sense to provide your own content not only inside Pleco app - educational organizations could be interested in using some content in their own applications.
But actually I don't know this market so cannot give a really useful advice...
 
Last edited:

Shun

状元
PS: but, as you want to be a "publisher" it makes sense to provide your own content not only inside Pleco app.

When a large part of the population has a smartphone/tablet running Android or iOS, and the basic Pleco app is free, that shouldn’t be a problem. You can still publish it as a printed book on the side. :)
 

Shun

状元
If Pleco want to give everything free of charge - there is really no problems :)

Well, whatever dictionary you buy still costs something, like a printed dictionary, just less than a printed dictionary. :)
 
Last edited:

Bvo

探花
PS: content sales is different kind of business - it's like you created a movie or a show and sell it to many TV-providers and cinema halls.
You can show it on your own TV channel only, but it's different kind of business.
 
We have a lot of active users but not a lot of recurring revenue; I am firmly opposed to the idea of making our main product subscription-based, but getting even just a few % of our users to sign up for an add-on subscription of some sort would do a lot for our bottom line.

How about a sort-of a "season pass" kind of deal? This kind of model is seen frequently in the gaming industry. This would be attractive, especially if you know what is lined-up. Something like:

>Pay $x and get all '18 releases when they come out. [including at least # dictionaries, # e-books and # features]

Season passes can usually be purchased in advance or even well after the fact as well. So when someone seems Military Mandarin Lexicon for ten bucks and thinks "na, I'll pass" - but instead sees it in a "season pass"-type bundle with some discounts and says, "alright, why not?" - could be win-win.
 

mikelove

皇帝
Staff member
Maybe, but I'd worry that people would be upset if we didn't release anything in a particular season - our release schedule is not regular enough that people would have a clear idea of what they'd be getting for their money.
 

pdwalker

状元
An opinion only, but I hate hate hate “renting” software, (F@₵K you adobe!) but I have few, if any, issues paying for an inexpensive subscription. service. (A rant about why would be off topic)

Case in point, I was about to subscribe to the TCB service because it looks like just the kind of reading practice I wanted to have.

(Of course, the recent ebook releases got some of that money instead)

I didn’t feel that way two years ago, but mobile devices and mobile connectivity has improved so much that it makes it an easy spending consideration.

The “season passes” idea would absolutely require delivering new features, functionality and offerings on a periodic basis. Too often in the past, I’ve seen companies lose business and customers because they didn’t deliver.

Mike, a thought here. One problem with iOS apps and the App Store is that there is no allowance for upgrade pricing. As a result, developers have to abandon an older app for a newer one to get new income on that app line.

Could that be a consideration? Release a new version of pleco and allow someone to register all their old purchases in the new app for a modest upgrade fee.

I know you’ve not done that in the past and that you’ve always supported old licenses brought forward, but is it worth considering?

I know that I’m happy enough with pleco that I’d be happy paying an upgrade price for the new version if it helped you keep the lights on and the code compiling.

Just a thought.
 
Top