My Biggest Tech Support Challenge

September 12, 2007

The start of a new academic year always brings new problems, challenges and questions. No matter how much one plans for change, there is always something that throws a wrench into the best laid plans. This year, programs like Windows Vista and Office 2007 are generating many calls for help. While I certainly expected many of these issues to appear, they are causing frustrations for both staff and students – and for me too since I’m struggling with the best way to offer support. This struggle highlights one of the aspects of providing technical support that I find most challenging – trying to find the right balance between giving someone the tools and training necessary to solve their own problem versus actually solving the problem for them.

When someone calls me with an issue, my first task is to listen, ask questions and make a preliminary assessment. At this point, I need to make a determination about the best way to resolve the issue and make a determination about whether or not this is the type of problem people need to be able to solve (or attempt to solve on their own). Some issues that play into this decision are the following: does the problem involve a student? is the problem related to standard procedures and/or practices (connecting to the network, printing, logging onto a computer)? does the problem require my intervention? There are, of course, other factors as well. This isn’t easy, and I’m constantly trying to make sure that I am offering the right level of support to everyone. I want people to feel empowered – and confident about their technical skills. But, I do not want people to think that I don’t want to help them – to think that I am being unapproachable and/or unhelpful. I’m pretty sure that I don’t always get it right, but I do try and I do try to learn from the mistakes that I do make.

One of the most important factors in trying to determine the right level of support is making the determination about whether or not this is the type of problem that might happen when I am not around to offer support. If this is the case, I believe it is important to give people some verbal help and then give them some space to try and resolve the issue. This is why when presented with any problems that involve student issues, I almost exclusively try and offer phone support. I don’t immediately offer to fix the problem. I specifically wait until a staff member either asks me to personally come and help or until I get a sense that the staff person is seriously at a loss.

One of the things that has become clear to me over the time that I have been engaged in technical support is that technical training for staff is a big problem. Honestly, I don’t feel as if it is one of my strengths. So often, there is so much work to do day to day to keep everything running smoothly that training takes a back seat. So staff may end up feeling as if they have the knowledge or the tools to solve the types of technical problems that patrons have. This, of course, means that I need to spend more time trying to troubleshoot basic problems. Right now, I’m on somewhat of a mission to try and make a serious effort to get people the tools they need. Hopefully, this will help me feel more comfortable when faced with the choice of helping staff solve problems themselves or solving it for them.

If anyone has any words of wisdom about how they deal with this issue, please feel free to share!

Libraries & Technology

July 5, 2007

Over the past year or so, I have become extremely interested in the topic of technology in libraries, the problem of technical support for patrons and the problem of technical knowledge among library staff. The whole “the user is not broken” discussion made me realize that library staff are not broken either. Sometimes those of us in the technical support arena work off the assumption that the user is the problem. This attitude isn’t helping us get the most from people – nor does it help us provide better customer service to our patrons. Technical knowledge for many people working in libraries is a big problem – even bigger for public services’ staff who are often expected to support and help patrons with technical problems. I’m hoping to do some type of study of this for my capstone experience, special project, or whatever you want to call it (which I will be doing during the spring of 2008).

Along these lines, Emily Clasper put together a list of technical competencies for librarians over at Library Revolution. Clasper is adament that these skills are an absolute must. I agree with her. I’m just not sure where these skills need to come from or who should be responsible for assuring that people have them. I tend to think people should have these basic skills before they even apply to library school. But, I think that since technical knowledge is so incredibly critical, we, in libraries, need to find a way to provide better and more effective continuing education for our staff.  The basic skill set changes fairly rapidly – and I can only see it getting worse.

I love this quote from Clasper:

So here we are trying to sell 2.0 technologies and initiatives, and all too often hitting a brick wall. But is it any wonder? Sometimes I feel like if I have to explain to one more librarian how to cut and paste a string of text I’ll just about die. No wonder I get a glassy-eyed look when I mention XML syndication!

I agree that dealing with Web 2.0/Library 2.0 is so far beyond the day-to-day things that go on in most libraries. I don’t think we can fully move forward with new technologies until we have a decent grasp of the basics.

IT Management In The Library

