Martha
--- Begin Message --- Thanks for the comments that are being posted. After discussion with David and Bruce, the deadline date for comments on the GUI architectural design is Friday, March 4th. I will be moving ahead on the conceptual design, so there will be at least two more opportunities for feedback on the GUI design before someone (probably a developer) does the precise layout of each display.
I am finding it interesting to try to mesh the comments on the users and dev lists. For example, I wrote this from the dev message I just received and then looked at the user message that just came in. I have addressed issues raised in the users message here because someone snipped them or wrote to both lists. For example, I commented on someone's snips of Elizabeth's comments and then I read her full comments in the user message. There were additional issues that had not been snipped, so that I also included comments on those at the bottom of this email. Any chance we can somehow consolidate the GUI discussion in a single list?
Comments and clarifications based on the comments so far:
First, let me clarify something: why the distinction between "reference" and "list of references"?
From my perspective, the latter would always be automatically generated, so why would I want to insert a single reference? It seems like it would make the GUI more complicated.
Some documents have two or more 'lists of references': (1) a general bibliography, such as "Recommended Readings," containing information items that are simply inserted in that list and not cited in the document, and (2) a 'works cited' (MLA term) list. By differentiating reference and list of references, OOoBib could handle multiple lists without additional work for the user because citations would automatically go into the 'works cited' list. A user would need to position the cursor in the Bibliography list and insert the references to be included there. Using a 'no cite' option would not work for the (1) type of list as the reference would still go into list (2).
Anyway, in order or priority, I'd say:
citaton and reference list text (you mean stuff like quotes here?)
Yes.
I had a look at the design document. Looks professional, although sometimes aYes, it's abstract because getting feedback at this level prevents my having to do rework of more detailed design. The GUI design will iterate though conceptual and logical design before someone creates the actual displays. Hopefully by then all of the functionality and user task issues will be resolved, leaving only visual layout issues to be addressed.
bit too abstract for my personal liking. Concerning the general concepts I
agree. Issues will probably arise later when things get more detailed and specific.
When saving reference metadata within the document, the user would then need toFor a particular insertion, some of its metadata could be public (usable by others) and some of it could be private (not even viewable by others). It's a separate issue from what subset of metadata is associated with the document. (More discussion of this towards end of this email.)
somehow define whether contents and metadata, metadata only or nothing is
stored with the document. I am not sure I have fully understood the proposed
concept of "private" data, but this probably goes in that direction.
These are exactly the kinds of issues that MUST be resolved for me to do the GUI design. I do not know all the possible alternatives, and it is not appropriate for me to make the functionality decisions. So what shall OOoBib do for Version 1?From the document receiver's point of view this is an important question: He/shecan only integrate those bibliographic data fields into his/her private database that come with the document:
a) If the doc contains (for each reference) metadata, notes and, lets say, abstracts the receiver could store all that in his personal BibDB and use the same snippets etc. in his/her own documents. Furthermore he/she could convert the document to another style guide.
b) If the doc contains (for each reference) only metadata, the receiver could only store this metadata his database. Again he/she could convert the document to another style guide.
c) If the doc contained only very selected fields or, in the extreme case, only the formatted citations and no "raw" metadata at all, the receiver would not be able to get any bibliographic data out of the document and wouldn't be able to apply a new style either (since this might require some other data fields).
What is your opinion about c)? Should this be possible at all? Are there maybe users that might not want their complete used metadata to be shared with the document receivers? Are there alternatives?
So by March 4th would someone please list what goes in the document, what may travel with it but not in it (e.g., the 'private' metadata), etc.?Given the length of abstracts I usually work with (some lines till up to one page) I don't think sending them within the document is a good idea - it might make the document so much larger. Personally I would prefer to store them together with the annotations and other "content" seperately. However, since sharing abstracts might sometimes be useful too, inclucing them into the document should imho be optional - so every user can decide that for him-/herself ... if that is conceptionally possible, of course.
But the GUI designer is one of those who does need this to seriously use OpenOffice. ;-)1) IMHO formatting and formulae in titles, although admittedly useful, are probably currently not one the main priorities.
2) One common (partly) solution for such issues is to allow a html or XML string as the title. This does not allow for complex formulae, but could solve simpler things like "x²", bold or italic formatting.
An alternative that I could imagine if things really NEED to be complicated, is, to allow the OOo Formula editor coding language to be entered as a title. This would solve nearly all formatting problems, although I am pretty sure that 99.9% of the users will not need it. ;-) In this second case an imaginary title could be: "The consequences of " E = m cdot c^2 "for red squirrels (" ital "Sciurus vulgaris"")."
Both alternatives would allow a relatively easy input (for the user), use
already functioning rendering concepts and can store even complex titles as a
simple "String" in the database.
It is my understanding that we are limited to using the "Bibliography Database" menu option to get to the database GUI. I tried to work-around that issue by designing OOoBib user interactions with a separate primary window database GUI so that the user could minimize the open OOoWriter document and interact the database as a stand-alone.First, I take it from the design docs that we propose, in phase one, to only allow access to OoBib from within OoWriter. I would like to urge that we rethink that decision and somehow allow the database GUI to be opened standalone. I have two main reasons for this: 1) I personally very often work with the database of my thesis notes without any reference document in mind, and it wouldn't make sense to me to have to open a document (which I won't use) to get access to those notes. Also because I'm paranoid about my notes, I'd like to be SURE they will be there for me if I have to use another word-processor. I really don't like the feeling of lock-in this proposal gives me.
Yes, the default is selecting a style before the first insertion, and the style is associated with the document so that the user can change the style for the document at any time.In the document GUI "style" element (p9), we say "A style must be selected before the first insertion is made." I think we should have a default style, and the user should then be able to change the style in the document -- in other words, styles shouldn't be fixed for a particular document.
I think the BibDB should contain ALL the information, and that there should be a default setting about what subset is included as the "travelling library" (to borrow an EndNote term) with the document. The travelling library contents should be able to be changed by the author of the document, and the travelling library ought to be able to be exported into a proper BibDB by the reader of the document.
All fine, except the part about "be able to be changed." I think that'd be difficult to manage.
So what shall OOoBib do for Version 1?
This is why I originally thought that there would be only one BibDB with subsets ("Collections") that could be searched and managed separately. If I could import my 'book collector' list of the books I own into a BibDB with the genre folders as subsets, then I could have my ~2000 books already categorized in BibDB and ready to use for reference. That does not even count the articles in various fields that would also need to go into my BibDB. To me, having Collections within BibDB, or even Collections within Libraries within BibDB, is necessary so that I can browse relevant topics without having to limit myself to search results or to be overwhelmed by having to browse 2000+ items. The key distinction is among search, browse and obtain -- research I did at OCLC indicates that all three are critical functionality, particularly for advanced users.
BibDB (p14) - "a major issues is whether a document can contain insertions from more than one BibDB" Yes, please!!!! I have a range of databases more or less categorised by subject (sort of ), and I would like to be able to access them all, not to have to go through some cumbersome cut-and-paste process to be able to insert a reference I already have.
I'm going to throw out a strong contrary opinion, in the interest of debate.
If you have more than one database for different subjects, then this is because your application is not a very good database application. If searching is easy and efficient, and storage robust, why should you need more than one database?
I have 1,500 records (that used to be in Endnote) in an XML database. I often accidentally find stuff I didn't know I needed because the searching functionality is simply much better than in Endnote.
And if you allow more than one database, how are you and your formatting processor going to know where the bibliographic records are?
That's fine, so long as we have both options. In the eXist demo, the simple field is in the sidebar, but there's a link to an "advanced" search interface. That's as it should be. Do you not agree?
Yes.
The mindset is to get the paper done, and if just going to Pubmed to retrieve a reference is simpler than finding a database where it already exists, then that is what they will do. There isn't anything wrong with this approach, but designing the GUI and usage pattern of the software should keep those type users in mind. I think most users of bibliographic software appreciate switching formats, ease of re-ordering references, and easy retrieval of references from public databases. If you put in a Google like search functionality, I am sure it would be a hit! Especially if you could treat it like the Pubmed webpage, where you just stick in the last name and first initials.
This comments reminds me that it is sometimes faster for me to use Google to retrieve something from the web than to walk over and get it from one of my filing cabinets. We definitely need the simple without losing the ability to do the complex (e.g., Google line with advanced search option). I also now find myself sometimes types "site:.edu" into the Google line when I want to limit the results to those from academic sites.
Second, in the Statements of Prupose (p7), we have "Manage retrieved result sets and BibDBs containing information items." I didn't find "Manage" as a key term that was defined, and I would like to know what "managing" entails. Maybe this is clear to others, I just didn't know.
Great question, Elizabeth -- I goofed and did not think to include the explanation. "Manage" is the UI action that covers all allowable actions that will be associated with a particular user concept (e.g., apply, create, view, insert, edit, print, delete, etc.) The term "Manage" is used at this highest UI-design level to allow discussion of critical user concepts and issues without getting into the details of taskflow and layout details (and, besides, the details people are passionate about tend to come up anyway, such as what types of search interfaces to allow). We have many highest-level issues to resolve (e.g., how many databases can be open and/or accessed), so "manage" nicely covers up the issues that we will discuss at the lower levels of design. There is just too much to discuss if we tried to do it all at once -- and the design document I sent would have been at least 100 pages given all of the open issues we have to resolve for detailed design of OOoBib.
Regarding the "private information" debate (p13): I don't like the idea somehow of their being a separate file, and the files having to be in the same directory, and all this stuff. I agree with Bruce (I think it was) that I have lots of stuff I would like to remain private (what I think of my supervisor's writing, for example). I would rather see it like this, though: I think the BibDB should contain ALL the information, and that there should be a default setting about what subset is included as the "travelling library" (to borrow an EndNote term) with the document. The travelling library contents should be able to be changed by the author of the document, and the travelling library ought to be able to be exported into a proper BibDB by the reader of the document. Then we don't have two documents needing to be in the same place at the same time, or any of that stuff: we just have a proper-sized subset that travels with the document and is under the original document author's control. Is that a possible solution?
As I understand it, the BibDB does contain all of the information, but there needs to be some type of information available to the document that distinguishes between what private and private information is associated with it (e.g., the filename and location path for an inserted graphic). If it is just a subset of information defined as a 'traveling library', then the user has no way to get a list of the private information associated with the document (e.g., 'show me the list of filenames for the graphics I have inserted).
It could be a single link back to an item in the BibDB, but that would have to be somehow be both hidden and associated with the document. Thus I think the issue is that there are subsets associated with the document, and some of them are public and some of them are private.
For example, we could define a generic "bibliographic database" search which included author, title, date, and subject, but eliminate subject from databases that don't work that way? This would allow people with specialised databases - let's say chemical engineers - to put in a field for chemical formulae in their specialised molecule database (don't laugh, I read a lot about search engines as that's my topic of PhD research, and there are indeed such databases). This would also allow for a more modular way of extending the database.
No laughter -- I am very familiar with those kinds of specialized needs and they are very real! The GUI can include whatever functionality the developers tell me is supported.
Thanks, Julian! I had not yet seen the beta of this and it looks really interesting.Have you guys tried Google Scholar? (http://scholar.google.com). I have come to depend on it for finding published references quickly - much more quickly than using any other bibliographic search services, or indeed than my locally installed bibliographic database (which has all the refs I need). It links to the academic publishers where you can get access to full papers.
Julian
Thanks for all the great comments so far! Martha
--- End Message ---
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
