Those converting from EndNote to Bookends will have noticed that EndNote has more than twice as many fields as Bookends; the number of fields in Sente is unlimited. Bookends is currently significantly limiting in storing discrete bibliographic information because it offers 19 fields.
Some notable fields missing are:
Call Number
Accession Number
Number of Volumes
Edition
Translator
Original Date
Note: although Edition and Translator are mapped to custom fields for certain reference types, custom fields should not be "usurped" for this purpose.
So I ask: how many would like to see the number of fields significantly increased?
please respond to poll for more fields in Bookends
Re: please respond to poll for more fields in Bookends
For the present, I don't find the current number of fields a serious impediment to using Bookends as my primary bibliographic database, but I would like to see more fields added eventually -- it would be very nice to be able to search on some of those additional criteria, and not to have to fold them willy-nilly into a Notes field.thecritic wrote:Those converting from EndNote to Bookends will have noticed that EndNote has more than twice as many fields as Bookends; the number of fields in Sente is unlimited. Bookends is currently significantly limiting in storing discrete bibliographic information because it offers 19 fields... So I ask: how many would like to see the number of fields significantly increased?
...though I think that the addition of new fields would require some careful reworking of the Reference detail window, as the current layout of that window is already crowded.
TH
I haven't run out of fields - yet. But I would definitely like to have more of them available since I am by now using all of the user defined fields and almost all of the other fields. I would be pretty sure that sooner or later I will run into a shortage… I am sure Jon would find a nice way of offering us more fields in an unobtrusive way 
Re: please respond to poll for more fields in Bookends
It probably would need reworking, but that wouldn't be a bad idea. Sections could be hidden and displayed just as they are with groups. It may not be realistic to have *all* fields displayed at once.tharpold wrote:...though I think that the addition of new fields would require some careful reworking of the Reference detail window, as the current layout of that window is already crowded.
As I understand it, from my discussions with Jon, his main reasons for not adding more fields are: (a) the GUI would have to be modified. It would probably require scrolling or widening the screen so as to allow more fields, or perhaps a second tab with additional hidden fields. Jon seems to like having everything viewable all at once, and (b) adding any field seems to require a significant amount of reprograming which is very time consuming.
I understand these concerns of Jon's but I think the lack of fields seriously hurts Bookends. Currently the "custom" fields are used for a number of fields that should be fixed fields, and the lack of the additional fields listed above further limits the application. Issues such as loss of information when moving between programs are very serious for me. I also think that having more fields provides more power and control over how bibliography formats are created. Also, custom fields are no longer custom fields if they are required for vital data that one normally expects to have its own field.
Ideally, I would argue for 1:1 parity with EndNotes - offering every field that they have. In addition to the ones listed above the latest version of EndNotes also offers fields for tertiary authors, translators, original language book title and author (for titles that need to appear, say, in both transliterated and original Chinese form), and other very useful fields.
I have used Bookends for some time without these additional fields, but I miss them almost everytime I use the program. I feel like I'm using an old Windows computer that only allows my filenames to be eight characters long, when I have a computer that can handle databases of thousands of photos and music files, etc. It just doesn't make sense to me to cripple the program in this way.
I understand these concerns of Jon's but I think the lack of fields seriously hurts Bookends. Currently the "custom" fields are used for a number of fields that should be fixed fields, and the lack of the additional fields listed above further limits the application. Issues such as loss of information when moving between programs are very serious for me. I also think that having more fields provides more power and control over how bibliography formats are created. Also, custom fields are no longer custom fields if they are required for vital data that one normally expects to have its own field.
Ideally, I would argue for 1:1 parity with EndNotes - offering every field that they have. In addition to the ones listed above the latest version of EndNotes also offers fields for tertiary authors, translators, original language book title and author (for titles that need to appear, say, in both transliterated and original Chinese form), and other very useful fields.
I have used Bookends for some time without these additional fields, but I miss them almost everytime I use the program. I feel like I'm using an old Windows computer that only allows my filenames to be eight characters long, when I have a computer that can handle databases of thousands of photos and music files, etc. It just doesn't make sense to me to cripple the program in this way.
Hi,Luhmann wrote:I understand these concerns of Jon's but I think the lack of fields seriously hurts Bookends.
I agree entirely. The only serious problem with Bookends in my opinion is its lack of fields and its limit as to how many custom fields and reference types can be used. Sente, on the other hand, now has absolutely no such limitations, and one can add as many fields as one likes (for Chinese, Japanese, or whatever--also note that Sente offers unicode support that is somewhat better than Bookends [Chinese and Japanese in titles are erroneously italicized in Bookends but not in Sente]). Sente, of course, still has a number of limitations (import and author name problems). I too have raised this issue with Jon, and can understand his reasoning for not implementing unlimited fields, but must say that Sente is in this respect most appealing. I do hope that others who find this feature useful will make this known to Jon.
Kindest regards,
Shayne
P.S. The Bookends forum wins hands down over Sente--most posts are never answered there, but here Jon responds too nearly everything. Keep up the great work Jon.
I see with pleasure Bookends become more robust and steady over time (which contrasts nicely with the mess Endnote has become). Because I value this, I have learned to accept the limited number of available fields. But I agree this is a bit too restrictive. There should be dedicated fields for at least Edition, # of Volumes, and Translator (or else, a couple more user-defined fileds made available for user-defined uses). Besides this, at least a Tertiaty Title field is badly needed: presently one cannot output Series Title in a Book Chapter ref. This means that if I quote, say, a contribution to a volume of the famous Encyclopédie de la Pléiade from Gallimard, I cannot tell readers this is a Pléiade, and not any other Gallimard, book. Since this is unacceptable, I will have to add such cases of Series Title by hand...Luhmann wrote:I think the lack of fields seriously hurts Bookends. Currently the "custom" fields are used for a number of fields that should be fixed fields, and the lack of the additional fields listed above further limits the application. Issues such as loss of information when moving between programs are very serious for me....
Ideally, I would argue for 1:1 parity with EndNotes - offering every field that they have. In addition to the ones listed above the latest version of EndNotes also offers fields for tertiary authors, translators, original language book title and author (for titles that need to appear, say, in both transliterated and original Chinese form), and other very useful fields.
...It just doesn't make sense to me to cripple the program in this way.
Again, let me stress how I value the facts that Bookends actually works, is stable, and improves by leaps and bounds. But I agree that to leave the present number of fields for much longer is unnecessarily crippling. Perhaps the passage to version 9 would be an opportunity to overcome this restriction?
Re: please respond to poll for more fields in Bookends
There hasn't been any action on this topic for a while, but since I have just been looking into it myself again lately I would like to add my voice to the call for more fields.thecritic wrote:Those converting from EndNote to Bookends will have noticed that EndNote has more than twice as many fields as Bookends; the number of fields in Sente is unlimited. Bookends is currently significantly limiting in storing discrete bibliographic information because it offers 19 fields.
...material deleted from quote...
So I ask: how many would like to see the number of fields significantly increased?
To properly implement the style I would like to use, in such a way the data can then be easily used in other styles, more fields are certainly required. I can nearly get the style I want to work by ignoring a couple of the rarest situations and not having a couple of fields I would like. But then, I still have to use every field for bibliographic data apart from keywords and notes. So, even the abstract and isbn fields have to be hijacked to be used for bibliographic data.
I won't go in to all the details, but one of the problems has been mentioned by another reader, that of tertiary title. In the style I use series and multi-volume sets are dealt with differently. So that means you you need a field for the series, seriesNumber (both of which are currently in Bookends), but also the name of the multi-volume set (say, tertiary title) and the volume number. So that is two extra fields already. Add that to the other fields people have mentioned and there are not enough fields.
I'm sure the GUI design issue could be worked around more easily than the large programming effort required to add extra fields. But for what it is worth, I would say this is the most serious reservation I have about Bookends.
-
kvmagruder
- Posts: 9
- Joined: Fri Sep 16, 2005 7:32 pm
- Location: Norman, OK
Example of need for dedicated Translator field?
Hi everyone,
Like you, I love Bookends and have just committed to importing all my references into it, despite the excruciating lack of extra fields (which is its most onerous limitation for my purposes in the humanities). But Bookends' stability, user friendliness, integration with Mellel, etc., make the choice to move to Bookends a no brainer. Kudos to Jon!
I'm trying to compensate for the limited number of fields by setting up extra format types in the Format Manager for such things as Author with Editor; Author with Translator; Author with Editor and Translator; Specific Volume in Multivolume Work; Chapter in Multivolume Work; etc. For example, by putting total volumes in the Volume field and the specific volume in the Issue subfield, it is possible to achieve the reference formats I need by multiplying the number of format types. And I'm doubling up data, delimited by a special code, in fields whenever I need to track some parameter that is not used in references, such as size, language, location, etc. And like many others I've set up a Translator field -- after all, it is not uncommon to cite a work with Authors different from Translators who are different from Editors.
As for importing names into the Translator field, there is another problem: When importing multiple names into Authors or Editors fields, the names are separated by returns, but importing into other fields separates names only by spaces. There is a workaround: I'm importing with a special code ("%/*") inserted between translator names, so that once the references are imported, I can do a Global Change Find and Replace to replace the special code with a return character (option-L).
Here's a problem I haven't figured out a workaround for: There is an Edited book reference type that displays the Editors in the List view if there are no Authors. Here is how the User Guide explains it (p. 127): "When a bibliography is to be sorted by author-date, if a reference has no authors (e.g., an edited book) it will be sorted by its editors. If it has neither authors nor editors (e.g. a reference work, such as a dictionary), it will be sorted by its title."
This is great, but what about a translated book with no editors or authors? What about a Translated book reference type? If my Authors field is empty, the Editors field is empty, and the names are only in the Translator field, then the work is sorted by Title in the List view. Any suggestions? Is there any way to get the Translators to show up in the List view in a Translated book type, just as the Editors show up in the List view in the Edited book type?
PEACE
Kerry
Like you, I love Bookends and have just committed to importing all my references into it, despite the excruciating lack of extra fields (which is its most onerous limitation for my purposes in the humanities). But Bookends' stability, user friendliness, integration with Mellel, etc., make the choice to move to Bookends a no brainer. Kudos to Jon!
I'm trying to compensate for the limited number of fields by setting up extra format types in the Format Manager for such things as Author with Editor; Author with Translator; Author with Editor and Translator; Specific Volume in Multivolume Work; Chapter in Multivolume Work; etc. For example, by putting total volumes in the Volume field and the specific volume in the Issue subfield, it is possible to achieve the reference formats I need by multiplying the number of format types. And I'm doubling up data, delimited by a special code, in fields whenever I need to track some parameter that is not used in references, such as size, language, location, etc. And like many others I've set up a Translator field -- after all, it is not uncommon to cite a work with Authors different from Translators who are different from Editors.
As for importing names into the Translator field, there is another problem: When importing multiple names into Authors or Editors fields, the names are separated by returns, but importing into other fields separates names only by spaces. There is a workaround: I'm importing with a special code ("%/*") inserted between translator names, so that once the references are imported, I can do a Global Change Find and Replace to replace the special code with a return character (option-L).
Here's a problem I haven't figured out a workaround for: There is an Edited book reference type that displays the Editors in the List view if there are no Authors. Here is how the User Guide explains it (p. 127): "When a bibliography is to be sorted by author-date, if a reference has no authors (e.g., an edited book) it will be sorted by its editors. If it has neither authors nor editors (e.g. a reference work, such as a dictionary), it will be sorted by its title."
This is great, but what about a translated book with no editors or authors? What about a Translated book reference type? If my Authors field is empty, the Editors field is empty, and the names are only in the Translator field, then the work is sorted by Title in the List view. Any suggestions? Is there any way to get the Translators to show up in the List view in a Translated book type, just as the Editors show up in the List view in the Edited book type?
PEACE
Kerry
Dear kvmagruder
First things first,
kvmagruder, your little problem with a second line in your translator field does not need to be fixed by a global change in your document. Simply use a hard enter, which is shift+enter.
As to more fields, I personally exclusively use SBL style and Bookends does everything I need it to, but reading this forum (and the competitors extra fields) I can see why it would be an advantage. I myself really like the GUI the way it is, I think more fields would clutter it too much, but it is obviously needed by users. But looking at the GUI, I can see 5 places where fields could be easily added without changing the size. Volume, Publisher, City, URL, and secondary title all only need a single space height showing, so another field could be placed underneath those. I like the compact size of the window and wouldn't want that to change, and the stretchability of the window should be enough to appease those who want to see more. If Bookends were to go with unlimited fields (it sounds so nice, but really, is anyone going to use unlimited fields?) I agree with others that it should be compactible, or perhaps in a drawer of of the Bib window. This would I think appease those who need a zillion windows, and keep those who like the tidiness happy as well.
kvmagruder, your little problem with a second line in your translator field does not need to be fixed by a global change in your document. Simply use a hard enter, which is shift+enter.
As to more fields, I personally exclusively use SBL style and Bookends does everything I need it to, but reading this forum (and the competitors extra fields) I can see why it would be an advantage. I myself really like the GUI the way it is, I think more fields would clutter it too much, but it is obviously needed by users. But looking at the GUI, I can see 5 places where fields could be easily added without changing the size. Volume, Publisher, City, URL, and secondary title all only need a single space height showing, so another field could be placed underneath those. I like the compact size of the window and wouldn't want that to change, and the stretchability of the window should be enough to appease those who want to see more. If Bookends were to go with unlimited fields (it sounds so nice, but really, is anyone going to use unlimited fields?) I agree with others that it should be compactible, or perhaps in a drawer of of the Bib window. This would I think appease those who need a zillion windows, and keep those who like the tidiness happy as well.
~I swore to myself that if I ever got to walk around the room as manager people would laugh as they saw me coming and applaud as I walked away~
-
kvmagruder
- Posts: 9
- Joined: Fri Sep 16, 2005 7:32 pm
- Location: Norman, OK
Hi there Zac,
I agree with your take on the simplicity of the interface. That feature of Bookends is extremely valuable to me, too, so I appreciate your suggestions on adjusting those fields to a single space height which wouldn't clutter it up.
Some way of adjusting tab order between fields would be nice, too, since some user-defined fields (eg Translator) would naturally be entered after Editors, etc.
As for my little problem, a hard enter won't work for me. My global changes are necessary because I will be importing 20,000 references from my current database. I don't want to have to go back and manually inspect each reference; I want to get on with my work. That means I need a Translator field that will accept multiple names on import once for all, and this can be done using some kind of marker for import, followed by a global find and replace. BTW, I found out that finding and replacing the code I indicated above crashes my 8.1.1 copy of Bookends every time (must be a prohibition on symbols like % or something in the replace function), so I've settled on using a code that contains just asterisks and letters.
So if anyone is waiting to switch to Bookends until Bookends is able to import multiple Translator names into a user-defined Translator field, you don't need to wait just for that reason.
Here's another correction to my post above: I've decided I can live without an Author as Translator format. I only had half a dozen such references in my previous database, and that's way too few to worry about.
Hopefully in the next week I'll have all my formats defined and will have verified that I can do the reference formats I need with the user fields as I've set them up, and then finally will be able to import my references. I know I'm going to love actually using Bookends, but setting up Bookends for my needs in the humanities is really, really complicated by the lack of extra fields.
PEACE
Kerry
I agree with your take on the simplicity of the interface. That feature of Bookends is extremely valuable to me, too, so I appreciate your suggestions on adjusting those fields to a single space height which wouldn't clutter it up.
Some way of adjusting tab order between fields would be nice, too, since some user-defined fields (eg Translator) would naturally be entered after Editors, etc.
As for my little problem, a hard enter won't work for me. My global changes are necessary because I will be importing 20,000 references from my current database. I don't want to have to go back and manually inspect each reference; I want to get on with my work. That means I need a Translator field that will accept multiple names on import once for all, and this can be done using some kind of marker for import, followed by a global find and replace. BTW, I found out that finding and replacing the code I indicated above crashes my 8.1.1 copy of Bookends every time (must be a prohibition on symbols like % or something in the replace function), so I've settled on using a code that contains just asterisks and letters.
So if anyone is waiting to switch to Bookends until Bookends is able to import multiple Translator names into a user-defined Translator field, you don't need to wait just for that reason.
Here's another correction to my post above: I've decided I can live without an Author as Translator format. I only had half a dozen such references in my previous database, and that's way too few to worry about.
Hopefully in the next week I'll have all my formats defined and will have verified that I can do the reference formats I need with the user fields as I've set them up, and then finally will be able to import my references. I know I'm going to love actually using Bookends, but setting up Bookends for my needs in the humanities is really, really complicated by the lack of extra fields.
PEACE
Kerry
Bookends shouldn't crash on a find/replace. Please rebuild the database. If it still happens, contact me with details about the find/replace you are doing.
As for multiple items in a single line field -- there is no prohibition against it. You can always see the additional info (and enter it by hand if you want) by clicking on the name of the field to enlarge it.
Jon
Sonny Software
As for multiple items in a single line field -- there is no prohibition against it. You can always see the additional info (and enter it by hand if you want) by clicking on the name of the field to enlarge it.
Jon
Sonny Software