February 22, 2007

In a new blog, Red dirt librarian, Carolyn McDonald writes about Models for managing IT in libraries. In the post, McDonald suggests that there are three types of IT models: all IT support provided by the library, all IT support managed by an outside agency or a hybrid model where IT support is provided from within the library and from an outside department. McDonald writes:

This last option is the one I am most interested in. It seems to me there are significant advantages, and risk of major problems. I’ve seen both at work. So how do we get the mix right, how do we ensure good communication, how do we develop enough of an understanding of each other’s business to appreciate what is being done and enable the business of the organisation?

In four short sentences, McDonald gets to heart of the matter for those libraries that have a hybrid mix of IT management. There is a natural tension between library staff who want to ensure open and easy access for everyone and IT staff who are charged with protecting an institution’s computer and network assets. I know that it seems to people that if they ask an IT person for something the answer is always no. I also know that many IT people shake their heads because “those library people” are always asking for something else – and that it is usually something that isn’t straightforward or easy to accomplish (this is my role in my work life). Open lines of communication and understanding of the mission of each organization are essential keys to making this hybrid relationship work. It really is all about give and take – and a little understanding.

I often have to ask for exceptions to the rules, holes through the firewall, LDAP access, guest accounts for patrons, wireless access for visitors and all sorts of other things that aren’t often available anywhere but in the library. I have found that it helps to have a good working relationship with the IT department. I make concessions sometimes – and agree to wait on some initiatives. I also offer to help the IT department with big projects. I will at times volunteer library computers and staff for new IT initiatives because the library can provide sufficient critical mass for test cases. I have also found that it is critical for me to be open and honest with the IT department about library initiatives that involve technology. I don’t EVER spring anything on them as a done deal. In a hybrid mix, the relationship between the IT department and library systems people makes all the difference in the world.

A Story About Technical Support Issues

January 11, 2007

This week at work, I received a call from one of our reference librarians asking about some trouble that a patron had experienced on the previous evening. The patron was a student in a satellite program that is offered by another institution, but is taught on our premises. This puts the students in the program in a rather difficult situation – they are not technically part of our college community, but they do use our physical resources. Our college provides the space for the actual classes, the students have network privileges on our campus and they have complete access to our on-campus library resources.

On this evening, this particular student came into our library in order to try and print out a syllabus and some documents on reserve. These items were in the course management system used by the college that runs the program – not run by my college. I’m not exactly sure what the exact nature of the problem was – except that the student could not print out the syllabus nor the documents. I’m not sure if the student couldn’t log into the course site, couldn’t open the documents or just couldn’t print them out. Our reference librarian called to ask if the issue could have been related to the fact that all of our library computers have IE7 installed. My response – yes, of course that could be an issue, but I really need specific information in order to troubleshoot. Without any information about the course management system, without access to the courses in question, without a username and password, without actually being there when someone was experiencing the problem, my hands were somewhat tied. Neither could I provide a definitive answer that would solve the problem. After a brief conversation about the problem and what we could do to try and resolve the issue, the reference librarian had a great idea. She thought we should ask the program coordinator for a test account so that we could try and troubleshoot on our end – which is where the students in the program are using their resources. Someone did in fact contact the coordinator and ask for this information – the response was rather curt. There was no need for us to have this information. The coordinator had heard about the problem, was meeting with the student and would work it out. A pdf of the instructions for accessing the course sites was emailed with the hope that our systems person would be able to work things out with that information. Oh and yes, the coordinator explained that the system only worked with IE6 or Safari for Macs. Sadly, this information did not help.

Our systems person (oh yeah, that would be ME) was left feeling frustrated and unhappy – and unable to help resolve a basic technical issue for one of our constituents. Even more frustrating is the fact that I actually use the same course management system in question for my coursework at SCSU – and I use it with IE7 even though it isn’t supported. It works fine with some tweaks to security settings and pop-up blocker settings. As such, it would be fairly easy for me to rework the instructions for IE7 if given the opportunity. Since these students use our resources and need to access their course management system, something needs to be done. At this point, I do plan to sit down at one of our public computers, log in to my course management system and show the reference librarians how it works. Hopefully, they will be able to tell me if this helps the students in question.

