On Nov 22, 2005, at 12:22 PM, [EMAIL PROTECTED] wrote:
First, it seems to me that this is the same issue we have been
discussing in terms of grouping the bibliographic entries in a
document as different types of reference lists (e.g., General
Bibliography, Works Cited, Recommended Readings). The question is
whether we would need to be able to nest groups within groups--for
example, the "Works Cited" group might include one subgroup as
"Primary Sources" and another subgroup as "Secondary Sources".
Ouch. I guess that is worth considering, though obviously adds
complexity all around.
Unless I am missing something (which is quite possible), the GUI would
allow the user to identify the reference groups for a document and the
entries that go within each group.
Yes.
Somehow the engine would be able to keep track of that, but the larger
programming question is whether the knowledge of groups are restricted
to a document or becomes part of the bibliographic item--i.e., which
is the fundamental object and what points to what?
Right. I think David has more to say on this.
The primary UI tradeoff issue is user control versus automation.
Yes.
Because we do not yet know all of the issues and how people might use
the functionality, I am strongly for an emphasis on user
control--automation that does something other than what the user wants
is a diabolical form of torture, especially when it cannot be
overridden or, worse, when it can be overridden but the overrides are
not stored.
Agreed.
If the group knowledge is constrained to the document because the
document is fundamental, then group names such as "Recommended
Readings" or "Works Cited" could be stored as heading text with the
other bibliographic data for the document. The user could type in
other group names (e.g., "Primary Sources" and "Secondary Sources")
and insert the bibliographic entry under that heading--the point of
insertion would be identified by the location of the text cursor.
This approach gives the user the greatest control in that the entire
"Bibliographic Section" of the document could be stored as a whole and
changed at will by the user without being constrained to 'messing
with' the bibliographic database. It would also solve another problem
if a user wanted to change or annotate an entry just for one document.
Yeah, I'm not sure if we're on the same page, but in coming up with my
XML approach to this, I was basically thinking that there'd be a little
config panel for this. So user would add a group. Then, if they needed
to manually assign references to groups, there'd be a list of included
references, with maybe a pop-up to choose the group.
Wait ...
On the other hand, if the focus is on automation rather than user
control, the knowledge of groups would be associated with the
bibliographic item as fundamental. Every item in the database would
have to know every group that had ever included it, and the groups
used for all other documents, and allow for the entry of new groups.
In this GUI, the user would select a database item and changing its
group heading from the generic default would be among the advanced
decisions to be made for an inclusion. The basic option would be the
default. The system automatically would put the entry in the
appropriate sequence under the group and the position of the text
cursor would be irrelevant. If the group did not already exist in the
document (i.e., that had been a previous inclusion under that group
name), then the system would automatically add the new group to the
document. This is where the nested issue becomes dominant--what if
the new group is "Secondary Sources" under the higher-level "Works
Cited" group -- how would the system know how to order the subgroup
sequence?
Where David and I were headed was somewhere between. Example: a "see
also" reference (e.g. not cited, but list in the bib) cannot be a
property of the reference item per se, but rather of its connection to
the document.
Also, this is a perfect example of how developer terminology often
migrates to the UI without consideration of the underlying assumptions
from the users' perspective. Is "group" actually the best word for
the name of a type of reference list? Or would "Reference List" be a
better term as it contains within it the definition of what it is?
Consider the following user statements:
1. "I want to add a new group to the document." [note that this
statement carries no intrinsic information about what is being added]
2. "I want to add a new reference list to the document."
Or perhaps there are even better alternatives for this user concept
that I have not yet identified.
I'm open to suggestions. When *I* think it, I think "I need to divide
my reference list ito sections." I don't think of it as more than one
reference list. Also, FWIW, the TeX package that does this sort of
thing is called multibib.
The precise details of all this are not critical to work out now,
except to the degree they effect the design of CSL. I just always try
to think about the end-user experience and GUI design when I work out
these details in the XML.
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
