|
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.?
|