Ultimately, I really thought this story helped to illustrate some of the problems of technical support in libraries today. It is a messy, messy situation. With remote access, satellite campuses, distance education, browser issues, personal firewalls, antivirus, wireless, etc., technical support isn’t something that is solely the purview of systems people. All library personnel need to have a better understanding  of technical issues in order to provide the best service possible to our constituents. When they don’t, we end up with frustrated and disappointed patrons. I honestly hadn’t really thought much about our agreement to host this satellite program on our campus – and about its impact. This was clearly a mistake. As a result, students are required to use a system that (supposedly) only works with IE6 in a library which only uses IE7. There is clearly a communication issue here – and I’m left feeling as if it is my fault. While it really may not be entirely my fault, it is my problem – as the fact that overall our technical support to our patrons needs to be better. I’m trying to learn from stories like this and hoping to eventually eliminate them all together at some point.

Should Tech Support Be An Explicit Library Service?

January 1, 2007

“Tech support is the key to our future”, wrote Laura Cohen in a post entitled The Accidental Tech Support Librarian. When I read this post, I had an real ah-ha, dawn-breaks-over-marble-head moment. I think that Laura is on to something that hasn’t really been talked about too much in the library world. Tech support has become a real problem in our computerized world. Computers, online systems, and technology play a large part in most people’s day to day lives. Despite the prevalence of technology, problems and issues abound. Laura explains the problem:

Our role in tech support has evolved slowly but surely as our operations have moved online. It’s sneaked up on us and now it’s a part of our (often unstated) mission. I suppose you could say it’s the law of unintended consequences at work. Put something online, and people will have problems using it, so the type of support we provide has undergone a transformation. We’re a service profession and providing help is in our blood, so we forge ahead and try to solve problems that are laid at our feet. We’re accidental tech support staff.

I think this is right on target and is a great explanation of tech support, especially for patrons, in the library. Laura is primarily concerned with the types of problems that remote users have – and she has a point that remote use has created a whole host of support issues. However, I think that tech support is as much of an issue for users within the walls of the library. In my library, we have three lab areas: one is primarily designed for reference use, one is a classroom setting used as an space for bibliographic instruction, a space for faculty to book classes on a one time basis if they need additional technology and as an open lab when a class isn’t in session and the last is an open computer lab that has software in support of classroom use. This means that people in the library aren’t just using library resources. They are also using word processing products, email clients, web-based social software sites, IM clients, statistical software programs, html editors, photo editing software, etc., etc., etc. Traditionally, the library is very different from ITs help desks which don’t often offer specific program support – and are staffed by students in off hours. I’ve noticed that if students are having difficulty with something they often come to the library to ask because there are staff people available – who are willing to at least try and help.

Ultimately, libraries need to decide whether they will provide technical support to their clientele. I personally think that if we offer technologically-driven services, we should be obligated to provide good, reliable and consistent support for them. Going further, we should not provide any service to patrons that we cannot support. Currently, I don’t think that we are doing a good job of providing technical support – specifically because we are still providing accidental tech support in a rather haphazard and inconsistent manner. Laura exhorts us to

. . . be clear about the types of tech support we’ll provide to remote users when the problem rests with their technology setup. Let’s determine who will provide this support, and at what levels. Let’s be sure that staff on the front lines are sufficiently trained to handle common questions and make appropriate referrals. Let’s provide decent Web-based FAQs to assist with basic, recurring issues. And by all means, let’s conduct regular assessments.

Again, my only addition is that we should be doing exactly this but including detailed support guidelines for those patrons who use our services in house.

In my experience, library staff on the front lines provide incredibly inconsistent technical support to our users. Certain staff have a greater understanding of technical issues and are more willing to try and help when problems arise. Obviously, they have only good intentions by trying to help. But are we doing more harm by providing asymetric service to our patrons? Wouldn’t it be incredibly frustrating for a user to ask for help with something like wireless and one day get the right answer and the next get no help at all? Shouldn’t we be able to provide patrons with clear cut and consistent answers to what we can support and what we cannot.

