Opinions wanted on details of new GUI features

[Starson17]

Originally Posted by chaley

The default would be two-value.
Acceptable?

Make the call yourself, then hand it off to Kovid. I'm pretty comfortable the right call will be made in the end, whatever it is. I'd love to have the tweak if the call is for a two-value default, but I'm already carrying some of my own code tweaks without the official tweak system, so it should be something that others want also. My perspective is from a fairly large library. I'd love to hear arguments for two-value. The checkbox struck me as a good argument - it initially seems two valued, but I can see ways to gray it out, etc. to make the tri-value work.

[Starson17]

How do you contemplate presenting the user with the option to define a Yes/No field? Is there going to be some sort of setup screen for defining fields?

With two-valued you're going to have to have a way to choose the default value. I wonder if you could set it up so the user chooses the default value? I can see presenting two checkboxes for the default value marked Yes and No. If the user clicks neither, the field becomes tri-valued.

[chaley]

Originally Posted by Starson17

How do you contemplate presenting the user with the option to define a Yes/No field? Is there going to be some sort of setup screen for defining fields?

Yes. There are buttons on the columns page in the config dialog that permit adding, deleting, and editing new columns. When a column is created, its type is specified, The type cannot be changed later, although other attributes can be.

The default value for a column is None/null/not-set. A Yes/No column is no different than any other column.

Note that all column types have the null value 'problem'. However, I think that unless the distinction is made important, people won't notice it. For example, for int columns, columns set to a value will sort before columns never set (blank), and I expect that people will think that this behavior is correct. The same is true for the various text fields.

Of course, the same argument can be made for booleans. It is too late in the evening for this sort of discussion. Sigh.

With two-valued you're going to have to have a way to choose the default value.

As I said, the default value for every column is None. If the user doesn't like that, then use the bulk editor after creating the column to set it to the value desired.

I wonder if you could set it up so the user chooses the default value? I can see presenting two checkboxes for the default value marked Yes and No. If the user clicks neither, the field becomes tri-valued.

I see this creating more questions than it prevents. First, it makes yes/no columns strange, different from the other columns. Second, it creates questions about what the boxes mean and highlights a concept the many people simple don't care about. Defaulting to two-value where None and No are considered the same solves that problem. Internally maintaining three values (remembering values that were explicitly set to false) helps protect work of users who later decide to set the tweak to change to visible tri-valued fields.

For the developers out there: the tweak is implemented. The search code is:

            if IS_CUSTOM[loc] == 'bool':
                v = item[loc]
                if tweaks['boolean_custom_column_values'] == 'two-valued':
                    if v is None or not v: # item is None or set to false
                        if q in [_('no'), _('unchecked'), 'false']:
                            matches.add(item[0])
                    else: # item is explicitly set to true
                        if q in [_('yes'), _('checked'), 'true']:
                            matches.add(item[0])
                else:
                    if v is None:
                        if q in [_('empty'), _('blank'), 'false']:
                            matches.add(item[0])
                    elif not v: # is not None and false
                        if q in [_('no'), _('unchecked'), 'true']:
                            matches.add(item[0])
                    else: # item is not None and true
                        if q in [_('yes'), _('checked'), 'true']:
                            matches.add(item[0])
                continue

[Sabardeyn]

Alright, my completely biased opinions are:

1) Yes/No/Null; the default starting state is null. I'll accept setting this field as a dual or triple value state via tweak file. As for the settings, I'll use Guyanonymous' listing, which I completely agree with:

col:false -> returns columns with no entry at all
col:true -> returns columns with any type of entry (yes or no)
col:no -> returns columns with no only
col:yes ->returns columns with yes only


2) I'm assuming you meant that unchecking a text/multiple or text/single column would hide the related entries in the tag browser. (Disappear had me thinking deleted for a bit.)

I don't think they should be hidden. This might be covered by #3, Restricted Views, but what if I need a subset of my data but do not need to actually see the value? For instance, all books by Doubleday? Viewing the Publisher column in this situation is not going to provide any more information about the books shown.

Anyone who does not want the related material shown can simply ignore those entries.


3) Is their some kind of naming to restricted views? Without a name, "275 of all" is going to be inadequate. Particularly if a user has more than one library, let alone reader device. Without names something like "275 of all (3000)" might be slightly more acceptable. At least the number of entries is one possible way to determine if you're looking at the correct library.

[rtype]

I Originally argued against a tri value field , but I have got to say Starson17 has convinced me that it makes sense to have it yes/no/null for the reasons they have outlined.

The tweak looks like a great solution.

[Starson17]

Originally Posted by chaley

The default value for a column is None/null/not-set. A Yes/No column is no different than any other column.

Why am I so confused? If the default value is null on a Y/N column, isn't it tri-valued? Are you just thinking of whether it can be set to null after it was previously set to Y or N, or do you mean that null=N or are you just thinking of display issues?

for int columns, columns set to a value will sort before columns never set (blank), and I expect that people will think that this behavior is correct. The same is true for the various text fields.

Exactly. I'm more confused. Shouldn't the Y/N column behave this way, too? In which case it would be tri-valued wouldn't it?

As I said, the default value for every column is None.

Which makes it tri-valued if it can also be Yes or No......

Defaulting to two-value where None and No are considered the same solves that problem. Internally maintaining three values (remembering values that were explicitly set to false) helps protect work of users who later decide to set the tweak to change to visible tri-valued fields.

