if you trust your rebel heart, ride it into battle

It's December Days time again. This year, I have decided that I'm going to talk about skills and applications thereof, if for no other reason than because I am prone to both the fixed mindset and the downplaying of any skills that I might have obtained as not "real" skills because they do not fit some form of ideal.

09: Instruction

One of the things that was not made clear about what my job would entail was that there would be all kinds of instruction going on with regard to the library's resources. I expected there to be some amount of helping people wring better results out of the databases, or making their search engine queries work better and with the way the engine expected things to work, because that's the sort of thing that I trained on as a professional, and it's not necessarily obvious to the people who are just starting to use databases and search operators how to maximize them for best effect. Or even to know how those operators work and how to put them together so that they will produce something useful. (Yes, despite the understanding that I was not going into either a K-12 or collegiate space, I still held the belief that sometimes someone would seek help from the public librarian about how to do those kinds of schoolwork parts.)

Reality has told me that while those are useful things, it's highly unlikely that the public library user will ever get to the point where they need database tips or search operator optimizations. In the era of slop-generation machines, and the unwanted, forcible integration of those slop-generating functions into things like search machines or other aspects of our technological lives, I imagine that search operators are going to be even less used by the general public as they seek answers for what they are looking for, and are willing to accept slop because it looks correct and reads confidently.

What I spend so very much of my public-facing time doing is instruction, absolutely, but it is instruction of the most basic forms of technology interaction. Our print system, as I lovingly refer to it, is "[z]-teen fiddly steps, all of which have to be done in the right order or it doesn't work." Divided into parts one and two, of course, where part one is ensuring the thing that is desired to be printed has been properly downloaded and is printing the correct thing, because many people want to print the preview that they're being shown on the screen and then are confused when what prints is the e-mail behind it, instead of the document they can see. Or they want to fill out a document and print it, but the document itself does not have fillable fields in it, so instead I end up walking them through the printing process and then through the scanner process so they can scan back the filled-out form and send it to the people who want it.

And sometimes just getting to the document itself can be a real pain. For example, I had a document sealed with Microsoft Azure locks, so it wouldn't open in Chrome at all. The Microsoft website said we had to open it in Edge, which we did, and then signed in, and then it kept telling us that we had to switch to the right profile to open it, even though we were signed in to the right profile on Edge.

So then we opened it in Acrobat Reader, and it spawned an Edge window to ask for permission to open it, and when permission was granted and all the appropriate sign-ins were completed, the window returned an error saying that there wasn't a necessary token available. Nuts. That seems like the rock and the hard place at this point.

But, going back to Acrobat Reader and letting the process finish and close the "Hey, we opened up a pop-up, let us know when you're done" notification that appeared, it turned out we had successfully authorized unlocking the document, and the person was able to print their paperwork from the VA that had been sealed with this Microsoft lock. I strongly suggest involuntary chastity torture be applied to the engineers that inflicted this nonsense on us and made it not work when we did it their way and errored when we did it the way they wanted us to.

Or the countless times where someone has asked me why their form isn't submitting or moving on to the next page, and I scan the document, and point at one thing, saying, "That thing. It needs it in this form." The offender is usually ringed in a small red box, and has some text explaining the problem, but unless that's what you know to look for when something is having an error, you can breeze right by it, because you put in the information that was wanted, why isn't it accepting it?

I have, at least twice, helped people them pull their LLM-generated resume and cover letter out of the interaction phase with the LLM and into an application. That was mostly just e-mailing themselves the chat transcript and then dumping the text into Word documents, but to someone who hasn't done this thing a hundred times every day as part of their work, they need to be walked through the process of giving the transcript a URL to ping against, e-mailing said URL to themselves (a thousand curses upon the engineer at Apple that thinks that "Share" is the right button to hide "Save" operations behind), and then opening the transcript from the URL, copying the text and pasting it into Word, at which point they could start styling it as they wished. I have a certain amount of revulsion about people using those tools to do this work, but I am also somewhat professionally prohibited from giving advice to people on how to build their resume, apart from helping them with formatting or showing them where the templates are that they can paste their information into. We have community partners that can help with that, but those kinds of things usually necessitate a trip to the local metropolis.