Do I believe that this will be easy to sort out? No, I do not. However, I think we need to make tech support an explicit library service and one which our patrons are aware of. Thanks to Laura for her post – and bringing this subject to light.

Bridging The Gap

November 15, 2006

I really enjoy discovering new blogs by students in MLS/MLIS programs. The students often offer great insights into their programs and into other issues that concern libraries. In a recent post by a student taking a library systems course, the student asks What makes a systems librarian? The author writes:

While systems librarians can have many roles, the one thing they appear to have in common is an ability to bridge the gap between the library and techie worlds. So the big questions becomes how do you learn both languages? And are library schools providing the courses to enable graduates to fulfill this role?

This is right on target. I have to say that in my role as a systems librarian, this is one of the most important things that I need to be able to do. Libraries have complex systems, and they rely a great deal on technology. If the library is part of a larger organization with an information technology department, someone has to be able to talk intelligently about the unique ways in which technology impacts library systems. I go to weekly IT meetings, volunteer to help with deployments and testing of new technologies (upgrades to operating systems, upgrades in email, new content management systems, hardware configurations, etc.), talk to IT staff before I do something that might be different from the accepted standard and try to sit in on as many demonstrations and training sessions as possible. I often joke that my aim is to really make the IT staff think of me as one of them.

To be able to talk the language of the techies, one has to really become one – or at least give the illusion of being a techie. I listen to their conversations, admit when I don’t understand some technical concept (usually about networks, packet transmission or code), read lots and lots of articles on technology and mess around with new technologies as much as possible. I have found that the IT guys are usually quite willing to discuss things – and to explain things when I ask. After a while, I was able to contribute (with intelligent conversation no less) and participate in the discussions about providing solutions to problems. I like to believe that I have been successful in developing a close working relationship with our IT department. I still have to remind them that technology changes may well impact the library (changing internet service providers or re-addressing IP ranges have huge implications for us, yet, I have to remind the IT staff of this over and over). However, they often ask for my opinion and include me in decision making.

One thing that I have found to be incredibly valuable is to remember that we must have a give and take relationship. I need their expertise for many things – especially those things that have implications for our physical network. I also need them for hardware replacement since all computer purchases come out of IT. To balance this, I help with things like re-imaging the computer labs in the library, troubleshooting issues with lab software for students working in the library and testing new software applications. Because I am the technical support for one physical building, it is often easier for me to upgrade all library staff to something like Outlook 2003 and see what type of problems occur than for the IT staff to find their own test group. I have offered up the library staff for this type of test environment several times. This means that the IT staff help me out – and I help the IT staff out. I highly recommend this type of approach.

As for systems librarian education in MLS/MLIS programs? I would be really interested to hear what type of class this particular student is taking. At SCSU, there is no class specifically targeted for systems librarians – at least none that I can see.  I haven’t seen any evidence of a class that encourages librarians-to-be to speak the language of techies as well as librarians. Maybe part of this has to do with the newness of the systems librarian position. Have we actually defined its parameters well? If we haven’t defined it well, how can we teach others what they need to know to become systems librarian? These librarian positions can vary widely from institution to institution. So much of systems is learned on the job – and I’m not sure that will change in the near future.

To succeed in this line of work, one needs to understand computer hardware, operating systems (including detailed information about services and processes that run on Windows machines), HTML,  imaging computers and networking concepts like bandwidth (calculating bandwith use), TCP/IP, IP addressing, NAT, VLANs, wireless, DNS, DHCP, switches, etc. There are of course other concepts that may be important. However, listening to techies is one of the best ways to figure out what concepts one needs to understand – and to help one gain confidence. Many people allow themselves to believe that they just don’t know enough to talk to IT people. My best advice is to believe in yourself – don’t be intimidated by the techies – and fight for what you believe you need. Remember that IT staff don’t understand libraries and/or the complexity of technology in the library. Systems librarians need to be the bridge that connects library technology to information technology.

The Education Of A Systems Librarian

October 15, 2006

