Thanks for posting this as it helps me understand why there was so
little discussion of my architectural design process and why I need to
do the conceptual design soon. The OOoBib GUI architectural document
describes "document" as a fundamental object without any mention of the
critical attribute "document type" because I did not plan to use
"document type" as a user selection when setting up a document for
bibliographic inserts.
I went back and researched Open Office again to see where I had missed
the list of types that David has in in email. Even after extensive
research and using OO help, I still have not found that list. Where is
it in the OpenOffice GUI? The user does need to declare a type for each
bibliographic record, but that is a different list and a different use
of type. There is also a "document type" defined by the .suffix for a
file -- again, that is very different from what we are discussing.
At this point, I believe a user needs to be able to use templates for
various types of documents, but I have not connected the use of those
with control of bibliographic insertions. Comments?
Martha
Subject:
Document type lists and document options
From:
David Wilson <[EMAIL PROTECTED]>
Date:
Sun, 22 May 2005 11:23:45 +1000
To:
[email protected]
To:
[email protected]
Some of the problems we have been dealing with the question of mapping the
‘standard’ document types to MODS and how to design a user interface to
collect reference data. I have thinking about how the other Bibliographic
applications use ‘standard’ document types and I think we should try a
different approach for our GUI. Or at least give the users an option to use a
different approach. So I offer these ideas for discussion.
OpenOffice currently supports only the following types - article, book,
booklet, conference, custom1, custom2, custom3, custom4, custom5, email,
inbook, incollection, inproceedings, journal, manual, mastersthesis, misc,
phdthesis, proceedings, techreport, unpublished, www. This is similar to
Bibtex.
Most of the bibliographic packages I have seen start with the process of
‘First select your document type, ..”. This implies that, before you start,
you fully understand the document types, what distinguishes them and what the
bibliographic formatting consequences are or selecting say inbook, as against
incollection. What is the difference in format between a book and booklet
reference ? If you have Honour’s dissertation is it the same as
mastersthesis ?
This process very confusing for a beginner and it still confuses me. Also,
this list presumes that the full range of bibliographic field selection and
ordering is defined by this list, but this is not the case. To provide one
example - If a work is a reprint version of an old well known edition – the
publication details of the original edition may need to cited as well. I had
several of this type in my thesis. If we supported this option with the same
approach, we would have make new types – reprinted Books, reprinted
Articles, reprinted Journals, reprinted phdthesis etc.
Also we do not want the situation where just because a user has entered the
original publication details that this appears automatically in the
bibliography. This should be a user option -
‘Store original Publication details y/n’
‘Display original Publication details y/n’
I suggest a more flexible approach to the user interface, which could also
support a wizard question walk though approach to properly define the
bibliographic attributes.
Rather than have fixed GUI panel design for each of the supported document
types we have either only one (or several more general panels) with more
options. I know that this can result in very large and confusing forms. But I
envisage something flexible and dynamic.
For example the Form could have Radio buttons -
The work has -
Author(s) [_] (or is unknown) [_]
Editor(s) [_]
Compiler(s) [_]
Translator(s) [_]
The Work is -
Part of series [_]
Part of a named edition [_]
A reprint [_]
Part of a collection with works by other authors [_]
And the text entry fields (or a sub-form to collect names) would only appear
when the associated button was selected. (I have seen this in web forms)
I have not fully worked this out but the type of questions / options would
include the following -
Physical character
Audio - talk, music, ...
Video - film, documentary ...
WWW pages
Paper - booklet , book, pamphlet, journal, newspaper, magazine, map, ...
Authorship – The work has one or more authors? has Compiler(s) or Editor(s) ?
Is the work a translation ?
Publisher – Publisher of this work, If it is a re-published (reprint) the
publication details of the original edition as well.
UnPublished – The from in which the work has been referenced ie (Photocopied)
Collections - Does the work have sections with different authors? (Collection
title name, Editor(s) / Compiler(s), publisher, and / or publishing agency,
page range of section referred to.)
Series – Is the work part of a series or collection ? Is the series well known
enough for the series name to be given prominence ? (There may be a different
field order if this is the case). (Series name, Editor(s) publisher, and /
or publishing agency)
Named Edition – Is the work part of a Named Edition ? (Edition name)
Conferences - If the work is an article, report or paper from a the published
proceedings of a conference, the conference details are needed (conference
title, place, date).
Summary
The point I am trying to get to is that the bibliography format should be
generated from the information that the user has provided about the work,
rather than from the user first have to make a selection from a document type
list that is difficulty to fully understand and does not satisfy all the
variation found. For exporting the data some program logic will have to find
a best fit to a document type list. But we should not force the user to deal
with this.
There are many bibliographic details that can be collected when we look
through the style guides. We could collect a list of possible options and
work out how to best to present these to the users. We should think about a
new Bibliographic GUI paradigm for OpenOffice.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
