Showing posts with label user interfaces. Show all posts
Showing posts with label user interfaces. Show all posts

Monday, 17 October 2016

Disheartening the visitor

For a long time — nearly twenty years — I had a very clear candidate for Worst Entrance To A Public Library Ever, though thankfully that particular entrance barely survived the millennium. I've now found one that's worse. No names, no pack drill, it wouldn't be fair to the staff who I know are trying their best in very trying circumstances.

The other day I popped into this library. I've been meaning to go and have a nosy for a while. Up to a few years ago this town had a reasonably busy little library, nothing special, in a simple brick two-story box of a building. The shopping area of the town got redeveloped quite extensively, one of the casualties being the old library. It was the replacement I'd been meaning to visit.

The good news is that the building's well-signed in the shopping area and made easy to find because there's a lot of colourful and useful library posters in the window. The first bit of bad news is that it's on the first floor above a supermarket so you can't idly walk past, see the library in use and be tempted in. But the posters and notices in the window try to draw you in.

library lobby with escalatorSadly, once you are drawn in you're in a small lobby with just enough room to wheel a buggy round to a lift or else take the escalator directly in front of you. Everything is grey: pale grey walls, mid grey ceiling, dark grey carpet, steel grey lift doors and escalator. It's all a bit soulless. Nothing much invites you to go up the escalator: it rises up into a dark grey shadow with no knowing that anything's up there, least of all a library. All in all pretty nasty.

Once you get upstairs it's slightly better, though that's despite the design of the library not because of it. The colour scheme is followed again, relentlessly, with grey metal shelving and an extensive network of exposed pipes in the ceiling space also painted mid-grey, the building designer obviously being a big fan of warehouse shopping chic. Or else one of the Borg. The overall effect was softened as far as possible by posters and displays but there wasn't physically a lot of scope for making it a much more human environment. Which was a shame as there were good things going on in there including a very enthusiastic rhythm and rhyme session going on in the enclosure that was the children's library. Lots of colourful books on the shelves may have helped a bit but this is a local authority that was closing libraries and cutting book funds back when the rest of us were refurbishing and replenishing so the staff didn't have many resources to play with there.

Generally speaking this is just the worst of a trend I've seen over the past few years, new library builds by architects and designers who see the library space as being like an office or else just a room with a few shelves of books in it. For all the consultations that go on it's evident that the designers haven't made any effort to understand how the business of the library is run:
  • The need to invite the visitor in, ease them back out again and leave them wanting to come back soon; 
  • The different lines of flow for different kinds of use and different kinds of customer;
  • The ease of navigation so that somebody standing in the entrance knows immediately where they need to go;
  • The essential requirement of lines of sight for staff so that they can provide unobtrusive supervision and support;
  • The capability for change in response to early experience of use (like some landscape designers who only hard pave paths after a few months so that paths follow the "cow lines" established by the people using the space) and to allow for development of delivery of the services on offer;
  • Most of all, the acknowledgement that the library space is a human space so people have to feel comfortable in it.
None of this costs anything except a bit of effort and a willingness to understand the desired outcomes that are being designed for, Sadly…

Wednesday, 8 June 2016

Learning from experience

