Remember the poor off-campus user

Many of our systems have different click flows for on and off campus users — often requiring some authentication step for off campus users.

At most universities, most of our patrons use is from ‘off-campus’.  But most staff use is from ‘on-campus’.

This can lead to staff not being cognizant of, or highly attentive to, usability problems with off-campus click flows.

On vs Off Campus

Like most university libraries, we offer a variety of third-party licensed services, which are only available to those affiliated with our institution.

Like many universities, the result of this is that for users from recognized on-campus IP addresses, they can use these services without having to log in (since the licenses generally includes local use regardless of individual affiliation, and/or because those on the local network are generally neccesarily affiliated (or this is considered sufficiently diligent security, at any rate)).

But users at off-campus IP addresses have to authenticate themselves somehow. Whether when going through EZProxy or for local apps, and usually either way via some campus-wide single-sign-on system.

However, most universities if they try to check their logs or survey users, will probably find that the majority of patron use is actually from off-campus locations. Users like to work from home, or from coffee shops, from their mobile devices out in the world (or over a cellular network that’s ‘off campus’ even when physically located on campus), etc. If not a majority, it’s probably a very significant minority, and only going up.

At our particular university, this is exacerbated by the way our wireless network may put some people even physically on-campus at an ‘off campus’ IP location.  Our central IT has a main wireless network all over campus which requires authentication to connect to, and which is considered ‘on campus’.  But they also offer a ‘guest’ wireless network which requires no authentication, and thus must be — in our current interpretation of following our licenses — considered ‘off campus’ for purposes of determining affiliation.  Many patrons use the guest network (even though it’s slower), because they find the authentication process for the official network troublesome, and thus show up as ‘off campus’ to our system.  Further increasing the amount of patron use that goes through ‘off campus’ (authentication required) click flow.

But staff use is almost entirely on-campus

Of course, most library staff do their jobs on-campus, at recognized on-campus IPs.  Sure, some library staff might occasionally work from home, or do personal research using library systems from home. But on the whole, staff usage is predominantly ‘on campus’.

This means that most staff — systems, reference, everybody — seldom even sees the off-campus click flow.

This can result in being insufficiently attentive to inconveniences in the off-campus click flows.  Sure, we, like everyone, try to get as much information directly from users as possible (usability testing (but do you ever do your usability testing with off-campus click flow?!?), surveys, focus groups, direct feedback, etc.)   But staff users are still an invaluable proxy for end-users, and a lot of what we know about when our systems have usability problems come from ourselves. Systems staff try out their systems on a regular basis, and note any obvious barriers or inconveniences, and come up with ideas for improvements. Reference and other staff use our systems themselves on a daily basis, and if they encounter inconveniences or inefficiencies in the UI themselves, or note things that are going to be problems or time-wasters for users, they surely let us know.

But none of these people are hardly ever looking at the off-campus click flows and UI processes.

I think this can result in us being insufficiently attentive to improving usability and efficiency of the off-campus workflows.

Are there really problems with off-campus clickflows?

Well, I think so.  One piece of evidence is that when I recently proposed making a new system require everyone to log in — there was kind of an uproar of rejection.  It’s clear that local staff thought that having to log in was a serious inconvenience — but we may not be keeping in our mind that the majority of  our users have to deal with this pain the majority of the time.

Our particular SSO system (shibboleth API combined with a proprietary vendor-purchased login component) is kind of a pain. It’s slow. It breaks the browser back-button on in some browsers, when you go through our SSO process.  The login is difficult to use on mobile, on small screens, or without javascript. It’s got some bug I don’t understand the details of that sometimes requires users to delete their cookies to get through the login process.

If all staff was using the off-campus click flow more often and encountering these problems, would it result in more energy spent on fixing it (or pressuring our central IT organization to fix it?).

Then EZProxy of course has it’s own problems. Slow, sometimes availability issues, also problems that sometimes result in having to periodically delete local cookies (prob due to ezproxy misconfigurations — that we don’t notice, because staff on-campus use doesn’t use ezproxy!).

Then there are newer weirder on/off campus differences not directly related to auth click flow. Like the fact that many of the new ‘discovery’ solutions provide different results to unauthenticated off-campus users, but users may not realize they are getting different results (or even if they do, find logging in not worth the trouble) — are we thinking about if these users are getting good service?


Perhaps staff should be encouraged to somehow use systems through the ‘off campus’ lense at least sometimes.  It is possible, although tricky to set up, a way for people sitting at their desks ‘on campus’ to still appear as ‘off campus’ to the various systems.  One hacky way to do this we’ve done here  is we actually subscribe to a DSL ISP, and set up Windows ‘remote access’ login to a single computer hooked up to to that DSL.  This is used right now mostly only for troubleshooting reported access problems that apply only to off-campus, and it’s invaluable. But it’s hacky, probably can’t support a whole bunch of people using it at once, and inconvenient.

If a better more robust way to do this could be set up, maybe “off campus Fridays” where all staff users set their environments up to appear to be off-campus even when they are at their desks?

