GUI sneak peek

[Jon]

Here are screen snaps of the proposed new reference Types and fields. This will be the last opportunity to comment on this -- once the next version of Bookends is released, it will be difficult to change. So please take this opportunity to examine the layouts in detail. One specific question: does it make sense to have an Edition field and a Vol # field for Book Types? I think maybe yes (e.g. Edition: Fifth Edition, Vol #: 5), but you all can tell me.

Journal:



Book:




Edited Book:




Book Chapter:

[tom]

Hi Jon,
just two remarks:

in "journal article" the field "City" should be "Address" (like before it would be the Address of the corresponding author and not the publishers) and "Year" should be like before "Date" (for journal articles the exact date is sometimes useful)

good job!
tom

[Jon]

Thanks, Tom. Of course you are right. They were changed by mistake, and will be changed back to Address and Date.

I have uploaded the revised image for Journal Article.

Jon
Sonny Software

[Craig]

It'd be nice if the labels left no ambiguity as to the type of information expected. I find buttons like "Orig Pub" and "Reprint Edn" a little confusing. Is "2nd" an appropriate answer for "Reprint Edn"? Is "1986"? or simply "yes"? or a longer string with publisher information?
I recognize that space is limited; perhaps a "tooltip" could pop up when mousing over the buttons that would give further guidance or an example.

[Jon]

Yes, that's a problem that even a larger button wouldn't solve...the labels are much the same as in EndNote, BTW, except with some abbreviations. And frankly, there is some flexibility here, because different people have different needs, and there are no rigid rules regarding reference information. This may require a trip to the docs. Here are some guidelines that will be included in the User Guide:

Reprint Edn (Reprint Edition): If the work was originally published under a different title, you can place the original title and year in this field.

Orig Pub (Original Publication): For a republished work, you would put information about the original publication here (e.g. publication date, place, publisher,).

Trans Author (Translated Author): If the author's name is in a non-Roman language (e.g. Chinese), you can use this field to enter the translated name.

Trans Title (Translated Title): If the title is in a non-Roman language (e.g. Chinese), you can use this field to enter the translated title.

Ser Editor (Series Editor): The editor of a book series.

Ser Title (Series Title): The title of a book series.

# of Vols (Number of Volumes): The number of volumes in a multiple volume work.

Vol # (Multiple Volume Number): In a multiple volume work, the number of the volume being cited.


Jon
Sonny Software

[mtauton]

Jon,

Do you think that it is worth having a separate feild for pdf attachments rather than including them in the keywords feild?

Matt

[Jon]

No. For several reasons. First, is would have to be a scrolling field (you can have many attachments per reference). Second, it would break existing attachments. Third, there would be no Term List for attachments. Fourth, I see no advantage. I think attachments in the Keywords field works well. Why change it?

Jon
Sonny Software

[Sue]

I'm using 'User 1' for call numbers. I've rewritten my most used import filters to import this information.

Would I need to move the call number data in my existing references into the new field? And would I need to change the import filters too?

Thanks

Sue

[Tacitus]

............I see no advantage. I think attachments in the Keywords field works well. Why change it?

One thing it does do is clutter up the term list for keywords. If attachments are to be left in the keywords field, why not (if possible) exclude them from the keyword term list. I can see no advantage to having them listed in both places.

Tacitus

[frvs]

One specific question: does it make sense to have an Edition field and a Vol # field for Book Types? I think maybe yes (e.g. Edition: Fifth Edition, Vol #: 5), but you all can tell me.
[/img]

Yes, by all means.
The only thing that bothers me slightly is the Volume thing, on three different grounds. I may be totally wrong regarding all three, but I guess it won't hurt for Jon to clarify this a bit. First, in Book Chapter the Volume field (which has an embedded Issue field) becomes Book Title. Now, imagine the group title includes some words in parenthesis. Would this not activate the embedded Issue field in weird ways? Second, there is redundancy regarding the Volume and Volume # fields for most citation types, right? Third, assuming the Volume # field is to be used, it looks a bit tiny. Frequently, specific volumes of a multi-volume book have specific titles, which would go in this Volume #. The present field size is likely to hide even medium-sized titles.
Same comment regarding the Translator field in cases when there is more than one translator. It would be ideal if this field had enough room to see at least two names.
But these are minor observations and some of them may well be misguided. Basically, I am very pleased with this historic improvement to Bookends. Well done!
Ah, and another thing. Would it be very hard to allow configuration of the sequence of jumps from field to field using the tab key? There are now many fields, and I fear their sequence is not always very practical when it comes to inputing data by hand. If the sequence of tab jumps could be configured, this would surely speed data entry a lot.

