When do you show your Umlaut screens?

[Ken Varnum]

My question is, when you implemented Umlaut, and you had a direct-to-full-text process with your previous interface, what were your users' reactions? Did anyone care about getting a "speed bump" page all the time, rather than only when the origin link was poor quality or was to a target your library doesn't license?

Some background.... We're working on implementing Umlaut, finally. We currently have 360 Link and have turned on their "direct linking" feature -- which means that when the library has configured a target to be a direct linking target, the user bypasses the 360 Link menu screen and goes right to the full text. Similarly, when there is a direct link from Summon to full text (an Index Enhanced Direct Link) is available, we bypass the link resolver screen and go right to the full text.

As we work on Umlaut, we're wondering about bypassing the Umlaut screen when there's an IEDL or a 360 Link Direct Link, and only showing the menu when there's no probably full text. There's some concern among public service librarians that changing the user experience will be troubling for our users.

[Ross Singer]

Hi Ken,

I'd argue that the answer is probably dependent on what services you are offering in Umlaut and if they really provide any value above and beyond the link to full-text.  That's where Umlaut's UX is a little hard to compare 1:1 to something like 360Link, which provides very few useful contextual offerings besides getting the user to fulltext.  On the other hand, I think you could argue that a library that had SFX + bX (as a somewhat common example) would do their users at least a partial disservice if they linked directly to the 'best' fulltext provider (for this argument, let's set aside whether or not the actuals recommendations in bX are helpful).

I guess that's the justification that needs to be made: for a given request, is Umlaut going to provide enough benefit to enough users for the incoming request to display, or are you better off getting to the thing they think they want?  It's tough to give a blanket answer to this question since it's a fairly complicated matrix of request resources, context services, and fulfillment options.  

If your Umlaut is really only set up to help the user get the specific thing they're looking for (that is, a better user interface to the traditional link resolver role) then I would say to bypass the menu and get the user to the resource.  If your Umlaut provides other kinds of services (recommendations being the easiest for me to articulate off the top of my head) rather than being a de facto splash page (in this context) then it's possible that your users won't find the resolver menu to be quite as annoying of a step.

I'll be interested to know what you decide on.

-Ross.

--
You received this message because you are subscribed to the Google Groups "Umlaut" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlaut-softwa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.