Quote:
Originally Posted by n7of9
-paid apps often have greater success when they also have a free counterpart...if you can figure out a way to disable some functionality for a free version and get people using the app, you may find that more will upgrade to the full version...it would also bode well if your app shows 50,000+ free installs as opposed to only 150 paid installs
|
We have looked hard at this, over and over. We always end up with the same three thoughts.
1) There aren't very many places where functionality can be limited and still be useful. That leads to the problem that if the base (free) functionality isn't reasonably complete, we will get zillions of 1-star reviews complaining about it. These reviews will do much more harm than not having a limited-function free version.
2) Having a free version that *does* have enough functionality to avoid the negative reviews will turn the paid version into donate-ware. That is not a place we want to be. My son, who is developing the android half of this system, makes his living doing android programming. At this point he can't afford to give away his time.
3) This isn't an app that someone will drive by, see, and try. A person who tries it has a specific problem for which this app is a solution, and there is a good chance that the user will know in advance from the description whether it solves the problem. Furthermore, the app is easy to test within the refund period, which provides a 'sort-of' try before you buy.
Quote:
-metadata - when syncing calibre to a proper ereader (like a Sony) any changes made in calibre after the book was added would also be updated and synced...currently, with no syncing capability for MTP devices, books with changes need to be converted over themselves (i.e. epub to epub) so any metadata changes are saved and visible on the android device...is this something your app may be able to address?
|
This is reader app integration. Calibre directly modifies the book database on Sony readers, some Kobo readers, and indirectly the database in iTunes. Our app would need to understand how to do the same thing: directly update the reader app's database or whatever it has that is equivalent, or using any automation interface the reader app might have.
Aldiko has a database that is reasonably simple, which is why it was mentioned as a possibility. We don't know yet what other possibilities we might have. I have spent a little time looking at FBReader's files and haven't yet found anything that would allow us to update a book's metadata apart from updating the book.
Dwanthy's point about modify-epub is a good one. In addition, calibre automatically updates metadata to the extent that it can when a book is sent to the device. For epubs, normally calibre can do a lot, especially when combined with plugboards. Unfortunately neither of these choices permit updating metadata without resending the book, but we can't do anything about that unless we can modify the information that reader app keeps.
Edit: our app will get updated metadata from calibre, which will be used by the app whenever it displays anything. To the extent that our app can serve as a 'director' for a user in place of a reader app, then the user will get many of the benefits of updated metadata. For this to work well, our app would need a good search interface, something that probably won't be in the first release. We would need a "collections" capability, which we haven't yet considered doing. I don't think our app will ever support eye candy like 'wooden bookshelves', and that might be a showstopper for some people. Finally, we will never be able to tie into a book purchase ecosystem such as Amazon's or B&N's.