[Jon]

I'm using 'User 1' for call numbers. I've rewritten my most used import filters to import this information.

Would I need to move the call number data in my existing references into the new field? And would I need to change the import filters too?Sue

Yes, that would be advisable. Moving the data in User1 to the new Call Number field in one step is easy -- Global Change -> Move Field.

Jon
Sonny Software

[Jon]

One thing it does do is clutter up the term list for keywords. If attachments are to be left in the keywords field, why not (if possible) exclude them from the keyword term list. I can see no advantage to having them listed in both places.

Having them in the Term List does no harm, that I can see (they all sort to the end). And you can use the Term List to quickly find them. Again, what harm?

Jon
Sonny Software

[Jon]

The only thing that bothers me slightly is the Volume thing, on three different grounds. I may be totally wrong regarding all three, but I guess it won't hurt for Jon to clarify this a bit. First, in Book Chapter the Volume field (which has an embedded Issue field) becomes Book Title. Now, imagine the group title includes some words in parenthesis. Would this not activate the embedded Issue field in weird ways?

No. The embedded issue field is only for Journal Articles [I tried to make that clear with the new label Vol (Issue)]. Bookends will ignore the parentheses if it's not a Journal Article. Try it now, if you like -- that is built into the current shipping version of Bookends.

Second, there is redundancy regarding the Volume and Volume # fields for most citation types, right?

I don't know. You all tell me. For book-types, I thought Volume would be used for titles (as we do for Books now), and the new Vol # field is for multi-volume works where you need to specify the number of the particular volume cited.

Third, assuming the Volume # field is to be used, it looks a bit tiny. Frequently, specific volumes of a multi-volume book have specific titles, which would go in this Volume #. The present field size is likely to hide even medium-sized titles.

No, it's for a number (#), like: 5

Same comment regarding the Translator field in cases when there is more than one translator. It would be ideal if this field had enough room to see at least two names.

If the fields were scrolling, it would make the drawer larger than the default window (and you wouldn't be able to see them all on smaller screens, like an iBook's). Don't forget -- clicking on the label enlarges the field, so you can always see/add/edit any information in any field. So multiple lines are not a problem.

Ah, and another thing. Would it be very hard to allow configuration of the sequence of jumps from field to field using the tab key? There are now many fields, and I fear their sequence is not always very practical when it comes to inputing data by hand. If the sequence of tab jumps could be configured, this would surely speed data entry a lot.

Unfortunately, maintaining backward compatibility makes that difficult.

Jon
Sonny Software

[frvs]

Second, there is redundancy regarding the Volume and Volume # fields for most citation types, right?

I don't know. You all tell me. For book-types, I thought Volume would be used for titles (as we do for Books now), and the new Vol # field is for multi-volume works where you need to specify the number of the particular volume cited.

Third, assuming the Volume # field is to be used, it looks a bit tiny. Frequently, specific volumes of a multi-volume book have specific titles, which would go in this Volume #. The present field size is likely to hide even medium-sized titles.

No, it's for a number (#), like: 5

Jon
Sonny Software

Currently I store volume # (and title, if any) together in the Volume field. In the following example,
Gaignebet, Claude. “Histoire critique des pratiques superstitieuses qui ont séduit les peuples et embarassé les savants.â€

[Jon]

First, to be clear, the Book Title is just another name for the Volume field for, uh, books. The Vol # is for the number of the volume.

BUT, there is nothing that prevents you from putting the volume number in the same field as the volume title if you want to. Bookends doesn't care. Then just leave the Vol # field empty in that case.

It seems that for book chapter you have the following 4 pieces of information you need to output:

Title: Histoire critique des pratiques superstitieuses qui ont séduit les peuples et embarassé les savants.
Book Title: Modes et modèles
Vol #: 5
Multi-volume name: Histoire des mœurs

Is this right? If so, then you would put the last three (which are now in the Volume field together) into

Book Title
Vol #
Ser Title

Remember, you don't have to do this! But you *can*, and it makes output more flexible in the end.

On a general note: because people adapted their reference info for fewer fields in older versions of Bookends, of course changes will have to be made to existing databases to take advantage of the new fields. But it should rarely be *necessary* to do this. As in the case above, keeping all that info in one field (Volume) should still work.

Jon
Sonny Software