Build an OpenURL form

[jonearley]

Replace 360link version with a simple JS form

[jonearley]

[jonearley]

We should get some librarian eyes on this to make sure I include the appropriate fields.

What are the minimum fields required to get an accurate citation link? What additional fields should we add and why?

[varnum]

I think it needs to have the same fields as the current MGet It
http://mgetit.lib.umich.edu.proxy.lib.umich.edu/?SS_Page=refiner&SS_RefinerEditable=yes
link
on our site for both journals and books.

On the journals page, there need to be a field for article title, and the
surname, first name, full name and corporate name of the authors (those are
all treated differently in an OpenURL). A genre menu is also important.

Ken Varnum
Senior Program Manager for Discovery, Delivery, and Library Analytics
Library Information Technology | University of Michigan Library
varnum@umich.edu | @varnum | 734-615-3287
http://www.lib.umich.edu/users/varnum

On Tue, Sep 13, 2016 at 2:45 PM, Jon Earley notifications@github.com
wrote:

We should get some librarian eyes on this to make sure I include the
appropriate fields.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#30 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQ7bL6fWojB0WGH9m4ri28vWJ43uTLEhks5qpu8xgaJpZM4JqOYq
.

[jonearley]

That's a good start.

I notice when searching for citation linkers they are all a bit different. I wonder why? I would like to explore what fields are most important and makes the most sense to use. Maybe we can start a document to track what fields to include, it's importance and why.

The hope to examine this is to make the form as simple as possible and improves usability. And help my understanding of the function of the form.

[varnum]

Here's an Analytics report showing the OpenURLs generated by people who use the form. Note that this includes people who used the "edit citation" link in the current interface (which we no longer offer).

Analytics MGet It Content Drilldown 20160701-20160913-2.xlsx

[jonearley]

http://nj.oclc.org/1cate/ig.html
http://nj.oclc.org/1cate/igbook.html

This is the best guide I've found to implementing an OpenURL I've come across. I'll follow this to help build the form.

[bertrama]

If you have questions beyond that, here's the full OpenURL spec.

[bertrama]

Some questions I don't think we've talked about @varnum @jonearley:

• What path will this live at in the application?
• Will it take an OpenURL as input for refinement?

[varnum]

Where it lives -- I think it ought to have a friendly URL, like mgetit.lib.umich.edu/citation-linker

Will it take an OpenURL -- We currently don't have a "refine the original citation" feature in our interface (it exists in the current native one). Was this intentional, @bnhowell and @Treevore ?

[bnhowell]

@varnum Can you describe the use case for the "refine the original
citation" feature in the citation linker page? Would a "clear fields"
feature to re-enter metadata help? Not sure why a user needs an interface
feature to refine original citation.

It would be best to have clear error messages, required fields to prevent
errors (I realize this is very difficult for the broad range of
possible citation metadata). When we redesigned the citation linker, the
form had unique entry fields by resource type (book, article, journal,
patent, dissertation, etc.).

On Thursday, September 15, 2016, Ken Varnum notifications@github.com
wrote:

Where it lives -- I think it ought to have a friendly URL, like
mgetit.lib.umich.edu/citation-linker

Will it take an OpenURL -- We currently don't have a "refine the original
citation" feature in our interface (it exists in the current native one).
Was this intentional, @bnhowell https://github.com/bnhowell and
@Treevore https://github.com/Treevore ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQBqv31bVUA-M9id6R0mjEH_SYeBehEVks5qqXh5gaJpZM4JqOYq
.

Ben Howell | Accessibility & User Experience Specialist
Design & Discovery | LIT | University of Michigan Library
bnhowell@gmail.com

[jonearley]

The "refine the original citation" feature was removed to keep things
simple. This keeps the focus on the core purpose of the page. I like to
think this approach helps make the page easy to use. And with Ben's recent
user testing the page has so far been easy to use for people, even if they
have never used the library website before.

There are cases for adding features, but I think it's in the best interest
of users to keep things minimal and focused.

On Thu, Sep 15, 2016 at 12:55 PM, Ken Varnum notifications@github.com
wrote:

Where it lives -- I think it ought to have a friendly URL, like
mgetit.lib.umich.edu/citation-linker

Will it take an OpenURL -- We currently don't have a "refine the original
citation" feature in our interface (it exists in the current native one).
Was this intentional, @bnhowell https://github.com/bnhowell and
@Treevore https://github.com/Treevore ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABmdSfeUth1wgapHk0diK3LchEhi1NYtks5qqXh5gaJpZM4JqOYq
.

Jon Earley
Interface Developer for Design and Discovery
University of Michigan Library

I check email once a day, M-F

[bnhowell]

I misunderstood where this issue was. I thought you were referring to the
Citation Linker page.

I agree with Jon, that we keep the interface on the impact side of design.

On the link resolver page I have only observed people click the
browser back button to revise their citation from their search results
page. If they were referred from the citation linker page they also clicked
the browser back button.

On Thursday, September 15, 2016, Jon Earley notifications@github.com
wrote:

The "refine the original citation" feature was removed to keep things
simple. This keeps the focus on the core purpose of the page. I like to
think this approach helps make the page easy to use. And with Ben's recent
user testing the page has so far been easy to use for people, even if they
have never used the library website before.

