Closed jonearley closed 8 years ago
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?
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 https://github.com/mlibrary/mgetit/issues/30#issuecomment-246782690, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ7bL6fWojB0WGH9m4ri28vWJ43uTLEhks5qpu8xgaJpZM4JqOYq .
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.
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
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.
If you have questions beyond that, here's the full OpenURL spec.
Some questions I don't think we've talked about @varnum @jonearley:
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 ?
@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 https://github.com/mlibrary/mgetit/issues/30#issuecomment-247386205, 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
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 https://github.com/mlibrary/mgetit/issues/30#issuecomment-247386205, 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
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 https://github.com/mlibrary/mgetit/issues/30#issuecomment-247386205, 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 https://github.com/mlibrary/mgetit/issues/30#issuecomment-247391763, 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
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.
An example form for an Article. Above you would choose either Journal Article or Book and then the form would change.
I think this looks good. A few labeling suggestions:
@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).
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".
Yeah, they are the more neutral looking buttons.
+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?)
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.
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
@jonearley Genre screenshot here:
@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)
Is this available on dev or earleyj for testing?
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.
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).
The form is functioning and generating OpenURLs. I sent an email to the link resolver project group for feedback.
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.
@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.
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 https://github.com/mlibrary/mgetit/issues/30#issuecomment-253625493, 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
Replace 360link version with a simple JS form