MobileRead Forums - View Single Post

chaley · 08-22-2014, 05:22 PM

This is a good time to summarize what I think I am hearing.

The options:

Connect to the library in the cloud via its local app. This means that the calibre db must be downloaded to the device, as well as all the covers. The implication is that CC must be able to browse the DB in some way. Two obvious choices: 1) present the information as if it was a content server, or 2) present the information as if it were a CC library. Both require CC to have a deep understanding of calibre's database.

The arguments for this option center around usability. There is one app. There isn't any "weird" folder. If done correctly, the user interface would match an existing user interface.

One person suggested an extension to this option where CC could update metadata from the calibre db in the cloud instead of via a wireless device connection.

The argument against is that this option is the most difficult to "monetize", in the sense that it is a lot of work and CC contains no in-app purchasing ability.
Add a function to CC that can import a book from a calibre-style folder on the device, which is one that contains formats, metadata.opf, and cover.jpg. The principle advantage is that from CC's point of view, there is no cloud service involved. The folder appears and can be imported. The disadvantages are that the folder must somehow get to the device, and that the metadata.opf file in the folder must be up-to-date.

This option was modified to include a second app that could browse (somehow) the calibre db in the cloud, download calibre folders, and ask CC to import them. The app would be pay-for, obviating the problem of adding in-app payments to CC.

The arguments for include ease of implementation, not being tied to a fixed set of cloud services, and straightforward "monetization". The arguments against include a more difficult user experience and potential unhappiness if the second app isn't as capable as the user wants.
Connect to a local calibre library downloaded from the cloud to the device. This has the advantage of performance, because everything is local. It appears that this option would be popular only with people who keep their entire library on the device, and therefore should not be considered as an alternative to #1 or #2. This option would need to be pay-for, somehow.

The arguments for include ease of use for people who want their entire library on the device. The arguments against are that it is of no use at all to someone who wants a subset of their library on the device, and (yet again) monetization.

Several people have expressed preference for #1, others for #2. What isn't clear to me is whether the people expressing preference for #2 really prefer it or were indicating that they could accept it under some set of conditions.

I understand that getting compensated for our work is not the end user's problem -- not *your* problem. That is as it should be. It is up to us to choose whether or not to offer functionality, and if offered how. I further understand that it is sometimes better to do nothing than to do something half assed. This understanding argues for doing nothing or doing option 1, based on user experience.

Note that no option would permit modifying the calibre database. There would be no way to change metadata or to add/delete books or formats. This is a downside of option #3 as described above; the is_read syncing would go away.

08-22-2014, 05:22 PM	#89
chaley Grand Sorcerer Posts: 12,482 Karma: 8025704 Join Date: Jan 2010 Location: Notts, England Device: Kobo Libra 2	Reprise This is a good time to summarize what I think I am hearing. The options: Connect to the library in the cloud via its local app. This means that the calibre db must be downloaded to the device, as well as all the covers. The implication is that CC must be able to browse the DB in some way. Two obvious choices: 1) present the information as if it was a content server, or 2) present the information as if it were a CC library. Both require CC to have a deep understanding of calibre's database. The arguments for this option center around usability. There is one app. There isn't any "weird" folder. If done correctly, the user interface would match an existing user interface. One person suggested an extension to this option where CC could update metadata from the calibre db in the cloud instead of via a wireless device connection. The argument against is that this option is the most difficult to "monetize", in the sense that it is a lot of work and CC contains no in-app purchasing ability. Add a function to CC that can import a book from a calibre-style folder on the device, which is one that contains formats, metadata.opf, and cover.jpg. The principle advantage is that from CC's point of view, there is no cloud service involved. The folder appears and can be imported. The disadvantages are that the folder must somehow get to the device, and that the metadata.opf file in the folder must be up-to-date. This option was modified to include a second app that could browse (somehow) the calibre db in the cloud, download calibre folders, and ask CC to import them. The app would be pay-for, obviating the problem of adding in-app payments to CC. The arguments for include ease of implementation, not being tied to a fixed set of cloud services, and straightforward "monetization". The arguments against include a more difficult user experience and potential unhappiness if the second app isn't as capable as the user wants. Connect to a local calibre library downloaded from the cloud to the device. This has the advantage of performance, because everything is local. It appears that this option would be popular only with people who keep their entire library on the device, and therefore should not be considered as an alternative to #1 or #2. This option would need to be pay-for, somehow. The arguments for include ease of use for people who want their entire library on the device. The arguments against are that it is of no use at all to someone who wants a subset of their library on the device, and (yet again) monetization. Several people have expressed preference for #1, others for #2. What isn't clear to me is whether the people expressing preference for #2 really prefer it or were indicating that they could accept it under some set of conditions. I understand that getting compensated for our work is not the end user's problem -- not your problem. That is as it should be. It is up to us to choose whether or not to offer functionality, and if offered how. I further understand that it is sometimes better to do nothing than to do something half assed. This understanding argues for doing nothing or doing option 1, based on user experience. Note that no option would permit modifying the calibre database. There would be no way to change metadata or to add/delete books or formats. This is a downside of option #3 as described above; the is_read syncing would go away.