When you're doing any sort of serious developmental work, whether it's solving a problem or exploiting a new opportunity, you have to start by defining your preferred outcome then look at all the possible options for getting you there. One of the things that constantly dismayed me when working in public libraries was just how limited "all the possible" usually was, and that these limitations were often imposed as a matter of principle rather than practice. Often summed up with a look of complacent contentment and the mantra: "Ah well, you see, they don't work the same as libraries." I still bump into this thinking quite regularly on the lists and social media, often as a dogmatic statement along the lines of "Libraries have got nothing to learn from…" This is, of course, the veriest nonsense: libraries can learn a great deal from other business operations, if only the reasons why adopting a particular policy or process would be a bad idea in a public library context (and that aren't "Ah well, you see, they don't work the same as libraries.")

The other reason why it is nonsense is that although a business operation may be very different to yours some of the operational functionality requirements may be very similar, or the same. There's no particular philosophical or ethical difference between opening the public doors to a library first thing in the morning and opening the public doors of a shop, for instance.

The exciting thing about not imposing any constraints on where ideas can come from is that you can often find alternatives to the organisation's "default setting" that are cheaper and more effective to apply.

The responsibilities in my last job included a transport management system called Tranman. Very generally speaking it was used to manage the council's fleet of vehicles and the jobs done in the vehicle workshop. Some of the jobs done in the workshop were part of the routine maintenance work included in the service level agreements with the council departments using the vehicles. A lot weren't: repairs necessitated by accidents or driver abuse were chargeable extras and the workshop also did a lot of private repair work, services and MOTs as part of the operation's income generation. Extremely different to the business operation and purpose of the public libraries I was also supporting.

They had a problem. A lot of the jobs were taking ages to complete and invoice on the system because they were missing information about the parts that were issued to them. Even worse, some jobs had been completed and invoiced without including the rechargeable costs of the parts. This was playing hob with their cash flow and making the accountants cross. So we had a look at it and basically the situation was:
  • There was a manual process involving somebody trying to catch up with a pile of paperwork at the end of the month
  • There was a technical solution which could automate the stock issue but wasn't being used
What was needed was for the parts to be issued to the jobs in as close to real time as possible and that wasn't going to be done manually from the paperwork.

We had a long, hard look at the technical solution. None of us were big fans. It was hard work to get set up and running and, frankly, was over-engineered for its purpose. On paper it looked great:
  • A piece of software on the stores manager's PC generated barcoded labels for each part, the barcode including the appropriate part number and bin, together with a human-readable description.
  • The parts bins were labelled up accordingly.
  • When a part was to be issued to a job the store man entered the job number into a PDA, read the appropriate barcode and entered the number of items being issued.
  • The PDA was then plugged into a console attached to the store manager's PC and the data uploaded into Tranman.
In reality it wasn't so hot:
  • The barcoded labels soon got scruffy and unusable.
  • We could make the barcodes on the labels as big as we wanted but the descriptive text was always tiny and difficult to read, especially in some of the darker corners of the store room.
  • The keys on the PDA were very small (6mm across), which was difficult enough for me with my never-done-a-stroke-of-hard-labour-in-his-life delicate fingers and not a lot of fun for workers who'd spent years bashing their finger ends on bits of metal on cold Winter's days. The incidence of input error was high.
  • Uploading the data was a bit hit and miss at first: it took quite a while for us to iron out the problems and making sure the solutions were properly packaged into the virtual application. (I for one was praying nothing happened to that PC as I wasn't confident we wouldn't have at least a few of these problems again with a new deployment of the software.)
  • It wasn't easy to see where and when something went wrong. The lack of transparency meant that you couldn't do any quality control to make sure that the right parts actually were being issued to the right job.
Something had to be done. 

We looked at various somethings: we spent far too long trying to sort out better barcode labels; then we had a fruitless quest for a more user-friendly PDA that could do the job. Over the next few months, in between a pile of other pieces of work we were doing with this system, we tweaked this process as best we could but in the end it felt more like we were working through levels in an arcade game rather than getting anywhere with improving the process and addressing the cash flow problem. By this stage I was thoroughly fed up and went and had a sulk in my tent. On reflection it was apparent that all we had been doing was following the same ploughed rut over and over again. 

We'd let our problem-solving be dictated by the "solution" rather than either the problem or the desired outcome.

So I looked again. And wondered why the issuing of parts to a job in a vehicle workshop was very much different to the issuing of library books to a borrower…

The solution I came up with was cheap, not especially elegant but did the job and could be seen to do the job. There were two elements:
  • A standard barcode reader, same as you'd see in a shop or library
  • A folder containing sheets of labels including all the information needing to be entered into the job record:
    • The description of the part in a large, readable font
    • The part number as a barcode (using the "3 of 9" font)
    • The bin number as a barcode
    • The store location as a barcode
The process was:
  • The request comes in for the part for the job
  • The stores man gets the part then opens the job record in Tranman
  • The part number, bin number and location are input by reading the barcodes from the appropriate sheet
  • The only manual input is the number of parts
  • The parts are issued to the workshop
For out-of-hours working the process was:
  • The request for the part is recorded on a paper job sheet
  • The fitter working on the job gets the part
  • Next working day the stores man issues the part in Tranman as above
Getting a working test sheet turned out to be a bit of a problem because initially I was doing it in MS Word and the formatting it imposed was disabling the begin and end codes of the barcode (an asterisk *). Jacking it in and doing the job in Wordpad gave us some test sheets we could use to demonstrate proof of concept. I used Crystal Reports for the final print out of all the parts.

Sadly, this is as far as I got with it by the time I was leaving. We'd checked that each step should work as expected but we'd not given the process much hammer and inevitably there'd be some snagging to do. One thing I'd have liked to have done, given the time, would be to modify the Crystal Report so that the first few pages were limited to the high-volume items, to save the stores men having to routinely wade through so many pages.

So that's how I applied a bit of standard public library functionality to a problem in a completely other environment.

So what are the takeaways from this?
  • Don't mistake differences in business operation with differences in operational functionality. In this case, issuing an item in real time is issuing an item in real time.
  • If your problem-solving energies are being devoted to the solution perhaps you've got the wrong solution.
  • To solve a problem you have to know what problem you're solving and the outcome you desire of the solution.

Saturday, 16 January 2016

Herding digital cats

It's interesting that the report on the national digital presence for public libraries finally saw the light of day at the same time that BIC and a lot of library technology supply companies were meeting to progress the Library Communications Framework (LCF).

In their own ways they are each trying to solve the same problem: how to pull together a myriad disparate resources and services, each built to their own specific requirements, into a single user experience without requiring the availability of hundreds of library technologists in the front line of public libraries who probably will never exist.

I think they are both doable, with fair winds and fair spirits prevailing.

Sunday, 27 September 2015

A national digital platform for public libraries

I'm always a sucker for flattery so it was flattering to be asked to go along to one of the workshops that the Library Task Force has been running to talk around the proposed national digital platform for public libraries. The Society of Chief Librarians had commissioned Bibliocommons to draft a plan of action and we were using the draft as the basis for discussion. This document has been unofficially published on one of the library lists but my copy says "Not for publication" so I won't go into any details of it here. This absolutely wasn't the report to go to the sponsor, it was a work in progress showing some very interesting workings-out.

The discussion was useful, though I've no idea how or where it would progress.

One of the points made by representatives from Bibliocommons was that there is no point in building yet another portal. This is dead sensible: the history of libraries and the internet is littered with the corpses of dead library portals, Some good, some bad, many perfectly competent and a few perfectly splendid and all of them the product of many hours' hard work. How many can you remember? The reasons for their falling are many and various but at the end of the day what had been intended as important local reference materials became so much unsecured grey literature. So no portals is a good idea.

Libraries do have useful points of arrival online: their library catalogues. Even a small authority like Rochdale gets at least four thousand visits every month. Integrating a national digital platform into a busy local interface makes a heap of sense. This is the point at which detractors would point out that Bibliocommons have products that do just that so they're bound to say so aren't they? Which can be countered with the observation that their perspective makes it easy for them to latch onto something that should have been blindingly obvious to anybody. The questions are: how would this be done and where would the necessary investment come from?

There was some troubled discussion of "national." Any discussion of any national public library initiative has to acknowledge the elephant in the room: the fractured state of the national public library service. Even if the end product is free and somebody else is doing all the work, the likelihood is that there wouldn't be 100% coverage across England's public libraries: if it's optional then somebody will opt out. What would be the minimum take up that would enable a minimum viable product? Our workshop group could only flag up the question; we weren't in a position to provide any sensible answer.

For me, the other problem is the integration of the national product with the local interface. No doubt someone somewhere would be prepared to do the necessary for a fee, but where would the money come from and if it were available how would it be apportioned and accounted for? Already we're moving away from "If the end product is free..." How much local expertise could be available to do the work? Let's be honest: generally not that much; which isn't a reflection on the expertise of some very good people thinly-spread out there in libraries but an indictment of the lack of investment and development within too many library authorities. How many library authorities present themselves as "Countyshire Libraries" instead of "Countyshire Library Services," their names and their organisational structures reflecting the traditional custodianship of library buildings rather than services which are often entirely independent of the building. Similarly, if you were to divide the cost of the staff managing and staffing libraries by the number of physical visits to the library you'd probably get a high fraction of a penny; in most library authorities, if you were to divide the cost of the staff managing and supporting virtual library services by the number of virtual visits you'd go a good few decimal places before the answer wasn't zero. So we should be concerned about the local capacity to do much of the necessary development work. And that's before we get to the vexed local corporate branding vs. national initiative branding issue!

So by the end of the workshop I'd come to the conclusion that if it was free and somebody else was doing the work and if take up was adequate to make the product viable then the challenge would be integrating the national platform into the local offer within almost certainly diminishing resources. Which is a tad downbeat but not necessarily insurmountable. It'll be interesting to see if/how this progresses past this exploration stage,

Sunday, 14 September 2014

Doorbells of despair

Back in the old days, Oh Best Beloved, when your parents were still young and didn't have mortgages, I used to work with council one-stop-shops. At one place I worked the need for a separate customer services service was self-evident as everything about the corporate culture and customer journeys screamed out that it couldn't keep the public far enough away for its own comfort. Its council offices had the nearest I have seen to a moat filled with crocodiles that could be practicable in a 20th Century building.

The most frequent customers were council housing tenants, or hopeful tenants-to-be. The customer experience was painful. They had to:
  • Know that they had to go to the council offices for a particular service and not one of nineteen other offices scattered around the town;
  • Know which floor to go to;
  • Know that when they got out of the lift at that floor they had to turn right and go through the big, wooden, unmarked door;
  • Know that once inside the reception room (not a lot bigger than a telephone booth) they had to ring the appropriate door bell for assistance;
  • Know which of the six doorbells on the wall to use, which wasn't obvious as they were hand-labelled with the names (or even initials) of the housing teams, not their function.
If you picked the wrong doorbell you were tutted at and left to your own devices to have another guess.

I'd hoped those days were long gone but looking round at public service web sites I begin to wonder. The vogue now is for pages to be stripped down bare save for a small number of icons taking you to the services you are most likely to want.

I have a few issues with the more extreme instances of this:
  • Where's the information telling the user who you are and what you do? Not a mission statement (God help us!) but a simple narrative explanation of your function. Don't assume that because you know then so does everyone else.
  • Where's the support? What if these icons and labels mean nothing to me? What do I do? Who do I ask for help?
  • Who says these are the services I am most likely to want? You don't know me, you don't know what I want.
  • Who says these are the services that the average user is most likely to want? Customer insight might be able to tell you which of the existing options the customer is most likely to find and use but that isn't necessarily the same as "want." Is a page popular because it is useful or because it's easily accessible (or least-inaccessible)?
  • Beyond the metrics, who determines which services are promoted? Is it the comms team? Is it the web team? Is it the service? Is somebody waiting for the research to demonstrate a demand for resources that have effectively been hidden?
But most of all, whenever I see one of these web sites I have to ask myself: have we really gone back to the customer having to guess which doorbell to ring for attention?