Thoughts on CC extended details in List view

[kaufman]

Definitely optional.

Seriously, I think it needs to be optional, because some people are going to want a ton of fields that may come and go, and they may want labels, and some people like me are just going to have a few more standard fields and then it woould just clutter the display.

Or, if you leave a blank space for missing ones, then you don't need to show them for anyone.

[chaley]

My problem is that we are really going to push performance boundaries. The more "options" we have the slower to work out what to show, which directly translates into slower flings and scrolls, which directly translates into unhappy users. We already get complaints that cover rendering is too slow, and this is going to make it slower. It is easy to forget that these devices are slow and memory challenged.

To overcome the problems it might become necessary to limit the number of choices to 1 or 2 fields, and/or to limit the layout choices in some way such as fixed width regardless of device size. Entering an empty line because there is no data to show requires processing both in CC and in Android widget layout. Etc.

[kaufman]

That makes complete sense. Perhaps the best solution is to just simplify a lot. Pick 2 or three layouts new and then let users select which ones they want. For example:

Standard view
Standard + Tags
Standard + Publisher+Pub date
Standard + Tags+ Publisher + Pub date

You can even add a note at the bottom that you are limiting it to this for now because of device limitations. Then in a couple of years I will come along and point out to you how much faster devices are and we can revisit this for 4.4.0.

Edit: since this isn't going in for a while, if you do decide to just pick a couple of fixed layouts perhaps you could have a thread where you ask people for suggestions and just pick the top three.

[chaley]

I am going to put this aside for a while in hopes it will age like a fine wine. There might be some way to trade a little space for a lot of time, or to do any processing where it won't affect fling speed.

In any event, some things must happen before we can do anything. The most important is finding a way for CC to know the column setup for all the connected-to libraries, not just for individual books. This requires coordinating calibre and CC, and requires some small API modification in calibre. Once this is done we will be able to have column pick lists and metadata, obviating the need to (for example) manually type the grouped custom column definitions in settings.

[kaufman]

Sounds reasonable, but I feel I should warn you that this means you have completed all of my requests.

Not to worry, I just thought of a little one that I am off to post in the with list.