It's often software that I have to deal with in one way or another when I'm doing these kinds of instructions, whether it's helping someone take pictures of identity documents and them moving them directly off their iProduct onto the computer so they could then be uploaded to the right site in drag and drop. (Which was the easier way, honestly, than any other available to them.) Or teaching someone, and then letting them practice, how to transfer material from their Macintosh to a storage drive, so they could eliminate it from their iCloud storage. (If my deep loathing for the way that Apple products and iProducts handle things like storage and directories and where something actually is hasn't come through yet, I should probably shout it louder.) When I'm in the weekly "Tech Help" program, there are a lot of things that need explaining, like how to slide a camera cover and make it possible for the camera to work. Or saving documents. Connecting to the Wi-Fi. (And then, occasionally, the secret ways to make the captive portal work properly when it doesn't do it the first time around.) Or helping someone with the apps on their iProduct and doing things with them. It's all stuff that would likely be covered in a class, or learned through experience of use, if you had started either the class or the use when you were younger, but many of the people here have neither had the class nor the long practice, and so I and the other person in the program are helping people as they handwrite the procedure for the thing(s) they have come to the program to learn how to do. This is not a knock on older people - it's just the most effective way for them to retain the knowledge and be able to use it when they're not in the program. (I write stuff down all the time to remember it and seed myself with reminders to do or follow-up on things.)

There's just so much need for what I would consider to be basic instruction in the use of computers that has not been provided, or is only being provided through a paying course, or only provided through situations where someone has to travel to the local metropolis, or it's only offered once a month as a three hour intensive, because that partner is doing the same thing at all of our locations and exhausting your community partners by making them try to sate the insatiable is a bad idea.

Many of these situations are happening with time pressure, as well, because they're running out of computer time and the library is closing and they just need to get this thing done first, why isn't it working! And that kind of panic often makes instruction not possible as much as being very directive about what needs doing. And once the thing is done, the person no longer needs the instruction, because they don't expect to need to do it again.

I've also found that a fair number of the people who are in the library and need assistance with working with the computers fall into one of two camps. The first camp hates computers and the increasing electronic everything and wanting as little to do with it as possible. They have had bad experiences with computers, or bad experiences with people who have said they are good with computers and have not figured out how to avoid looking down their noses at the people who aren't, and they prefer human to human interactions rather than anything mediated by a computer. (They most likely would agree with the maxim "a computer cannot be held accountable, therefore a computer must never make a management decision," and then go forward into complaining about how everything has to be mediated through computers, automated assistants, and chatbots when all they want is a telephone number to talk to a human so that the problem can be fixed in five minutes. Because the human will understand what they want.) Much like my younger self, these are not people interested in instruction or in retaining the instructions, because they never want to have to do that thing ever again, period. With enough repetition, I suspect, much like my younger self, it will sink in and they will learn things, but also like my younger self, they will never stop being salty about having learned it in the first place. They are people who will accept the idea that computers are stupid, but they will blame the computer for being stupid when it is a PEBKAC error.

The second camp are people who have become afraid of computers. Those people have often been fed the scary stories about black-hat hackers, and stolen currency, identity theft, and the exfiltration and posting of data, botnets, and all of those things that do happen, absolutely. They also know that phishers and predators are using computers, deepfakery, synthesizers, viruses, and other such things to fool people into giving them sensitive information or to just take it without asking. So they don't like interacting with computers, either, but it's because they've been convinced by a steady stream of media stories that if they press one key wrong, or click in the wrong place, it will mean that they have given access to a criminal organization that will steal their identity and all their money and compromise all of their systems. These are people who are open to instruction, but only so far as it gives them an exact sequence of steps to faithfully replicate, and if at any point, something happens that is not in the sequence, or the sequence produces an error, they have a panic because it's not working like I said it would be. It's a brittle form, because the slightest deviation, or the change of a UI element, or any other such thing is enough to change the entire thing and now they're back to baseline worry that something catastrophic will happen if they deviate even the slightest bit from a known-safe procedure. These people will not accept the idea that computers are stupid, nor are they particularly keen to understand that because of this, the people designing computer software have figured out how to put in all sorts of guardrails around permanent decisions. I try to give this piece of wisdom for the afraid: "If the computer asks if you're sure, and you're not, click the 'cancel' button." (I also try to explain to them that most criminals aren't after them specifically, they're either after the data that the company has, and if they get that, there's nothing you could have done to stop it, or the part where a scammer is trying to get you to do something before you think about it, and so the best way to beat those is to take the information given, and then find some other way to contact the people they claim to be, and confirm with that. I know it doesn't always work, even on people who know that's what's going on, but I try. And so do our community partners.)