In a recent blog post What exactly makes a systems librarian?, Corey Wallis reflects about what makes a systems librarian and what type of education would be best. Corey writes: “the big question in my mind then is obviously what course would help me in becoming the systems librarian I oughtto be.” I struggle with the same questions. Personally, I don’t think my current course of study (MLS program) will make me a better systems librarian in the practical sense. However, I do think it is providing me with valuable insights into the world of librarianship and is helping to make me more aware of library issues. This will make me a better librarian – and this is a critical piece of the puzzle I am trying to put together. So, I am looking at my MLS as part of the foundation of systems librarianship (I guess I would have to consider my 8 years of experience in library systems as the other major part of the the foundation). In my mind, this also means that the process of becoming a better systems librarian will never really be over. It is a lifelong process. Right now, I’m concentrating on my masters. However, when I am done, there will be other, more technical skills that I will need to develop. I’m not sure that I will enter another graduate program – at this point, I can feel myself getting a bit tired of school (I need to find a way to reinvigorate myself and my attitude), so I can’t stomach the thought of another formal program. But, I do think that I may find certificate programs, go to conferences, take classes on specific technical subjects, read current literature on important topics, etc. Ultimately, I very much enjoy learning, and I believe it is a key to personal growth and development. I hope never to stop – and often comfort myself with the belief that we can learn just as much from bad educational experiences as from good ones (which means every educational effort is worth something). 

A Day In The Life Of A Systems Librarian – Desktop Support

October 14, 2006

In addition to ILS administration and web site management, desktop support is another one of my major job responsibilities as a systems librarian. We have approximately 120 computers in our library, 12 printers, several scanners and other assorted pieces of hardware. I am responsible for their configuration, their regular maintenance and troubleshooting hardware and software problems. Our public computers are included in the college’s general lab rotation – with replacement scheduled for, hopefully, every four years. I generally need to remind those in the IT department about our three lab areas in order to make sure that the computers get replaced when necessary. The software configurations for our lab machines are similar to those of other college lab machines. I usually take an image created by the IT department and use that as a base and make some minor modifications – especially for the lab in the library that is used for library instruction. We use Deep Freeze software in order to keep the machines in decent shape throughout the year – this means that we only need to re-image the computers once a year – generally in August before the start of the fall semester. Deep Freeze has been a made computer maintenance a much easier and less time-consuming process. Of course, the image is never quite right, and one of the biggest projects in September is to do last minute installs and make last minute configuration changes.

About 30 of the computers in the library are dedicated as staff machines. These require more upkeep and troubleshooting than the lab machines. While the staff computers have much in common – operating systems, email and word processing software, ILS client software, etc. – there are many specific software packages that are used by particular departments. Such software includes interlibrary loan management software, cataloging software, book binding applications, along with several other types of programs used on a daily basis. Not only do I need to know what software goes where, I also need to know the basics of how it works and how to use it. In order to successfully troubleshoot user problems, I have to understand what the software does and what it needs to run correctly. Problem areas have a tendency to be how the applications interact with our ILS, printing issues (especially labels – which may be the bane of my existence), software updates and security issues (simple passwords, spyware, viruses, etc.). It is often the little issues that cause the most problems.

Desktop support is one of the most vital parts of my job. Problems with technology abound, and I really think that having someone in the building that people can rely upon for help makes a big difference on work efficiency. For this to be true, library staff need to be comfortable calling me with problems and questions. I also need to be aware of situations where I think that people may need some help, but don’t feel comfortable asking for it. On some days, it seems as if I do little else and as if my phone doesn’t stop ringing – and on others, I never seem to hear from anyone. Unfortunately, I can’t predict which type of day I will have. Inevitably, the days where there are many problems and issues are the days in which I have committed to work on something else. Ultimately, this is also one of the most rewarding parts of my job. Sometimes it can be very frustrating, but helping people and solving problems is very satisfying.

A Day In The Life Of A Systems Librarian – Webmaster

October 3, 2006

