Opinions wanted on details of new GUI features

[chaley]

I am now wrapping up implementing several new features that use Kovid's stellar custom column database code, and I would like some opinions on some details.

The background: calibre users will soon have the ability to create user-defined 'custom columns' that are stored individually in the database and seen as columns on the GUI. A custom column can be one of several types: 'text/multiple' (like today's Tags), 'text/single' (like today's Publisher), 'comments' (like today's Comments), 'yes/no' (boolean), 'datetime', 'integer', 'float', and 'rating' (like today's Rating). Those of interest for this message are 'yes/no', 'text/multiple', and 'text/single' .

Questions:

1. Like most columns, Yes/No columns can actually have three values: Yes, No, and not-set. What should a search for 'col:no' return, columns with No or columns with either No or not-set? What should col:false return, No or either No or not-set? What should col:true return, Yes or both Yes and No (currently, searching for true means testing if the column has a value.)

When considering the choice, note that if col:yes matches only columns containing 'Yes' and col:no only columns containing No, then:
- a search for 'not col:yes' would get both No and not-set.
- a search for 'not col:no' would get both Yes and not-set.
- 'not (col:yes or col:no)' would get only not-set columns.

Alternative: the value No goes away, leaving as possible values Yes and not-set, making the column effectively two-valued.

2. Text/multiple and text/single columns will appear in the tag browser as categories. Should they disappear when they are removed from the GUI (config/interface/uncheck column)? If so, should the standard categories also disappear if unchecked? For example, if I take Publisher off the GUI, should it also disappear from the tags browser?

3. A 'restrict view' feature has been added that, when selected, restricts the GUI to show only books that match the restriction (a saved search). The restriction is selected in a place different from the search box; the search box is left empty. A restriction not only limits the books displayed, but also limits contents of the categories in the tags pane to items in the selected books. Searching and tag browsing operate only on the books matching the restriction. The intent is to permit definition of 'mini-libraries': calibre acts as if the library contained only the selected books.

The question: how should a restriction be visually indicated? Options I have thought of: a) set the 'number of books' text next to the search box to 'restricted' instead of 'all books', b) color that same box/text (what color)?, or c) be indicated by the fact that the restriction selection box has something in it. Ideas?

Please note: adding a box to the libraries bar is not an option.
---
Thanks in advance.

[rtype]

This Sounds like a great feature, looking forward to seeing it.

1> I would go with the Alternative, i.e. it is either set or not.

for 2 main reasons,
a> If you want to be able to display 3 states on an UI you cannot use a checkbox, which is the IMHO clearest way to display a Boolean value. and the easiest for a user to interact with.
b> While the concept of null or not set is clear to programmers, it has been my experience that it causes confusion with end users.

Just my 2 cents.

[chaley]

Originally Posted by rtype

1> I would go with the Alternative, i.e. it is either set or not. for 2 main reasons,
a> If you want to be able to display 3 states on an UI you cannot use a checkbox, which is the IMHO clearest way to display a Boolean value. and the easiest for a user to interact with.

Actually, checkboxes can be tristate. They are normally used to indicate 'set to yes', 'set to no', and 'no change'.

That being said, so far I have failed to convince the graphic toolkit to display read-only data in the display table using a checkbox , and I have been too lazy to paint my own 'check'. I have succeeded in using a checkbox to edit the data, but doing so is less appropriate if the read-only display is text.

b> While the concept of null or not set is clear to programmers, it has been my experience that it causes confusion with end users.

I tend to agree. However, some non-programmers have told me that they think of null as 'I don't know', which seems to work for them and is, luckily enough, exactly what it means.

Just my 2 cents.

Very inexpensive advice. Not cheap, though.

[rtype]

Interesting I'll have to take a look at trisate checkboxes.

It would be great to be able to change these fields from the display table (I'm assuming this is the main calibre view)

I'm thinking of the type of scenario like where I select a bunch of books, do send to device and then click one of the check boxes in my new "sent to device" column and it checks all the check boxes of the selected books.

:-) I don't want much really.

[Dopedangel]

well how about using color like
red for no
green for yes
yellow for undecided

[chaley]

Originally Posted by rtype

It would be great to be able to change these fields from the display table (I'm assuming this is the main calibre view)

Yes, it is, and yes, you can edit them directly on the view like other fields.

I'm thinking of the type of scenario like where I select a bunch of books, do send to device and then click one of the check boxes in my new "sent to device" column and it checks all the check boxes of the selected books.

Unfortunately, the selection goes away when you double-click a field to edit it. However, you can do what you want using the bulk editor (once custom columns are in it). Select what you want, bring up the bulk editor, go to the (new) second tab, then indicate that all the boxes in that column are to be set to yes (however that is done).

:-) I don't want much really.

Nope. Not yet at least.

[chaley]

Originally Posted by Dopedangel

well how about using color like
red for no
green for yes
yellow for undecided

Don't understand.

Are you talking about the results of a search, or how the data is displayed in the main view? If the former, what is colored: the search box or the results? If the latter, then would one see colored rectangles on the view?

[Worldwalker]

1. I like the yes/no/not-set model, but then again I'm a programmer. Perhaps if it was presented to the user as something like yes/no/maybe or yes/no/NA?

