Interface Draft: Providing Lists of Authors

The following page is a interface draft for entering lists of authors more comfortable. Please mind that this is a abstract GUI draft. It is not done to define a detailed level but serves as a discussion base for further work.

=R 3.8 Approach=

After comparing lists of authors from different journals they appear to be quite different when taking a more closer look (e.g. Multiple Affiliation Numbers in Footnotes, Family Names divided by blanks like De la Mancha). It turned out that those lists can be parsed to a great extend (Clarified with dev). A first version can be offered without using grid lists.

A new input group :Add Creator List: could be part of 'Easy Submission' and 'Edit Item'.




 * 1) The user pastes his author list via the clipboard into a text area
 * 2) The user clicks "Get Authors"
 * 3) Optionally (if authors were already entered), the system warns upon deletion of existing creators
 * 4) The system parses the author list trying detect automatically the used format.
 * 5) The system displays as many groups "Creators: Persons/Organizations" as authors are detected. The fields of each groups 'Family Name' and 'First Name' are prefilled with recognized names.
 * 6) Optionally (if the system selected the wrong format), the user chooses to select a given list format/input format from a dropdown
 * 7) The user clicks on "Get Authors"
 * 8) The system tries to parse the author list with the selected format
 * 9) The system displays as many groups "Creators: Persons/Organizations" as authors are detected. The fields of each groups 'Family Name' and 'First Name' are prefilled with recognized names.
 * 10) Optionally (if the system was unable to parse the author list with the given format), an error message is displayed.

=R4 Approach=

Preconditions
edit item'
 * 1) If a lot of authors/affiliations need to be displayed it needs to be done with a scrollable list view. The current solution (Creator box) is not efficient. This is not only true for 'edit item' but also for 'view item version' beyond a given threshold.
 * 2) Lists of authors should be available for edit item as well as for create item. If a list of authors is already existing it must not be overwritten by default. Optionally the user besides if the new list overwrites the old one or will be attended below.
 * 3) As the order of entry is sort order by default
 * 4) Creators of type organization are entered manually in '

The edit list provides extended functionality:


 * Change of creator position
 * Add creator list
 * Move Creator (Up/Down)
 * Edit Creator (Inplace)
 * Delete Creator
 * Change position of creator
 * Insert single creator new



Natasa's input
 * maybe possible to keep explicit edit link out, so if the list is always on edit mask, every list item field is by default editable
 * check if the list with would fit in a "normal" witdth of the screen
 * check if for list item actions items vs. text label - what is better
 * new list position only via move up/down

Robert's input: If you require javascript anyway (for in-place editing) i'd recommend implementing sorting via drag-and-drop (see for example http://developer.yahoo.com/yui/examples/dragdrop/dd-reorder.html ).

=Open Questions=


 * Examples show alphabetical sorting in very long author and affiliation lists. The initial requirement was to take those lists in the order, they have been entered into the system by librarians (sorted individually / possible threshold for change of sorting to be figured out)

See example here: Example of a Paper with lots of authors

=Match Affiliations=

Creators are usually linked with one or more affiliations. As a consequence all new entries are matched with organizations (individual organization names are not treated yet). After getting the list, there are one or more creators with no affiliated organization. One or more creators must be matched to one or more organizations in a generic manner.



=Varieties of Lists= Author lists appear in various formats. Luckily Formats with a lot of authors are more unique. A good way may be to start with three or four and support the first early adopter and then evolve/adapt parse algorithm over time.


 * Name1: First Name
 * Name2: Additional First Names
 * Family Names: May contain Blanks (e.g. 'C. Van Den Broeck,8')
 * OrgNr: Footnotes, referring to a list of organizations below.

Current Formats are (Blanks are as displayed):


 * Name1 Name2 NameX FamilyName OrgNr1,OrgNr2,OrgNrX
 * Name1. Name2. NameX. FamilyName,OrgNr1,OrgNr2,OrgNrX

Current Affiliation lists are: OrgNrAffiliation

Collection of additional varieties (not for long lists)

i'd really recommend providing a single text input which can take a list of authors and an algorithm - as smart as possible - to make sense of it (e.g. https://dev.livingreviews.org/projects/epubtk/browser/trunk/ePubTk/refdb/importfilter/bibtex/convert.py line 321 ff). in terms of simplicity that's hard to beat - and from my experience also in terms of usability. typically, the huge author lists come pretty consistently structured, so parsers have a good chance. Robert 18:28, 30 November 2007 (CET)

To test such an algorithm, I would appreciate to have the above samples also as text copied from the original sources. Is that possible? Michael 09:31, 26 February 2008 (CET)

Natasa's comment:
 * Affiliations can be entered by autosuggest (with a flat list, generated from the tree)