Or perhaps we should actually consider moving to a unified click flow, where everybodyon campus or not, has to authenticate when authentication is required.  It’s a pain keeping all systems (and third-party vendors!) recognizing the same proper set of on-campus IPs anyway — in a large complex enterprise, the IT organizations management of IP addresses is complex, and oriented at network efficiency not at the libraries desire to be able to tell something about someone by their IP address. (But we’d have to remember to set up some way for ‘walk in’ users to still get access to products we license for ‘walk in’ users!)

Of course, all of the above is just talking about ‘solutions’ to making staff  cognizant of what things are like for our off-campus users. It doesn’t actually fix the inconvenience of current off campus click flows.  I am not actually sure how to fix the inconvenience, if it was easy I would have done it already!  But even if we let on-campus users (and staff) have more convenient click flows — the majority of our users the majority of the time aren’t benefiting from this, and I’m convinced that off-campus use of our services is only going to keep increasing. (Remember again, if you are using a cellular network with a mobile device, you are ‘off campus’ regardless of your actual physical location).

The problems are tricky to solve (and I probably don’t even know about all of them myself, most of my use of library services is from ‘on campus’ too!).   But unless library staff are feeling the pain too, we may never be able to fully identify the problems, and get institutional commitment to dedicating resources to solve them.

8 thoughts on “Remember the poor off-campus user

  1. Authentication for mobile apps is another part of the landscape that causes confusion and frustration for patrons, because the vendors all seem to have a different scheme.

  2. Can you say more alc28? I’m not sure what you’re referring to, what vendors/products for example, and what types of mobile auth schemes?

    For the kind of auth I was thinking of, it’s all controlled by our library more or less, and the interfaces don’t work very well on mobile sometimes, but there aren’t different ‘schemes’, just
    HTML in the browser, and there aren’t issues of different vendors we license from doing different things, it’s something under ‘our’ control (although more central IT than the library).

    What vendors, products, and schemes are you thinking of, that have caused problems for your patrons? Oh, are you talking about native mobile apps rather than HTML web apps? Which vendors you work with have such native mobile apps? We aren’t really promoting any vendor-specific mobile apps at present (although I’m sure it will become a problem in the future. These days shibboleth is widely adopted by library-market vendors — but I don’t think there’s been _any_ work on mobile-app interaction flows for shibboleth, rather than browser-centered ones. Shibboleth seems to be more or less a ‘dead’ standard and implementation, in that it isn’t getting much continued maintenance or development attention. Which is a problem).

  3. Ebsco’s mobile app has a sort of email based authentication, which bypasses Ezproxy, and allows the user in for quite a long period of time after authentication, on campus or off. It’s interesting, but I still haven’t figured out the best way to explain it to users.

    One big step I was able to make on my campus was extending Ezproxy authentication to users of the wireless network. That meant a lot more library staff went through the login process, even though it wasn’t strictly necessary. Then the wireless network was taken off its unique subnet, and I lost the easy ability to treat it as off-campus. Oh well, it was good while it lasted.

  4. Until recently, when I was working as a part-time library assistant at a UK university, I regularly used off-campus access to do my own research at home. The problem I came across was the lack of uniformity between eresource providers in how they link to the Shibboleth login. Some vendors make the link you need to click hard to find and identify, some still mention ‘Athens’ and Shibboleth is relegated to a link named ‘other login’.

    As soon as I had managed to chose my institutional affiliation the process went smoothly – it is getting to that point where the difficulty lies. We have to produce different user instructions for each resource vendor.

    I agree that it is easy to be unaware of the relative difficulty of off-campus login – and it is a point which needs to be addressed in collaboration with the resource providers to at least work on a more uniform login process.

  5. Thanks, this is a cool post. During my “career” I have been noticed that it’s very, very eye-opening and useful to work in the library with only the tools we provide to our users. Ok computer networks (as you write), but also all the other facilities we provide to users: lockers, cloakroom, wc, wifi, chairs, tables, audio environment, pens, opening hours et cetera.

    Personally I’ve recently worked in projects and not so-called “real work” (read: customer service), so this sort of work is great for experiencing the library as our users do, and i believe can give super valuable information about what life is like “on the other side”.

    I’ve tried to encourage all colleagues to try this model too, at least every one in a while, but i’m not sure many are taking it very seriously.

    Anyways, thanks for the post. Though I cannot comment on your local particularities, i seem to agree with what you write.

  6. Tim, there is some group that has produced a set of recommendations for standardizing the advertisement of login options, but I can never remember the name of it or find their recommendations (which may say more about my memory than their marketting). That’s a different aspect of off-campus login then I’m talking about here, but I agree an important one, making it possible for people to find third party licensed platforms ‘via google’ and still be able to authenticate.

  7. that is a good idea, thanks laurence. In fact, you’ve reminded me that I’ve tried to do that in the past, but tor ends up being rather slow and buggy itself, kind of frustrating trying to actually get work done that way.

    But hey, maybe all academic libraries should run tor nodes to help each other out with off-campus viewing, and strengthen the tor network at the same time.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s