There are cases for adding features, but I think it's in the best interest
of users to keep things minimal and focused.

On Thu, Sep 15, 2016 at 12:55 PM, Ken Varnum <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

Where it lives -- I think it ought to have a friendly URL, like
mgetit.lib.umich.edu/citation-linker

Will it take an OpenURL -- We currently don't have a "refine the original
citation" feature in our interface (it exists in the current native one).
Was this intentional, @bnhowell https://github.com/bnhowell and
@Treevore https://github.com/Treevore ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
ABmdSfeUth1wgapHk0diK3LchEhi1NYtks5qqXh5gaJpZM4JqOYq>
.

Jon Earley
Interface Developer for Design and Discovery
University of Michigan Library

I check email once a day, M-F

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQBqvySC0-vD1HiCM9rivYEwVQP21u6Mks5qqX0YgaJpZM4JqOYq
.

Ben Howell | Accessibility & User Experience Specialist
Design & Discovery | LIT | University of Michigan Library
bnhowell@gmail.com

[varnum]

So there are two contexts:

1. A user starts with an MGet It button in ArticlesPlus or a 3rd party source. This is the most common route. Here, I agree, a refine citation button is probably not that useful; if the go to item link is broken, reporting it as a problem is probably the best route.

2. A user starts with the citation linker form and enters data for one or more fields of the citation. If it results in a successful OpenURL that can lead to full text, the user can click the button. If not, they have the back button and can get to the form and change what they entered. It maybe be helpful to include a prompt in the interface for users who come from the citation linker to remind them to go back and edit the citation if they think it's possible they entered something problematic (a typo in publication year or journal title, the wrong ISSN, etc.). But as long as the back button works, I don't think is is required, either.

[jonearley]

An example form for an Article. Above you would choose either Journal Article or Book and then the form would change.

[varnum]

I think this looks good. A few labeling suggestions:

1. Write "Date" as "Publication Date"
2. Expand "Corp" to "Corporate" as the 4th field in Author.
3. Bundle the ISSN / DOI / PMID under a bolded heading like "Standard Identifier"

[jonearley]

@varnum thank you! How's this? I also updated the input field styling that closer matches @Treevore's designs. It's easier on the eyes and looks nicer now (in my opinion).

[varnum]

Looks good. Is the style of the toggle buttons (Journal Article / Book) in keeping with Trevor's templates? They look at a bit Windows 95-y.

"Corporation" should be "Corporate".

[jonearley]

Yeah, they are the more neutral looking buttons.

[bnhowell]

+1 for @jonearley leaving out the "Genre" drop down menu that we currently have in the citation linker page. I know there was discussion and some questioning about the genre dropdown in previous PARC meetings. (@varnum maybe you remember this?)

[jonearley]

You'll have to refresh my memory on the genre dropdown. It's missing from the form here without any real reason on my end.

[varnum]

The genre is theoretically important to distinguish the kind of article, and if there were multiple items with the same title and author but no identifier provided, might help 360 Link get to the right one.

In practice, I think it's more helpful for Ask a Librarian staff for troubleshooting

The only place in PARC minutes I could find genre referenced was in the 4 November 2015 meeting, when we were talking about the previous re-skinning of the 360 Link native interface. There, it was simply pointed out that, "Looking at “Genre”, it looks repetitive, but helps to refine the search. It is there for (1) article/journal and (2) book". A copy of those minutes is attached.
Public+Access+Resources+Committee%C2%A0Meeting+2015-11-04.docx

[bnhowell]

@jonearley Genre screenshot here:

[bnhowell]

@jonearley What if we had something like this for the format and genre (if we decide we need it) selection: (we could place genre selection at the bottom of the form and indicate it's optional if this is a feature primarily used by librarians)

[jonearley]

https://github.com/mlibrary/openurlform

[varnum]

Is this available on dev or earleyj for testing?

[jonearley]

I have the UI version here: http://earleyj.www.lib.umich.edu/openurlform/. Although it doesn't generate the OpenURL yet. I'm still coding that part and hope to have it ready to test this week.

[varnum]

Great! I think it could use a bit of testing, when it's generating actual OpenURLs (we can start with committee, and probably Pam MacKintosh).

[jonearley]

The form is functioning and generating OpenURLs. I sent an email to the link resolver project group for feedback.

[jonearley]

Seems we have some refinement to do after receiving feedback from the group. I'm going to create issues over at https://github.com/mlibrary/openurlform to track.

[jonearley]

@varnum do you think it would be OK to close this issue? I think any more feedback coming in could be tracked at the openurlform repo. We've address the major issues and I believe this form is ready for use.

[varnum]

Yes, sure.

On Thursday, October 13, 2016, Jon Earley notifications@github.com wrote:

@varnum https://github.com/varnum do you think it would be OK to close
this ticket? I think any more feedback coming in could be tracked at the
openurlform repo.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQ7bL-viex08W_3TNrJyXt-gAAKd_P8wks5qzpEAgaJpZM4JqOYq
.

Ken Varnum
Senior Program Manager for Discovery, Delivery, and Library Analytics
Library Information Technology | University of Michigan Library
varnum@umich.edu | @varnum | 734-615-3287
http://www.lib.umich.edu/users/varnum