Talk:Providing Lists of Authors

MPDL 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.

=Add Creator List=

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: should be part of 'Easy Submission'.




 * 1) The user pastes his author list via the clipboard into a text area
 * 2) (Optionally, very nice feature for R3.8: user selects one organizational unit to which authors should be affiliated)--Natasa 18:08, 2 June 2008 (CEST)
 * 3) The user clicks "Get Authors"
 * 4) Optionally (if authors were already entered), the system warns upon deletion of existing creators
 * 5) The system parses the author list trying detect automatically the used format.
 * 6) 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.
 * 7) Optionally (if the system selected the wrong format), the user chooses to select a given list format/input format from a dropdown
 * 8) The user clicks on "Get Authors"
 * 9) The system tries to parse the author list with the selected format
 * 10) 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.
 * 11) Optionally (if the system was unable to parse the author list with the given format), an error message is displayed.


 * Questions--Natasa 18:17, 2 June 2008 (CEST):
 * can there be a mixture of formats?
 * in case users use the author-list-field to type manually their authors, each author then in another row in the text area field?
 * why should already entered authors be removed? It will be fine to ask user what she would like to do and whether add at the end or at the beginning of the list.

=Prototype draft=

Prototype Lists of Authors

=Future development (R4)=

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 ).

=Add Creator List III=

After comparing two examples of those lists 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). More lists need to be analysed. Assuming we can not build a nice parser it would look like the picture below. If a parser is applied the first step might look more simple, but we must deal with mismatches later in the GUI. Rupert 10:51, 21 February 2008 (CET)



=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)

Rupert: That would be great! Do we need to define the behaviour? e.g. Is the list shown right from start (placing the cursor into the field) or does it appear after typing at least one letter (that would produce a shorter list). We can also wait until first implementation version and than see ... will be a trinidad or rich faces component. But anyway it will be far better than moving to the tree. --Rupert 13:33, 4 July 2008 (UTC)