I don't know why you say that. Each time we add a field there is a cost. There is the cost of db size (each empty field requires a certain set-aside, which is not negligible). And each field requires a mechanism for import/export, which is not a trivial consideraton in maintaining the interface. Nothing comes without a cost. I have seen justification for 10-12 new fields, a number that would seem satisfactory even in extreme cases.
This is one danger, I'm afraid, about being so open about development, and one reason that developers don't usually discuss future plans with their users in such detail—you can't please everyone. Suggestions are welcome and of course they are taken seriously, as I hope my participation in the discussion has made clear. This thead has been helpful, but I think it may have run its course.
Jon
Sonny Software
GUI and more fields- a discussion
Fair enough, all good things must come to an end 
Just for the record, the previous poster doesn't speak for the majority. If Jon wasn't taking us seriously he wouldn't be as open about further development and he wouldn't have been as active in this thread as he was.
For those who think that 12 additional fields is not enough and more are needed, provide an actual example. I think Jon is justified in saying that this thread showed 10-12 fields to be a good additional amount. But are there citations that need more than thirty fields that you use? If so, tell us, that was one of my first requests in starting this thread. If you have a legitimate citation type that takes up 30 fields and leaves you no room for keywords, notes, abstracts, etc., then I'm sure Jon would reconsider. As of right now, no one has.
ttfn
Just for the record, the previous poster doesn't speak for the majority. If Jon wasn't taking us seriously he wouldn't be as open about further development and he wouldn't have been as active in this thread as he was.
For those who think that 12 additional fields is not enough and more are needed, provide an actual example. I think Jon is justified in saying that this thread showed 10-12 fields to be a good additional amount. But are there citations that need more than thirty fields that you use? If so, tell us, that was one of my first requests in starting this thread. If you have a legitimate citation type that takes up 30 fields and leaves you no room for keywords, notes, abstracts, etc., then I'm sure Jon would reconsider. As of right now, no one has.
ttfn
~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~
This is a very long thread and I'm sorry but I didn't read all of it. But I just wanted to add my 2 cents:
1. I bought Bookends recently but have not started using it.
2. why? i really need a notes field and a call number field to finally switch from endnote. i bought it hoping those will come soon.
3. Under another hat, I am the developer of an old bit of software called PocketCites, which imported EndNotes records into FileMaker for sync with Palm via FM Sync or FileMaker Mobile. I haven't updated it in ages, and in fact stopped using it myself once EndNote included their own Palm Conduit, but I would be interested in updating it for BookEnds when the field support grows and/or AppleScript support is included.
1. I bought Bookends recently but have not started using it.
2. why? i really need a notes field and a call number field to finally switch from endnote. i bought it hoping those will come soon.
3. Under another hat, I am the developer of an old bit of software called PocketCites, which imported EndNotes records into FileMaker for sync with Palm via FM Sync or FileMaker Mobile. I haven't updated it in ages, and in fact stopped using it myself once EndNote included their own Palm Conduit, but I would be interested in updating it for BookEnds when the field support grows and/or AppleScript support is included.
Hi Lobster,
1. There is a Notes field (and an editable Notes pane in the List View Info Drawer).
2. More fields are coming. I can't say just when, but they are.
3. We don't have plans on making Bookends scriptable, but we will work with other developers to allow direct AppleEvent communication if it seems useful.
Jon
Sonny Software
1. There is a Notes field (and an editable Notes pane in the List View Info Drawer).
2. More fields are coming. I can't say just when, but they are.
3. We don't have plans on making Bookends scriptable, but we will work with other developers to allow direct AppleEvent communication if it seems useful.
Jon
Sonny Software
BTW, to those who have contributed to this thread, you can email me directly if you want to discuss the default values for new fields that will be added (as a function of reference Type): support@sonnysoftware.com
Jon
Sonny Software
Jon
Sonny Software
Does a 'Date added' field seem like a good idea to anyone? It should be automatically filled with the date when the reference is created -- in Bookends sortable format, of course: yyyy-mm-dd.
Then we could create Smart Groups like 'Recently added', 'Added in December 2004', 'Added one year ago today' etc., and also sort the list view in date added order (or better yet, reverse date added order, so that recently added references are at the top).
(If there's already a way to do this kind of thing and I've missed it, I apologise... I know about Refs > Insert Date, but that has two drawbacks: (1) it's not automatic, so it takes extra time and I don't remember to do it; (2) it inserts the date in the format specified in System Preferences, which is no good for sorting on.)
Nick
Then we could create Smart Groups like 'Recently added', 'Added in December 2004', 'Added one year ago today' etc., and also sort the list view in date added order (or better yet, reverse date added order, so that recently added references are at the top).
(If there's already a way to do this kind of thing and I've missed it, I apologise... I know about Refs > Insert Date, but that has two drawbacks: (1) it's not automatic, so it takes extra time and I don't remember to do it; (2) it inserts the date in the format specified in System Preferences, which is no good for sorting on.)
Nick
You can do that now. The reference number (not the unique id) reflects the date added. You can have a column showing this number (as of 8.1.3) and sort on that (ascending or descending). Alternatively, you can choose not to have the List View sorted (as default, in Preferences), in which case it will always open with the list in the order added, ascending.nicka wrote:and also sort the list view in date added order (or better yet, reverse date added order, so that recently added references are at the top)
Jon
Sonny Software
Many thanks for the quick reply Jon. It's great that this is possible.The reference number (not the unique id) reflects the date added. You can have a column showing this number (as of 8.1.3) and sort on that (ascending or descending). Alternatively, you can choose not to have the List View sorted (as default, in Preferences), in which case it will always open with the list in the order added, ascending.
I think it would be even better to have the actual date a reference is entered kept automatically with the reference, though. That's just my opinion about what extra fields I would find useful, of course, and perhaps this isn't important to others.
Nick
You still wouldn't be able to sort by date, unless it was
05/12/01
because sorts in Bookends are alphanumeric (except unique id and reference number).
You will certainly be able to assign a "date entered" field in the future if you like, but you'll have to enter the date as above if you want to sort by it.
BTW, don't forget the handy Command-' combo. It copies the data from the same field in the previous reference. So you only need to enter the date once per day, and them Command-' in that field for every new reference you add. Even the next day you can do this, and just change the last digit (until the end of the month/year, that is).
Jon
Sonny Software
05/12/01
because sorts in Bookends are alphanumeric (except unique id and reference number).
You will certainly be able to assign a "date entered" field in the future if you like, but you'll have to enter the date as above if you want to sort by it.
BTW, don't forget the handy Command-' combo. It copies the data from the same field in the previous reference. So you only need to enter the date once per day, and them Command-' in that field for every new reference you add. Even the next day you can do this, and just change the last digit (until the end of the month/year, that is).
Jon
Sonny Software
Thanks for the clarifications and suggestions.You still wouldn't be able to sort by date, unless it was
05/12/01
because sorts in Bookends are alphanumeric (except unique id and reference number).
You will certainly be able to assign a "date entered" field in the future if you like, but you'll have to enter the date as above if you want to sort by it.
BTW, don't forget the handy Command-' combo. It copies the data from the same field in the previous reference. So you only need to enter the date once per day, and them Command-' in that field for every new reference you add. Even the next day you can do this, and just change the last digit (until the end of the month/year, that is).
I guess what I want is for Bookends to just take care of all this for me, automatically keeping track of when references enter the database and allowing sorting and searching on that data set. If I have to remember to enter the date myself, I will forget at some point, and then the data set will be incomplete, so searches on it would be much less useful.
Whether setting all this up is worth your time and trouble is another question, I understand.
A small suggestion to make it a little easier to enter sortable dates: How about making it possible for Ref > Insert Date to insert a date in a format that can be sorted on, like yyyy-mm-dd? (You could have a preference for whether it inserts in this format or in the date format specified in System Preferences.)
Nick
(Sorry to readers of this thread that this discussion is now a bit off-topic, by the way.)
I'll think about that.nicka wrote:A small suggestion to make it a little easier to enter sortable dates: How about making it possible for Ref > Insert Date to insert a date in a format that can be sorted on, like yyyy-mm-dd? (You could have a preference for whether it inserts in this format or in the date format specified in System Preferences.)
Jon
Sonny Software
For those interested, here is a list of new fields being considered (some are reference Type-specific, of course).
Call Number
ISSN
Language
Ser Editor (Series Editor)
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 Title (Multiple Volume Title): In a multiple volume work, the title of the volume.
Vol # (Multiple Volume Number): In a multiple volume work, the number of the volume being cited.
Jon
Sonny Software
Call Number
ISSN
Language
Ser Editor (Series Editor)
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 Title (Multiple Volume Title): In a multiple volume work, the title of the volume.
Vol # (Multiple Volume Number): In a multiple volume work, the number of the volume being cited.
Jon
Sonny Software
I assume that ISSN means here "ISBN/ISSN"?Jon wrote:For those interested, here is a list of new fields being considered (some are reference Type-specific, of course).
Call Number
ISSN...
# of Vols (Number of Volumes): The number of volumes in a multiple volume work.
Vol Title (Multiple Volume Title): In a multiple volume work, the title of the volume.
Vol # (Multiple Volume Number): In a multiple volume work, the number of the volume being cited.
Jon
Sonny Software
The volume-related fields are very much welcome!
TH
I would say yes -- this is really the same data, mapped to different reference types.Jon wrote:No, currently User4 is already used for ISBN in Book-related Types. For backwards compatibility, I had not planned to map that anywhere else.tharpold wrote:I assume that ISSN means here "ISBN/ISSN"?
Hm, maybe I should...
Jon
Sonny Software
TH