col:yes should match only yes, and col:no should match only no. I think that's what users will expect. To match both yes and not-set, you'd just use not col:no, and vise versa.

2. Yes. If I've removed a column from the GUI, that means I don't need or want to deal with it, and that includes having it sneak back in via the tags browser.

3. Indicated by the restriction selection box being populated. You might also change its visual properties in some way, like coloring the background (blue, perhaps?) to make it more obvious that it's active.

How are you handling the matter of Sony collections? Ideally, at least from my point of view, there should be a checkbox in column properties to determine whether the column is treated like a tag for collection purposes or not. If it can't be user-selectable, then I think they shouldn't be used to generate collections at all; I wouldn't want to have a collection of, say, the books I got from MobileRead. That's useless Reader-side. But I do want a column to designate where books come from, so I can check back for new versions, etc.

And I like rtype's idea about the bulk check-off very much.

One thing to consider: how are you going to explain this to people who don't really have any conceptual model for what a database table is, what a field is, etc.?

[kovidgoyal]

@chaley: Regarding display of bool columns. I'd suggest simply using Qt.DecorationRole. Return a QIcon of a green tick mark for true, red X for false and NONE for blank. IIRC, those two images are already included with calibre

[chaley]

Originally Posted by Worldwalker

1. I like the yes/no/not-set model, but then again I'm a programmer. Perhaps if it was presented to the user as something like yes/no/maybe or yes/no/NA?

Interesting idea. It makes the screen a bit less visually appealing because of the extra data, but that is OK. What about 'yes/no/?' ? Searching for col:? would then do what is expected.

2. Yes. If I've removed a column from the GUI, that means I don't need or want to deal with it, and that includes having it sneak back in via the tags browser.

That is what I thought, which is why I asked the question.

How are you handling the matter of Sony collections?

Kovid suggested that the existing mechanism in the device plugin configuration be extended. Currently the box for my Sony 300 includes the ability to make collections from any of tags, series, and author. This list would be extended to include the text custom columns. If the column is multiple, then all the 'tags' in that column will become collections. If the column is single, then each individual value will become a collection.

I don't know when the plugins will be enhanced in this way.

And I like rtype's idea about the bulk check-off very much.

Hmmm ... Perhaps I can do this with the right-click context menu. It doesn't kill the selection.

One thing to consider: how are you going to explain this to people who don't really have any conceptual model for what a database table is, what a field is, etc.?

Most people understand spreadsheets and their columns, and this isn't all that different. However, I almost certainly won't be writing the manual text for it (I know from long experience that I write bad manuals), so the right answer is I don't know.

[chaley]

Originally Posted by kovidgoyal

@chaley: Regarding display of bool columns. I'd suggest simply using Qt.DecorationRole. Return a QIcon of a green tick mark for true, red X for false and NONE for blank. IIRC, those two images are already included with calibre

Thanks! That is the secret sauce I was missing. I kept trying to do it with widgets, which didn't work at all.

In this case, would you use a tristate checkbox to set it, or a combobox containing Yes, No and blank? Either is possible, although there might be some issues with the combobox painting over the decorations.

[kovidgoyal]

A tri state check box with a dynamically changing label should do the trick.

Incidentally I'm planning to make a release in the next day or so. Are you happy with custom columns SQL as it is now? I'd rather not have to make another change to the db schema.

[chaley]

Originally Posted by kovidgoyal

A tri state check box with a dynamically changing label should do the trick.

Tried that. The label didn't display. I will try it again, as I have learned a lot since then.

Incidentally I'm planning to make a release in the next day or so. Are you happy with custom columns SQL as it is now? I'd rather not have to make another change to the db schema.

I will take this to the tickets, as the discussion will be rather detailed and arcane.

[Worldwalker]

I don't want to be forced to make collections out of custom columns.

For example, my major need for a custom column is for the origin of the file. I want to be able to label something as being from MobileRead, Project Gutenberg, Feedbooks, or whatever. There would be no value whatsoever to me, and unnecessary clutter, in having collections by those names. They're not something I select books to read by; they're something I need to manage books in Calibre. If they're forced to become collections, they'll be MUCH less useful to me, and most likely to a lot of other users as well. Either there should be a way to choose if you want them to be collections or not (would having the column name in square brackets, like is done now with tags, be a viable option? though I'd rather a column-attributes dialog box). or they shouldn't be collections at all, and if someone really wants to make such a collection, they'd have to use a tag as they do now. There are a LOT of library-management purposes for custom columns that would be unwanted as collections.

Yes/No/? would work fine, and you're right, the searching would be more intuitive.

Don't be too sure that everyone understands spreadsheets, by the way. I'm thinking of my mother-in-law. Spreadsheets are familiar to people who work in offices, or who use their computers for things other than web-surfing and email, but I don't think there's any reason to believe that only those people are likely to use calibre, especially as ebook readers become more mainstream.

[chaley]

Originally Posted by Worldwalker

I don't want to be forced to make collections out of custom columns.

Clearly I didn't explain things well. This is why I don't write manuals.

What I was trying to say that you will have the option of using a custom column to generate collections, just as you have today with Tags, Series, and Authors. To do so, you will configure the device plugin to use a given (text) custom column. If you do not change the configuration, no custom column will be used to generate a collection.

Don't be too sure that everyone understands spreadsheets, by the way.

OK.