user-defined tick boxes

[Shayne]

Hi Jon,

I am wondering what the best way of adding information about Journal articles, etc., I have in hardcopy would be. Some Journal articles I have as pdfs, and these can easily be attached in BE, and equally importantly, at a glance I can see whether I have a copy of the article. In the same way, I have a large collection of photocopies stored in filing cabinets (some under author’s name, some under subject).

Do you have any ideas of how I might reflect this in my BE database?

I had wondered about colour coding, but that is too hard on my eyes (unless one could colour code only part of the list view).

I had also toyed with user1-4, but really need them for other things.

I realise I could use some of the new fields, but I really would like to be able to see this information at a glance.

Is there any way that one could have a couple of user-definable tick-boxes? This would not take up much space on the GUI, and would be highly visible. I would use them to refer to my filing cabinent, but others could do with them what they wanted--â€

[Jon]

I had wondered about colour coding, but that is too hard on my eyes (unless one could colour code only part of the list view).

You can change the colors in Preferences, if that's any help.

I realise I could use some of the new fields, but I really would like to be able to see this information at a glance.

If you open the ref window drawer you can do that at a glance.

Alternatively, you could create a format that displayed what you want, and use View Formatted to see what you'd like to keep track of.

Another approach might be to make static or smart groups (the new Command key mechanism for adding refs to static groups might be very handy here, and static groups are displayed in the Info Drawer in the List View, which also may be helpful).


Jon
Sonny Software

[Shayne]

Thanks for the reply Jon.

You can change the colors in Preferences, if that's any help.

I tried that, but I mainly work from the List View window, and even with the option of changing the colours, a whole line in four or five different colours is hard on the eyes.

If you open the ref window drawer you can do that at a glance.

Agreed, but I usually work from the List View window.

Alternatively, you could create a format that displayed what you want, and use View Formatted to see what you'd like to keep track of.

Another great suggestion, but I like to use only the format I use for output--I want to be able to see things at a glance without opening anything, or changing any settings/formats, etc.

Another approach might be to make static or smart groups (the new Command key mechanism for adding refs to static groups might be very handy here, and static groups are displayed in the Info Drawer in the List View, which also may be helpful).

This too is a great idea, but I really would like to be able to replicate the lovely little paperclip I see in the List View window. In a sense it is a way of adding data without adding text fields.

I will be interested to see if anybody else would find user-defined tick boxes (or something similar) useful. I have no idea, however, if it would be easy to implement.

Kindest regards,
Shayne

[Jon]

Hi Shayne,

If you're not already doing so, you know that you can have up to 5 columns of your choice in the List View, right?

Jon
Sonny Software

[Shayne]

Jon,

I already use 5 columns in the List View, and while that is great, I find the attachment paperclip in the left-hand side of the List View extremely useful--another 2-3 of these kind of icons available in the List View would be amazing.

Kindest regards,
Shayne

[Jon]

Such things work well for binary features (e.g. attachments, marked status) but not at all for quantitative ones (so to speak).

What do you (and others) think about having color apply only to the first column and not the entire row? Would that make it more readable/useful?

I'd be interested in input from anyone who cares about the color text feature...

Jon
Sonny Software

[Shayne]

Such things work well for binary features (e.g. attachments, marked status) but not at all for quantitative ones (so to speak).

Jon,

I am not sure that what I am asking for is necessarily quantitative. Although they would be user-definable in the sense that the user defines what they represent or are called, what I was thinking of was very much like the binary features you mention. Perhaps another way of thinking about it is user-definable marked statuses that do not add the reference to the hist list, but do somehow make something visible in the List View.

Kindest regards,
Shayne

[Shayne]

What do you (and others) think about having color apply only to the first column and not the entire row? Would that make it more readable/useful?

As in all things, I think the key is flexibility. Some people will want the entire row changed. Some will want only the first column, some other columns.

The only way to deal with all possible variations is, I would suggest, to offer the ability to apply the colour to:
a: all columns
b: user-specified columns
c: another variation

The key, I think, is flexibility.

Kindest regards,
Shayne

[Jon]

I understand. But that is no different from adding more fields. And no doubt one would then want the ability to search based on those criteria as well.

Bookends now offers a wealth of data organizing mechanisms. I don't see the need of adding more. But I'm willing to consider different ways of displaying the data.

Jon
Sonny Software

[Rudi_Grams]

What do you (and others) think about having color apply only to the first column and not the entire row? Would that make it more readable/useful?

Jon
Sonny Software

Yes, I would find this a better solution!

Rudi