Aha - You're just not going to let the average user search for "false" and find anything? Or are you still going to allow that, but have a search for No pull up the internally saved null as well as No?

[chaley]

I know that I am going to make things worse here.

Before I start, is there anyone who still pushes for two-value? rtype and theducks voted for, but rtype has (mostly) changed votes. I ask because although I have implemented the tweak, its existence does complicate things. "Someone" will need to explain its existence, which might be harder than explaining tri-state columns.

Originally Posted by Starson17

Why am I so confused? If the default value is null on a Y/N column, isn't it tri-valued? Are you just thinking of whether it can be set to null after it was previously set to Y or N, or do you mean that null=N or are you just thinking of display issues?

One must separate storage from behavior. Some columns in calibre can be Null, but that fact is effectively hidden from the user. For example, Null Comments fields are indistinguishable from those that contain an empty string, including for the :false search.

What is being debated is the behavior for Null for boolean columns. The answer seems to be 'let me choose'.

If the user chooses two-value, then the behavior of No and Null become indistinguishable, just as the empty string and Null are indistinguishable for Comments.

Exactly. I'm more confused. Shouldn't the Y/N column behave this way, too? In which case it would be tri-valued wouldn't it?

That was why I asked the question. Note that we are discussing behavior: make it DoWhatIMean, not something IDon'tMean.

Which makes it ...

I lied. Currently most columns do have a value set, so they are never Null.

That being said, don't confuse what is in the table with behavior the user sees. Calibre has for some time treated :false as matching anything that evaluates to zero, including Null, empty strings, and zero values. For example, try 'rating:false'. You will get columns that you edited to zero.

Aha - You're just not going to let the average user search for "false" and find anything? Or are you still going to allow that, but have a search for No pull up the internally saved null as well as No?

In two-value mode, all of 'false', no', and unchecked' match Null columns or columns with false in them. All of 'true', 'yes', and 'checked' will match columns with true in them.

I ask again: is there anyone who still strongly thinks that two-valued columns should be offered, and even more important, that they should be the default? One reason I ask is that I polled my several people, technical and non-technical, and all of them said that they expected the behavior to support 'I set it to checked', 'I set it to unchecked', and 'I haven't set it yet' (trivalue). I am very nervous about the two-value default.

[Sabardeyn]

Yes, it does seem as though we're defining a "tri-valued" state differently. To me any of the three values (Yes, No or Null) can be set by the user, at any time. As well as re-set by the user. By this I mean that a field can start as Null, changed by the user to Yes, and then changed back to Null.

While everyone is saying this is a Yes/No field, it really depends on how the user decides to implement it. Here are some possibilities that I can imagine:

Purchase paper edition? Yes, No, Null = decision not yet made
Whose ebook is this? Yes = Dad, No = Mom, Null = Kid (yeah, multi-text would be better, but someone will do something similar)
Ebook's metadata requires updating? Yes, No, Null = unknown

I'm sure that with a bit more thought I could come up with other examples. But I'm at work and it's taken me six hours to get this far!

[chaley]

Thank you all for your comments and suggestions. It can be a frustrating process, but better decisions come out in the end.

I have submitted the code to Kovid. My decisions on the questions were:

1. Support two- and three-value boolean columns via a tweak. I ended up setting the default to three-value.

2. Tag browser categories are displayed even if the underlying columns are hidden.

3. Restrictions are indicated by all of:
- The restriction name is shown in the set restriction box. Note that this box is associated with the tags browser, so it will be hidden when the tag browser is hidden.
- The 'number of matches' box is changed to display '(n of m)', where n is the number of books matching a search, and m is the number of books matching the restriction. When there is no search, n and m are the same. When there is no restriction, the box displays '(n of all)'
- The 'number of matches' box is colored yellow when a restriction is in force.

See here for a somewhat more detailed discussion of what changes are included in the submission.

Note that Kovid might change any of these decisions or decide not to provide some of the underlying features.

[kovidgoyal]

It will be a little while before I have the time to review this patch as I'm still stuck in Mumbai, first because Uncle Sam decided I needed special vetting and now because of the worlds smokiest volcano.

[Starson17]

Originally Posted by chaley

II have submitted the code to Kovid.

Thanks for your efforts. It looks great to me.

[Sabardeyn]

Chaley,

Thanks for all of your hard work. I greatly appreciate the effort you put into thinking of all the permutations users could come up with - and then managing, somehow, to make all of them possible.


Kovid,

In the immortal words of Bill the Cat "Ack!" and "Thbbft!" (respectively). Hopefully you will be able to return soon.

[tlrowley]

Like many, I suspect, I've create a "read?" column with a yes/no checkbox. The lookup name is set to "read". I can't seem to get "read:yes" or "read:no" return any matches. This is in 0.7.2 on Mac OS. I could have sworn that I had this working in the past. Did something break, or am I mis-remembering how I got it working previously?

[Starson17]

Originally Posted by tlrowley

Like many, I suspect, I've create a "read?" column with a yes/no checkbox. The lookup name is set to "read". I can't seem to get "read:yes" or "read:no" return any matches. This is in 0.7.2 on Mac OS. I could have sworn that I had this working in the past. Did something break, or am I mis-remembering how I got it working previously?

#read:no

not:

read:no

[tlrowley]

Thank you. Now up and running.