Thoughts on CC extended details in List view

[kaufman]

I was going to post this in the Wish list thread, but I decided to post it here instead to keep Chaley from having to move it. I am posting it now while I am thinking about it, not in order to pressure Chaley into putting it into this release cycle.

So, I was thinking a bit, and I think I have come up with a simple to explain to users and relatively simpler to implement concept for showing more details in list view.

What if you used a new layout similar to the "choose item to display" popup



And told the user that of the items checked, CC would display as many as would fit with the current list view cover size and font size. It would probably make sense to lock the first two lines with the current information as

Title
Author (Series[Index])

but any other lines would show as many selected items as would fit. People who wanted to show more information could use a smaller font or a larger cover.

This would avoid some confusion, because if all the selected information didn't fit, the user would see why not, and users are already getting used to the idea (from book details) of selecting items to show and ordering them.

For Chaley, this would avoid some complexity (because you don't have to deal with multiple items on one line) while still delivering almost all of the value of this.

One of the things I like about this is that people could select what they want to see, and then just adjust the cover size until it all fit.

I do want to reiterate, that I don't think that any of this information should be clickable. Its just too small a target. IMO, any clicks should go to the detail for that book.

Any thoughts? Does anyone like this idea?

[kaufman]

Did everyone hate this idea, or is it just too early to start thinking about it?

[chaley]

I think it has a lot of merit because of its simplicity, but it doesn't deal well with large screens. I am thinking of something similar but with two checkboxes, or better three radio buttons. The area underneath the first lines would be divided into equal-sized left and right containers. The radio buttons would be labeled "Left", "Hide", "Right" (or something like that). Things marked "left" would be shown in the left hand container in the order encountered on the list, and the same for right.

I also wouldn't put any size restraints on it. Let the cell take up as much space as it needs, even if it exceeds the height of the cover.

There are some potentially "interesting" performance issues that would need thought. In particular, I don't want to be doing a lot of dynamic processing while flinging. I might render the extra info when the cover is drawn, avoiding filling in the extra info while the list is moving rapidly.

[kaufman]

Originally Posted by chaley

I think it has a lot of merit because of its simplicity, but it doesn't deal well with large screens. I am thinking of something similar but with two checkboxes, or better three radio buttons. The area underneath the first lines would be divided into equal-sized left and right containers. The radio buttons would be labeled "Left", "Hide", "Right" (or something like that).

I like it for big screens, but perhaps on smaller devices one column would be better.

Or, how about if the user only had left selected (or hide), you could automagically expand left to the whole width.

Or maybe left, right, full and hide. Then you could have things like tags go all the way across, but show publisher and publication date on the same line.

Originally Posted by chaley

Things marked "left" would be shown in the left hand container in the order encountered on the list, and the same for right.

This might get complicated for users who wanted things on the same line (like publisher and publication date).

How about make them do it in order? If a right follows a left, they are shown on the same line. If two lefts are in a row, then the first one gets the whole line. That makes the results somewhat more deterministic since it is less reliant on the size of the results for a specific book.

Originally Posted by chaley

I also wouldn't put any size restraints on it. Let the cell take up as much space as it needs, even if it exceeds the height of the cover.

I guess I thought that if the user said they wanted small covers, they are saying that they want more books per page. You are probably right that if they say they want lots of information, they are overriding that decision.

Originally Posted by chaley

There are some potentially "interesting" performance issues that would need thought. In particular, I don't want to be doing a lot of dynamic processing while flinging. I might render the extra info when the cover is drawn, avoiding filling in the extra info while the list is moving rapidly.

I bet it will look cool when the extra information blinks in, but how will you know how big to make the area for the book if you don't do the processing of the extra information?

Can't wait to see this in 3.6.0

[chaley]

Originally Posted by kaufman

I like it for big screens, but perhaps on smaller devices one column would be better.

Or, how about if the user only had left selected (or hide), you could automagically expand left to the whole width.

Or maybe left, right, full and hide. Then you could have things like tags go all the way across, but show publisher and publication date on the same line.

Unfortunately we are starting to get into the capabilities of Android layouts.

The first thing to note is that unless one goes to a lot of trouble, Android does the screen layout itself after all the information is added. The programmer tells android the relative positions of the information and the system lays it out respecting those instructions. Thus, if we are doing a two-column layout, we would simply say which column a field is in and the order of the lines. If a column has no information it wouldn't appear. If a field has no information then it wouldn't appear.

There is no straightforward way to have some lines consume 1 column and some lines consume two columns. It can clearly be done, but if one does so then it is up to the programmer to do *all* the layout. This gets us back to some kind of GUI layout designer, which is far beyond your proposal. The way around this would be to create a three-cell layout: full, then a two-column layout below it. I could do that.

Do note that full would equal left if there is no right, or right if there is no left.

This might get complicated for users who wanted things on the same line (like publisher and publication date).

You just raised the ante. The beauty of the original proposition was that there was no compound field display, which is why it is so attractive to me.

How about make them do it in order? If a right follows a left, they are shown on the same line. If two lefts are in a row, then the first one gets the whole line. That makes the results somewhat more deterministic since it is less reliant on the size of the results for a specific book.

For me as a user, this is difficult to understand. There is an implication that lines are left empty "sometimes", such as if I say "left, right, left, left, right". There is an implication that a left and a right have some semantic relationship. There is an implication that a field is displayed even if it is empty. I think it is easier to understand that the lefts are displayed in order in the left and the rights are displayed in order in the right, assuming that the field contains something. There is no attempt to connect them. Of course, if a user does "left, right, left, right" then the "order" rule would present the information together, as long as the the field is actually defined for the book. If the first "right" is empty then it wouldn't show, lifting the second "right" to the first line.

I guess I thought that if the user said they wanted small covers, they are saying that they want more books per page. You are probably right that if they say they want lots of information, they are overriding that decision.

Yes. You choose what you want to see and CC shows it.

I bet it will look cool when the extra information blinks in, but how will you know how big to make the area for the book if you don't do the processing of the extra information?

Android takes care of this. It doesn't render the cell until it has all the information that goes into it.

[kaufman]

Originally Posted by chaley

Do note that full would equal left if there is no right, or right if there is no left.

If this means that if there are no rights at all then lefts would go all the way across, then that's good enough for me.

Originally Posted by chaley

You just raised the ante. The beauty of the original proposition was that there was no compound field display, which is why it is so attractive to me.

Sorry, I didn't mean to do that. I was just thinking out loud. I think that the version with no compound field display will be such a nice addition, that we can put off thinking about compound fields until version 4.

Are you planning on pinning

Title
Author (Series[Index])

to the top, or will we lose the current single line of author and series? That would be a pity and somewhat of a step backwards.

[chaley]

Originally Posted by kaufman

If this means that if there are no rights at all then lefts would go all the way across, then that's good enough for me.

One of the interesting "problems" with doing this derives from something related to what you say: are the cells the same?

Consider a cell where something in both left and right have a value. You see left and right. But what happens in another cell where the left (or right) doesn't have a value? Do we show the empty cell?

Another question: do left and right take 50% of the space each, or does the space allocate? For example, if I put tags on the left and publisher on the right, does the left grow as needed?

In both cases the cells for individual books would differ from one another. This is in fact what Android would want to do, but it might look rather unusual to the user.

Finally, are there borders? Something separating the cells?

Sorry, I didn't mean to do that. I was just thinking out loud. I think that the version with no compound field display will be such a nice addition, that we can put off thinking about compound fields until version 4.

Are you planning on pinning

Title
Author (Series[Index])

to the top, or will we lose the current single line of author and series? That would be a pity and somewhat of a step backwards.

First, note that the content of the first and second lines depends on what sort is in use. If the primary sort is author then the first line is author and the second line is title/series. If the primary sort is otherwise, the first line is title and the second line is author/series. In both cases the third line is the date being sorted on, should that be the case.

My position is that these first 2 (or three) lines are inviolate. They will always be there. The optional cells will appear below. That might create some duplication in the case where one sorts on a date that is also shown in the optional fields. So be it.

[kaufman]

Originally Posted by chaley

One of the interesting "problems" with doing this derives from something related to what you say: are the cells the same?

Consider a cell where something in both left and right have a value. You see left and right. But what happens in another cell where the left (or right) doesn't have a value? Do we show the empty cell?

Another question: do left and right take 50% of the space each, or does the space allocate? For example, if I put tags on the left and publisher on the right, does the left grow as needed?

In both cases the cells for individual books would differ from one another. This is in fact what Android would want to do, but it might look rather unusual to the user.

I think all of these issues, are going to make you crazy. Especially, what's going to happen if one book has tags and another doesn't. Metadata items will not be in the same relative position on a book by book basis. (This might be an argument for having blanks areas where the metadata doesn't exist).

How about instead of having two columns of metadata, you limit them to one column but have an option to show two columns of books in list view? Then you kill a lot of the dead space on tablets but avoid all of the two columns of metadata complexity.

Originally Posted by chaley

Finally, are there borders? Something separating the cells?

I think not, because that will just make everything take up more space.

Originally Posted by chaley

My position is that these first 2 (or three) lines are inviolate. They will always be there. The optional cells will appear below. That might create some duplication in the case where one sorts on a date that is also shown in the optional fields. So be it.

Good, that sounds perfect.

[chaley]

Originally Posted by kaufman

I think all of these issues, are going to make you crazy. Especially, what's going to happen if one book has tags and another doesn't. Metadata items will not be in the same relative position on a book by book basis. (This might be an argument for having blanks areas where the metadata doesn't exist).

The position of metadata will be controlled by the order of the list, not by the book. The main question is "what happens if the book doesn't have that metadata?"

The Android natural outcome (that takes the fewest layout parameters) is that if a field isn't there then is takes no space, that the size of a column is determined by the longest value in that column, and that space is allocated between the columns in the group depending on the relative size of each column. Using this "rule", space is allocated as needed on a book by book basis. If there is nothing in a column then the column is not there. If the relative field sizes change from book to book then the column sizes change from book to book. If the user displays tags on the left and a custom genre column on the right then the sizes of the columns for a given book will depend on the sizes of the values for each book.

I can of course fix the column sizes to be each 50%, but that would force empty columns for books that have no information displaying in that column. I am not convinced that this is better than data-sensitive layouts, other than that users might think that varying cell size is weird.

How about instead of having two columns of metadata, you limit them to one column but have an option to show two columns of books in list view? Then you kill a lot of the dead space on tablets but avoid all of the two columns of metadata complexity.

I don't see how this would be accepted by users. I assume that you are suggesting that if I have 4 values to display then I display 2 on the left and 2 on the right. That doesn't deal with width, and also makes the position of a given metadata item indeterminate, something you implied above wouldn't be acceptable.

Also, aren't we talking only about list view?

[kaufman]

Originally Posted by kaufman

How about instead of having two columns of metadata, you limit them to one column but have an option to show two columns of books in list view? Then you kill a lot of the dead space on tablets but avoid all of the two columns of metadata complexity.

Originally Posted by chaley

I don't see how this would be accepted by users. I assume that you are suggesting that if I have 4 values to display then I display 2 on the left and 2 on the right. That doesn't deal with width, and also makes the position of a given metadata item indeterminate, something you implied above wouldn't be acceptable.

No, I wasn't very clear. Right now the list view screen looks like this:

Book1-Cover | Book1-Metadata
Book2-Cover | Book2-Metadata
Book3-Cover | Book3-Metadata

Your current thought is to give them two columns of metadata so that each row was

Book1-Cover | Book1-Metadata-Left | Book1-Metadata Right
Book2-Cover | Book2-Metadata-Left | Book2-Metadata Right
Book3-Cover | Book3-Metadata-Left | Book3-Metadata Right

My ideas was that you (optionally) give them one column of metadata per book, but two books per row

Book1-Cover | Book1-Metadata | Book2-Cover | Book2-Metadata
Book3-Cover | Book3-Metadata | Book4-Cover | Book4-Metadata
Book5-Cover | Book5-Metadata | Book6-Cover | Book6-Metadata

This allows you to kill a lot of empty space while at the same time avoiding a lot of complexity related to multiple columns of metadata. Does that make sense?

[jackie_w]

When it comes to data layout I find it very difficult to picture things in my head. It's not until I see a prototype that I start to have those "any fool can see that this would be better ..." feelings. I've been wrestling all week rearranging the GUI layout of a personal calibre plugin, trying to get a quart into a pint pot.

Having 2 columns sounds pretty good. Thinking out loud, if I was designing a rough prototype for myself I would start with the Left being wider than the Right and I would populate the Right only with my short metadata fields like #Pages and PubDate(YYYY) and possibly anything in date-format. Which are the 'short fields' would, of course, vary wildly by person.

[kaufman]

Originally Posted by jackie_w

...I would populate the Right only with my short metadata fields like #Pages ...

On an unrelated note, how do you get #Pages to show up? Is that a custom column you have created, or am I just missing some setting?

Thanks.

[jackie_w]

Originally Posted by kaufman

On an unrelated note, how do you get #Pages to show up? Is that a custom column you have created, or am I just missing some setting?

It is a custom column used with this calibre Count Pages plugin. There are several choices for how to count pages (and words, too, if you want).

[kaufman]

Originally Posted by jackie_w

It is a custom column used with this calibre Count Pages plugin. There are several choices for how to count pages (and words, too, if you want).

That is excellent. Thanks.

[chaley]

Question: do you expect that these fields will be labeled as in "Publisher: Baen"? Or do you expect the value to be naked, as in "Baen"? I expect that labeling is preferable because fields can come and go, so you can't depend on the position to know what the value is.

(I can already see the response -- "I want the label optional".)