As a systems librarian, there are several major parts of my job description – being the ILS administrator is only one job responsibility. When I’m not masquerading as an ILS superhero (I often feel like I have to fly to the rescue), I wear my webmaster hat. While wearing this hat, I am responsible for designing, managing and maintaining our library’s web site. Of course, there are some caveats. The college has a department that manages the look and feel of the entire web site. They generally contract a design firm to provide templates and the like for all of the major departments. In the past, I have taken the templates that the firm provided and modified them heavily. I have found that the designs suggested or provided haven’t provided enough independence for the library web site. I am a proponent of a consistent look and feel across an institution’s web presence, but I do believe that some autonomy of design is important when different departments have different goals and objectives for their web presence. Our library web page needs to have the look of a home page, but yet needs to tie-in to the college site. Once a design is set and the remaining 300 pages that make up the library’s web site have been converted, it is a matter of management and maintenance.

Managing the web site is a daunting task that could take up almost all of my work hours. We have a somewhat decentralized system where some departments within the library edit and create their own pages. They generally work on local copies of pages that I keep on a file server – and send me an email with the name of the file they edited. I check and double check the new pages (and compare them to the old) before uploading the web server. There are of course many issues with this system. One problem that I have with this is the fact that the local copies of the web pages don’t point correctly to the stylesheets and server side includes. People often want to try and fix this by changing links. If they do, I have to make sure that everything points to the correct files again. Additionally, people enjoy adding new content, but don’t really enjoy checking for expired and/or out of date links. The same can be said for new pages and services. We are often charged with a task for which we need to get new web pages up; and yet, don’t visit old pages nearly often enough. This is especially problematic since we do not have dynamic content for subject bibliographies, etc. This is something I need to get in place, but have to implement on my own servers, etc. This means it isn’t an easy thing to accomplish. It won’t happen in the near future – much to my dismay. Hopefully, the college will be moving to a content management system which will make my life easier. Managing a web site is not an easy task, and frustrates me to no end some time.

Web page management and design is one of the areas where I feel least confident. I often try to take classes on CSS, XHTML, DHTML, other languages, new technologies, Dreamweaver, database design, etc. However, there is so much to learn. When necessary, I can usually teach myself what I need to know. This approach works in pieces though – and doesn’t give me the luxury of being able to see the state of our web site and developing a plan for where we need to be. It is also an area where we often decide that what we have is good enough for now. The obvious problem with this rationale is that now extends far beyond the original time frame (ie has it been five years already??). Despite my lack of confidence, I enjoy web page creation and management. I often which I had more time to devote to it, but like many things in library systems, there are times when I feel like my whole life revolves around our web site and times that I have to remind myself that I need to get back to it.

A Day In The Life Of A Systems Librarian – ILS Administrator

September 24, 2006

With Dorothea Salo’s recent TechEssence.Info post on Hiring a systems librarian and recent conversation about the lack of good systems managers on one of the listservs that I subscribe to, I’ve been thinking giving some thought the the life of a systems librarian. I find this job to be an incredibly rewarding one. It is both challenging and frustrating; fulfilling and stressful. It isn’t a library job that everyone would want, but being a systems librarian is a unique way to contribute to the overall mission of a library. I absolutely love my job – but can tell you honestly that I’m having a good week if I only threaten to quit once.

So, many people ask me “What exactly do you do?” First and foremost, I manage our library’s integrated library system. This is our mission critical application – so is the most important service in terms of up time and support from the library staff perspective. If the system is down or unresponsive, I need to resolve the issue ASAP. Like many libraries, we have a vendor that supports the software and the hardware. I am listed as the primary contact with the vendor – and am usually the only one to call for support – exceptions only happen if I am away and unreachable. There are often less critical issues with the ILS. These include questions about the system and how it works, software updates and training staff on new features (generally not formalized). Like most systems, our ILS has a web interface which requires endless editing and tweaking (web pages are never a finished product, right?). This is pretty much a long slow process on which I should always be spending time (and definitely don’t spend enough). We often purchase additional products from our vendor, and I am responsible for configuring and implementing them.

Being the ILS administrator takes about 50% of my time. If I didn’t have anything else to do, it could take all of my time. However, due the fact that I have several other job responsibilities, I can only spend so much time working with the library system. This is one of the difficulties with which I must deal. Time is short and work abounds. Every week, I have to assess the work load, prioritize based on some schema that resides in my head and decide what I need to do first. But ultimately, ILS administration is the most important part of my job, since it is our most important system.