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.
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 everybody, on 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.