ACIS project / stage 3 /
Number one thing in whole EPrints/ACIS cooperation is to have a compatible metadata format. Given such format ACIS could use EPrints-produced data for its documents database. AMF is supposed to be such metadata format, but users don't care which format is used.
Number two thing is to allow personal identifiers in the author data (creator data) in EPrints. Personal identifier input field may or may not be visible to a user submitting a document. It probably shall be an EPrints option, whether to show such field or not. But if it is shown and used, the identifier must be saved into the EPrints-produced metadata.
Number three thing is to help user to find particular person (author) and include his identifier into document data. Given previous steps are completed, that will already be a great level of cooperation between EPrints and ACIS. Because ACIS will notice the personal identifier in document data and ACIS' ARPU will automatically include the document into the author's profile.
It is important that we minimize user errors at this stage. If many EPrints users start assigning documents to wrong persons, it would cause bad metadata and lower people trust in the both services.
And then number four thing is to make ACIS react to EPrints submissions quickly -- through metadata processing request.
Of these four things only two have something to do with user interface. In 2nd thing it is pretty trivial -- add an identifier input field to the other author information input fields. Let's now look at possible user interface strategy in 3rd thing.
Submitting a document to an EPrints archive is a pretty complicated process. Not because it is physically difficult, but because it involves several steps and each step takes time and effort. We want to add more to this process -- to let user identify the person(s), he is mentioning in document description. First, we want to do that in the least obtrusive way. Second, we want to touch as little as possible existing EPrints code. We want the feature to be additional to EPrints. Its best to leave the general user-EPrints workflow as it is, just adding little hooks for us and then hang all our code on these hooks.
XMLHTTPRequest is a funny piece of browser technology, bacame widely known just recently. It allows for such applications as a web page in a browser that communicates with a server, and then modifies the page based on what server returned.
Here are some examples. Google Suggest
Meetup.com registration form. Choose a country and see how a page reacts -- it loads a list of cities from the server.
You wonder about technical accessibility? It works in Internet Explorer 5.0 and higher, in Mozilla 1.0+ and FireFox; Safari 1.2+. It does not work in Opera, but Opera developers plan to implement it in the future.
We can use it for AIDA.
Second screen of creating a "deposit" sequence in EPrints looks like this:
In the lower part of the screenshot we see author (creator) information entry fields.
Let's look at a simpliest user scenario. User enters first author family name and then goes to the next input field -- Given name/Initials.
At this point script in the page sends a query to find personal records with such family name. Server executes an SQL query and formats result as XML. Page script gets this XML data, a list of persons. Based on this data, script constructs a menu of these personal records and includes it into the page.
Then user may click on any of the suggested personal names and it will mean he made a choice. Script will then fill out the Family and Given name fields and personal identifier field. Other links ("profile", "homepage") may help the user to find more information about the person in question.
On these screenshots there's no personal identifier input field. But it doesn't mean there can't be a hidden input field in the form. It is an important question, but not critical to things I'm trying to show. Bottom line is that for every person in the menu we know his shortid. If submitting user chose a person from menu, this person's shortid must be saved into the author/creator metadata.
After a choice, person menu is removed.
If user does not make a choice, but instead continues to enter author name details, e.g. Given name, we may refine the menu based on what user enters.
If user returns back to the Family name box, and edits its value, we re-execute the query back with new family name and then again display the menu, based on the response we get.
Other scenarios of user behaviour are certainly possible. As we have author email input box in EPrints, user can use that to identify the person. If user entered email address but nothing else, we check that email address and offer a menu based on this. Similarly with shortid input field, if we make it visible.
That's briefly how I suggest to make the interfrace.
There is a number of questions still left.
Is there a better way to present a menu of choices to the user? Something less confusing?
Shall we display a shortid input field for every author?
Shall we list persons' shortids in the menu?
How can user undo his menu choice?
Shall we get and show more information about the person in the menu to lessen chance of user mistake? For instance, shall we also display person's affiliation? That would probably make chance of mistake very low, but will clutter screen.
What to do when there's a lot of personal records matching to a family name? Shall we display a list of 15 items? Of 25 items?