Because I do these pieces of instruction so often, I've become a very practiced hand at doing it, and guiding people with all sorts of devices or different scenarios successfully to the result they want. Often times they misattribute this to some form of brilliance, superior intellect, or supernatural beneficial aura that I have and they do not. I usually try to pop that bubble by being honest about how many times a day I do this, and if they had the same amount of experience I did, they'd be just as good at it. I don't think the bubble actually pops all that often, but it very much is having experience in the general form enough, and having seen several of the most common (and a few less common) ways that the process errors or goes slightly sideways that I can course-correct in the moment to keep someone on track. And that also sometimes means knowing when to let go of the part that's saying "they're not doing it right!" or "they're repeating this step unnecessarily!" and focus on making sure that the thing gets done in the end, regardless of whether it was done efficiently or elegantly. Because most of the time, I'm not going to see that person again and they're not going to come back to tell me about what happened because of what we did. They're not interested in perfection, they're interested in satisfaction, and therefore any job that is satisficing is a good job. (Even in some cases where I know that the thing that they want to do, and the thing that would be actually effective toward reaching their goals are two very different things, but they don't want help on doing the effective thing, they want help on doing the thing they want to.)

For example, I was helping someone work through making sure their emails all synced to an iProduct. One of the un-synchronizing accounts just needed to be removed and re-added, and it started syncing again. The other was an account that kept prompting for a password, which we couldn't actually find, remember, or make, but after trying all the things we could to get it work, the person mentioned that everything from this account that was complaining about not having a password forwarded to one of the accounts that was already on and synchronizing to the iProduct ([annoyed grunt]!) So I deleted that account from the phone, and lo and behold, no more password prompts. That doesn't help the underlying problem of not knowing the password to get into that account, but it does accomplish what was asked of me, and the person left happy that I had fixed the problem they wanted help with. Satisfaction achieved.

If I had more time with people, and could guide them through repeated attempts to do the same thing, especially those things that sometimes have slight variances, I could help them build the skills they need to be able to do the more general form of the thing they want to do, but I don't get that. I don't have that for programming time, and I don't have it for those interactions on the public service floor. The best I have is trying to steer someone toward one or the other resources that can help with this, because they know they'll have someone for a class period, or a video that they can watch infinitely until it clicks, or any of the other things that are really needed for any kind of learning that isn't just-in-time learning. For that to happen, the person has to be interested in learning the specifics and the general situations, and most of the people at the library, I suspect, don't want to learn the general pattern of a thing, they want to learn how to do the specific thing they want done and to move on.

What that usually means for me is a lot of repeat instruction. Even though when I signed on to do this job, I didn't think I was going to be doing a lot of teaching. (And I still recoil from being referred to as "Teacher" in any way. I don't have an education degree, please don't call me that.)

Sometimes, though, people do come back, or they do tell me about what happened after they interacted with me. I helped someone put together a huge zip file of pictures and video, then showed them how to upload it to Dropbox and provide a shareable link to those that needed to see it. Then they came back a few days later and needed to add a new picture to the file, so we did that, too, and re-uploaded and re-shared everything just to be sure that it would work properly.

Or they appreciate the care and the rest that goes into the instruction. I helped walk someone through the process of first signing into their e-mail (and walking through the steps for a recovery to make sure they could get in, and gleaning that the person who had set up the account had set themselves as the recovery e-mail and telephone number, which could have made the process a lot shorter—all things that I have done before, but that would (and did) throw someone who hasn't for a loop), and then helping them walk through getting their boarding pass printed and confirmations all sent to the right places. By the end of this process, I was complimented by the person saying "after you've shown me how to do this, I could teach someone else how to do it." Which is certainly a goal of mine when it comes to helping people do these things.