[jadrain]

What do you (and others) think about having color apply only to the first column and not the entire row? Would that make it more readable/useful?

Hi Jon - Personally I think this would be a retrograde step and require a few more synapses to fire to get the overview presented by having entire records coloured in list view - it would put hurdles in the way of the wonderful clarity colours have provided. Others may feel differently. At this point restricting the colour to just one of the columns would severely diminish its usefulness in my view. If you go this route please make it a preference if possible. I suppose the alternative would be to make colour assignable by field, but I'm sure this would add a large amount of overhead and probably too much complexity.

With regards to Shayne's point/request, I would find a couple of binary-toggle fields (which would need to be in addition to the five fields currently permitted in list view) quite useful, if not critical. One of the ways I use colour is basically to set such a toggle. That's fine, but another way I use colour is to broadly classify references by subject area. This latter use seems a more natural one, and I'd be all for using binary toggles with some sort of radio box/check indicator similar to the attachments indicator. The more I think about it, the nicer it seems, though again it may be a lot of overhead for something only a few people would use.

Jonathan

[Jon]

Hi Jonathan,

Please be specific. How would you want Bookends to indidate "area" by toggling an icon.

And BTW, I have tried using color for the first column only, and think it works quite well (no need to see all data in that color to get the idea). Perhaps I'll make this a Preference choice.

Jon
Sonny Software

[jadrain]

Hi Jonathan,

Please be specific. How would you want Bookends to indidate "area" by toggling an icon.

Jon - not sure I understand. What I meant was I use colours to indicate subject area. Check boxes or whatever are a separate yes/no thing (which I end up mixing in with colours) and I'm not sure how one would want to identify what a given yes/no field refers to as a column in list view. This I guess is actually I suppose an argument against using such things. The attachments indicator is clear because it's a specific icon whose meaning is universally defined and understood. I'm not sure offhand how you could indicate the user-specific meaning of a checkbox or radio button in list view aside from the name of the column, and this could result in a very wide column (for the name) for a small check box.

The yes/no use I have for colours is whether papers in a particular subject area (trilobites) have been processed for a major database project. This sort of mixes metaphors for colours, as trilobite papers end up having two colours, one for done and one for not done. This is why I thought having some sort of simple indicator field would be good.

I suppose the other logical way to go with this discussion is just not messing with basic fields or field types at all but allowing more than five columns/fields in list view. I think this would solve the problem for everyone.

For only showing colour in the first column, I'm sure it's fine for lots of uses and for lots of people. And obviously I haven't tried it. But entirely coloured records let me focus on particular sets and "blip out" the rest. A preference choice for just first column versus whole record would be fine. I think this boils down a lot to what the meaning of colour assignment is for particular users. If classifying papers within a generally related set is the point, then just first column might be great. If making a fundamental distinction between essentially different groups of papers is the point, then whole-record colouring is better. Adding one-column as an option (or even the default) is fine, but losing whole-record colouring would be a drag.

Jonathan

[Shayne]

Personally I think this would be a retrograde step ...

Hi Jonathan,

I must disagree that it is not a retrograde step if it is added as a preference option. I have never suggested Jon should change the colour coding scheme, other than to allow more flexibility. I do not think flexibility can ever be a retrograde.

Kindest regards,
Shayne

[Shayne]

What I meant was I use colours to indicate subject area. Check boxes or whatever are a separate yes/no thing (which I end up mixing in with colours) and I'm not sure how one would want to identify what a given yes/no field refers to as a column in list view. This I guess is actually I suppose an argument against using such things. The attachments indicator is clear because it's a specific icon whose meaning is universally defined and understood. I'm not sure offhand how you could indicate the user-specific meaning of a checkbox or radio button in list view aside from the name of the column, and this could result in a very wide column (for the name) for a small check box.

Jonathan,

I am not sure if I agree with your argument against check boxes. The whole point is that it is user-specific. It could be an icon, an emoticon, or simply a box with a user-definable name.

I agree, however, that check boxes and colour are--or at least should be--entirely separate discussions.

I suppose the other logical way to go with this discussion is just not messing with basic fields or field types at all but allowing more than five columns/fields in list view. I think this would solve the problem for everyone.

I agree that increasing the number of visible columns in the List View would be great, but do not think that this would solve the problem--not that there is a problem. I see these as separate issues. I think a user-definable tick/check box would be incredibly useful. In that sense, I also see it as a way of displaying data more than adding new data/fields.

I am happy that this request has generated at least a little bit of discussion (and perhaps a new preference).


Kindest regards,
Shayne