I just finished reading Carlen Ruschoff's column entitled "Competencies for 21st Century Technical Services." Published in the Nov/Dec 2007 issues of Technicalities, it's an 'oldie but goodie.'
One of the cornerstones that Ruschoff suggests we need to build upon is the commitment to being lifelong learners in both formal and informal ways.
She writes:
The person who seeks out opportunities to grown and change is truly valuable, indeed. The person who integrates what has been learned into his or her work is priceless!
As the field of cataloging changes(and man, oh man, is the field changing!), the commitment to being lifelong learners increases in importance. We have to stay engaged in the conversation about the future of Technical Services, but we can only do that if we're in-the-know about current and future trends.
The good part is that webinars and other free resources like blogs and freely available journal articles make it easier than ever to stay informed. The bad news, for some anyway, is that this increased access to free information makes it harder than ever to disengage.
But don't just learn new things, put them into action! Change your workflow. Teach a class. Improve your cataloging. Ask your supervisor if you can incorporate a new format into your work.
Showing both the initiative to learn something new and the willingness to incorporate what you learned into your existing workflow raise your stock in your library. You become someone who takes initiative and someone who is not afraid of change.
Up until my current job, I worked exclusively with Dewey. Every job, from the shelving job I had as a teenager to the paraprofessional cataloging job, was in a public library. So when I started my current job in a library that uses LC Classification, I felt more than a little bit lost.
I love my work and I'm good at it, but using LC Classification has always been my weakest skill.
I got a new supervisor recently, and we started setting my goals for my six month evaluation. I told my new supervisor that I really wanted to be more comfortable with LC Classification. I came up with a plan on how I would do that and she signed off on it.
I'm working my way through Learn Library of Congress Classification (for the second time) and doing some copy cataloging to learn more about how LC Classification works. Hopefully, by the end of the six month period, I'll be a LC Classification-using fool.
My point is, there's always something new that you can learn and always some way in which you can incorporate these new skills and knowledge into your work. And doing both of those things make you more valuable to your library.
Be proactive. Be visible. Be awesome.
Friday, August 13, 2010
Thursday, August 12, 2010
Gorman's "Drift down" theory and Good Enough
I was reading an article and came across the "drift down" theory which goes something like this:
Librarians shouldn't do a job that a paraprofessional can do. Paraprofessionals shouldn't do a job that a student can do. No person should do a job that a machine can do.
I was curious about the origins of this "drift down" theory, so I tracked it back to Michael Gorman. Apparently he debuted it in 1982 in a book chapter entitled "A good heart and an organized mind."
Consider for a moment how terror-inducing this is for modern-day Technical Services librarians and then consider how scary it must've been in 1982. Moreover, think about how forward-thinking that must've been.
It seems like everyone these days is preaching how Technical Services Units need to shape up, slim down, and streamline as much as possible. This time of turmoil is a perfect place for the "Drift down" theory to take hold, right? The best way to streamline your bulky Technical Services Unit is to examine everyone's daily tasks and workflows and see where projects and processes can be whittled down and passed on to someone further down the line to do.
In some ways, I am totally on board with this. Why do the costly double checking of reports when you rarely find errors?
There's part of me too, though, that worries that this zeal for streamlining our workflows and processes has the potential to be costly for users.
I am a big fan of Good Enough. I am a fan of considering what else you could be doing with the time you spend making that catalog record 'just so,' when very few people will notice the work you did. I am a fan of uncovering hidden collections and of doing special projects.
But I'm also in favor of not cutting corners when the trade off between staff time saved and value for the end user is too large. Sometimes it makes sense to have a Librarian do what a machine could could do.
The point is, when you're making decisions to streamline your workflows, slash with a pencil and not a red pen. And keep your users at the center of all of these cost-saving and time-saving measures.
Be proactive. Be visible. Be awesome.
Librarians shouldn't do a job that a paraprofessional can do. Paraprofessionals shouldn't do a job that a student can do. No person should do a job that a machine can do.
I was curious about the origins of this "drift down" theory, so I tracked it back to Michael Gorman. Apparently he debuted it in 1982 in a book chapter entitled "A good heart and an organized mind."
Consider for a moment how terror-inducing this is for modern-day Technical Services librarians and then consider how scary it must've been in 1982. Moreover, think about how forward-thinking that must've been.
It seems like everyone these days is preaching how Technical Services Units need to shape up, slim down, and streamline as much as possible. This time of turmoil is a perfect place for the "Drift down" theory to take hold, right? The best way to streamline your bulky Technical Services Unit is to examine everyone's daily tasks and workflows and see where projects and processes can be whittled down and passed on to someone further down the line to do.
In some ways, I am totally on board with this. Why do the costly double checking of reports when you rarely find errors?
There's part of me too, though, that worries that this zeal for streamlining our workflows and processes has the potential to be costly for users.
I am a big fan of Good Enough. I am a fan of considering what else you could be doing with the time you spend making that catalog record 'just so,' when very few people will notice the work you did. I am a fan of uncovering hidden collections and of doing special projects.
But I'm also in favor of not cutting corners when the trade off between staff time saved and value for the end user is too large. Sometimes it makes sense to have a Librarian do what a machine could could do.
The point is, when you're making decisions to streamline your workflows, slash with a pencil and not a red pen. And keep your users at the center of all of these cost-saving and time-saving measures.
Be proactive. Be visible. Be awesome.
Friday, August 6, 2010
Becoming more visible: a 3-step plan
I just finished reading Bradford Lee Eden's article entitled The New User Environment: The End of Technical Services?
You can read it here (you need a username and password): http://www.ala.org/ala/mgrps/divs/lita/ital/292010/2902jun/toc.cfm
This isn't actually a post about Eden's article, though. What really resonated with me was a quote that he used that came from a 2007 article by Sheila Intner.
She wrote:
Part of the trouble is that the rest of our colleagues don't really know what technical services librarians do. They only know that we do it behind closed door and talk about it in language that no one else understands. If it can't be seen, can't be understood, and can't be discussed, maybe it's all smoke and mirrors, lacking real substance.
I think that Intner points out a real weakness for people in Technical Services. We often end up sequestered in back rooms, removed from both library users and our colleagues. When we do get face time with our front-line colleagues, the burden is on us to show them the impact of our work. It's hard to do if, when we have the chance, we bore our colleagues to death with jargon.
For better or worse, I think it's the job of Technical Services Librarians to make their work seem relevant and important. We need to take away the smoke and mirrors and show the substance of what we do in a way that anyone can understand.
To that end, I offer you a three-point-plan:
1. Be more visible
Attend as many meetings as your schedule allows without neglecting your primary job duties. Does you library have an all-staff meeting? Go! A brown bag lunch series? Go! Use the opportunities to network with your colleagues, especially if your back-room office is at a remote part of the library where no one ever sees you.
Being more visible means that people know your name when you call or email them with a question. It also helps you seem more well-rounded, especially if you attend meetings on topics that don't seem to immediately connect with your work in Technical Services.
2. Create an 'elevator speech' about what you do
Say you sit down next to a Reference Librarian at one of those meetings and you have a few minutes before the meeting starts. If you've taken the time to craft a short explanation of what you do and how you can help that person, the time before that meeting will be more productive than any all-staff email or presentation you might give.
When you're coming up with your elevator speech, lose the jargon. Don't assume that the person you're talking to knows--or cares about--the acronyms that are second nature to you. Your elevator speech should be easy to understand and should focus on how you can make a difference in the life of the person you're talking to.
3. Find an front-line ally who is willing to help you raise your visibility with front-line staff.
In my experience, making a difference in the life of a front-life staff person is the easiest way to forge the kind of alliances that I'm talking about. If you can work a miracle for someone, they'll likely sing your praises to their colleagues.
I think that if you are willing to be visible and to forge relationships with front-line staff, the smoke and mirrors will dissipate and your true value to your organization will shine through.
Be proactive. Be visible. Be awesome.
You can read it here (you need a username and password): http://www.ala.org/ala/mgrps/divs/lita/ital/292010/2902jun/toc.cfm
This isn't actually a post about Eden's article, though. What really resonated with me was a quote that he used that came from a 2007 article by Sheila Intner.
She wrote:
Part of the trouble is that the rest of our colleagues don't really know what technical services librarians do. They only know that we do it behind closed door and talk about it in language that no one else understands. If it can't be seen, can't be understood, and can't be discussed, maybe it's all smoke and mirrors, lacking real substance.
I think that Intner points out a real weakness for people in Technical Services. We often end up sequestered in back rooms, removed from both library users and our colleagues. When we do get face time with our front-line colleagues, the burden is on us to show them the impact of our work. It's hard to do if, when we have the chance, we bore our colleagues to death with jargon.
For better or worse, I think it's the job of Technical Services Librarians to make their work seem relevant and important. We need to take away the smoke and mirrors and show the substance of what we do in a way that anyone can understand.
To that end, I offer you a three-point-plan:
1. Be more visible
Attend as many meetings as your schedule allows without neglecting your primary job duties. Does you library have an all-staff meeting? Go! A brown bag lunch series? Go! Use the opportunities to network with your colleagues, especially if your back-room office is at a remote part of the library where no one ever sees you.
Being more visible means that people know your name when you call or email them with a question. It also helps you seem more well-rounded, especially if you attend meetings on topics that don't seem to immediately connect with your work in Technical Services.
2. Create an 'elevator speech' about what you do
Say you sit down next to a Reference Librarian at one of those meetings and you have a few minutes before the meeting starts. If you've taken the time to craft a short explanation of what you do and how you can help that person, the time before that meeting will be more productive than any all-staff email or presentation you might give.
When you're coming up with your elevator speech, lose the jargon. Don't assume that the person you're talking to knows--or cares about--the acronyms that are second nature to you. Your elevator speech should be easy to understand and should focus on how you can make a difference in the life of the person you're talking to.
3. Find an front-line ally who is willing to help you raise your visibility with front-line staff.
In my experience, making a difference in the life of a front-life staff person is the easiest way to forge the kind of alliances that I'm talking about. If you can work a miracle for someone, they'll likely sing your praises to their colleagues.
I think that if you are willing to be visible and to forge relationships with front-line staff, the smoke and mirrors will dissipate and your true value to your organization will shine through.
Be proactive. Be visible. Be awesome.
Thursday, August 5, 2010
Technical Services Librarians and the theoretical user
I just finished reading Rick Anderson's op ed from September 2005 about the Patron-Centered Technical Services Librarian.
Even though it's nearly five years old, I highlighted most of it and kept shouting 'yes! That!' in my head to nearly everything he wrote.
Anderson's premise is that the ultimate goal of libraries should be "to get the best possible information to our patrons as quickly and effectively as possible, and to do in a way that works best and makes most sense for our particular patrons."
He goes on to say that because of the day-to-day tasks that Technical Services staffs perform, it is easy to think that the ultimate goal of librarianship is a well-managed collection.
I suspect that most front-line staff would say something to the effect of 'well...duh' to Anderson's assertion about the ultimate goal of librarianship. I also think that one point that Anderson doesn't make is that Technical Services Librarians often lose sight of this 'ultimate goal' because they rarely see a library user. Being at least one step removed from end users has the potential to cause the kind of myopia that Anderson discusses.
When you work in Technical Services and don't have day-to-day (or even more intermittent) contact with end users, they start to become theoretical. I know that I have the tendency to start guessing what's best for users when I don't spend time with them. And since I'm a librarian and have librarian-strength searching skills, I probably shouldn't being going all Lorax on our users.
Let me tell you a story...
For the past two semesters, I've worked as one of the class librarian for my University's Freshman Composition program. I am one of about 25 librarians from across our library who volunteers to do this. There are subject librarians, paraprofessional staff who are in library school, and Technical Services librarians who offer a few hours of their time over the course of a semester.
Serving as a class librarian is a low intensity way for me to spend a little time with library users. It's not explicitly listed as one of my job duties, but it's some of the most rewarding work I do.
I teach Freshmen how to search for articles and books on their paper topics; they teach me how the user's mind works. It's awesome.
This past Spring, both of the instructors I worked with asked me to have one-on-one sessions with their students. Over the course of two weeks, I spent 30 minutes with each student.
Boy howdy did I learn something about library users!
That face-time with end users was invaluable to me. I learned how they think, how they search, and what they value. They were no longer theoretical but were, instead, real people with real problems.
My point is that Anderson is right about it being easy to lose sight of the fact that our goal should be to get good information to our users in the way that makes the most sense to them.
The good news is that there are concrete ways to stop yourself from falling into that trap:
Offer to work a shift at your library's reference desk, sit in on a colleague's library instruction session, offer to teach an introductory library instruction session yourself.
Be visible. Be proactive. Be awesome.
Even though it's nearly five years old, I highlighted most of it and kept shouting 'yes! That!' in my head to nearly everything he wrote.
Anderson's premise is that the ultimate goal of libraries should be "to get the best possible information to our patrons as quickly and effectively as possible, and to do in a way that works best and makes most sense for our particular patrons."
He goes on to say that because of the day-to-day tasks that Technical Services staffs perform, it is easy to think that the ultimate goal of librarianship is a well-managed collection.
I suspect that most front-line staff would say something to the effect of 'well...duh' to Anderson's assertion about the ultimate goal of librarianship. I also think that one point that Anderson doesn't make is that Technical Services Librarians often lose sight of this 'ultimate goal' because they rarely see a library user. Being at least one step removed from end users has the potential to cause the kind of myopia that Anderson discusses.
When you work in Technical Services and don't have day-to-day (or even more intermittent) contact with end users, they start to become theoretical. I know that I have the tendency to start guessing what's best for users when I don't spend time with them. And since I'm a librarian and have librarian-strength searching skills, I probably shouldn't being going all Lorax on our users.
Let me tell you a story...
For the past two semesters, I've worked as one of the class librarian for my University's Freshman Composition program. I am one of about 25 librarians from across our library who volunteers to do this. There are subject librarians, paraprofessional staff who are in library school, and Technical Services librarians who offer a few hours of their time over the course of a semester.
Serving as a class librarian is a low intensity way for me to spend a little time with library users. It's not explicitly listed as one of my job duties, but it's some of the most rewarding work I do.
I teach Freshmen how to search for articles and books on their paper topics; they teach me how the user's mind works. It's awesome.
This past Spring, both of the instructors I worked with asked me to have one-on-one sessions with their students. Over the course of two weeks, I spent 30 minutes with each student.
Boy howdy did I learn something about library users!
That face-time with end users was invaluable to me. I learned how they think, how they search, and what they value. They were no longer theoretical but were, instead, real people with real problems.
My point is that Anderson is right about it being easy to lose sight of the fact that our goal should be to get good information to our users in the way that makes the most sense to them.
The good news is that there are concrete ways to stop yourself from falling into that trap:
Offer to work a shift at your library's reference desk, sit in on a colleague's library instruction session, offer to teach an introductory library instruction session yourself.
Be visible. Be proactive. Be awesome.
Wednesday, July 22, 2009
Amazoogle Fail?
The May 2009 issue of Computers in Libraries has a really interesting article called "OPACs and the Mobile Revolution."
The author, Samuel Liston, looked at how catalog interfaces from SirsiDynix, Innovative Interfaces, and AquaBrowser display in various kinds of mobile devices. He tested aCrackberry Blackberry, a Windows Mobile device, and an iPhone.
The test in each was:
1. Does the library own a specific book? (Search from the library's main page)
2. Does the library have a current copy available? (Look at the results page)
3. What is the call no. of the copy? (Look at a full-record view for the title in question)
My short (and snarky) summary of this article is two-fold:
1. iPhones do the best job of displaying at each step in the test.
2. If your users don't have iPhones, they're screwed.
I'm no code whiz, but I know that there is a difference between how a full website views on a mobile device and how 'mobile versions' of a site display. I know this because I can use my Windows Mobile-driven phone to check in for flights on Southwest's mobile site, but you couldn't pay me enough to load the full version on my phone.
I'm guessing, based on the article, that the catalog interfaces in question either don't have mobile versions or the mobile versions weren't tested.
The article concludes by showing how awesomely Amazon's website displays on each kind of mobile device.
(Cue the record scratch)
If libraries want catalogs that navigate more like Amazon (and wasn't that the impetus behind NextGen catalogs?), shouldn't we have followed Amazon's lead and looked at the mobile device-aspect of this equation? It seems like users don't want to be tethered to their laptops and they certainly don't want to be tethered to the machines in our libraries. Theoretically, users want to access our resources from their phones. And, according to this article, they can--but they can only do it reliably if they have an iPhone.
It seems like over and over again, libraries have excellent intentions when it comes to implementing "Web 2.0" ideas in a library setting. And it also seems like over and over again, libraries just barely miss the mark.
I haven't done any kind of research of my own beyond the article, so I'd love to be pointed in the directions of some awesome mobile catalog interfaces. I'm sure they're out there! Prove me wrong, library-land!
The author, Samuel Liston, looked at how catalog interfaces from SirsiDynix, Innovative Interfaces, and AquaBrowser display in various kinds of mobile devices. He tested a
The test in each was:
1. Does the library own a specific book? (Search from the library's main page)
2. Does the library have a current copy available? (Look at the results page)
3. What is the call no. of the copy? (Look at a full-record view for the title in question)
My short (and snarky) summary of this article is two-fold:
1. iPhones do the best job of displaying at each step in the test.
2. If your users don't have iPhones, they're screwed.
I'm no code whiz, but I know that there is a difference between how a full website views on a mobile device and how 'mobile versions' of a site display. I know this because I can use my Windows Mobile-driven phone to check in for flights on Southwest's mobile site, but you couldn't pay me enough to load the full version on my phone.
I'm guessing, based on the article, that the catalog interfaces in question either don't have mobile versions or the mobile versions weren't tested.
The article concludes by showing how awesomely Amazon's website displays on each kind of mobile device.
(Cue the record scratch)
If libraries want catalogs that navigate more like Amazon (and wasn't that the impetus behind NextGen catalogs?), shouldn't we have followed Amazon's lead and looked at the mobile device-aspect of this equation? It seems like users don't want to be tethered to their laptops and they certainly don't want to be tethered to the machines in our libraries. Theoretically, users want to access our resources from their phones. And, according to this article, they can--but they can only do it reliably if they have an iPhone.
It seems like over and over again, libraries have excellent intentions when it comes to implementing "Web 2.0" ideas in a library setting. And it also seems like over and over again, libraries just barely miss the mark.
I haven't done any kind of research of my own beyond the article, so I'd love to be pointed in the directions of some awesome mobile catalog interfaces. I'm sure they're out there! Prove me wrong, library-land!
Tuesday, July 29, 2008
Another tool in the cataloger's trusty toolbelt?
I stumbled upon OCLC'S Classify by way of The FRBR blog's post about it.
Using any number of identifying characteristics (UPC, OCLC no., ISBN, ISSN or Author and/or Title), a user can identify the most frequent and most recent call numbers for both Dewey and LC Classification for a (for lack of a better word) work.
I got really excited thinking about the implications of a tool like this. I couldn't help but think that, sitting next to Worldcat Identities, that this might be the Next Big Thing for catalogers.
Upon further consideration, I wondered what exactly one might do with Classify and the use I kept coming up with was certainly not what OCLC had in mind.
Imagine being a small library without the funding or resources to purchase a copy of DDC. Imagine being able to use a freely available web resources to assign a call number to something you own.
Given the stranglehold that OCLC seems to have on DDC, this was certainly not the intended use for this technology.
But what if it had been?
In light of this argument for setting classification free, Tim Spalding's idea about Open Shelves Classification doesn't seem so radical after all.
A library's ability to catalog it's collections shouldn't be tied to how much money it has. Period. End of story.
It's one thing to choose not to catalog a collection. It's quite another to not be able to because you don't have the means to do it.
Spalding's OCS (well, our OCS, if you take adhere to the truly open nature of "open" anything) puts part of that decision back into the hands of libraries.
I still think OCLC's Classify is a neat and potentially useful tool. And it has the ability to do a lot of good if it remains freely available. But, if it goes behind the wall of subscription services, it doesn't give us a whole lot more than what we've already got or what we can get by way of worldcat.org.
OCLC's Classify: shiny toy or useful tool?
Using any number of identifying characteristics (UPC, OCLC no., ISBN, ISSN or Author and/or Title), a user can identify the most frequent and most recent call numbers for both Dewey and LC Classification for a (for lack of a better word) work.
I got really excited thinking about the implications of a tool like this. I couldn't help but think that, sitting next to Worldcat Identities, that this might be the Next Big Thing for catalogers.
Upon further consideration, I wondered what exactly one might do with Classify and the use I kept coming up with was certainly not what OCLC had in mind.
Imagine being a small library without the funding or resources to purchase a copy of DDC. Imagine being able to use a freely available web resources to assign a call number to something you own.
Given the stranglehold that OCLC seems to have on DDC, this was certainly not the intended use for this technology.
But what if it had been?
In light of this argument for setting classification free, Tim Spalding's idea about Open Shelves Classification doesn't seem so radical after all.
A library's ability to catalog it's collections shouldn't be tied to how much money it has. Period. End of story.
It's one thing to choose not to catalog a collection. It's quite another to not be able to because you don't have the means to do it.
Spalding's OCS (well, our OCS, if you take adhere to the truly open nature of "open" anything) puts part of that decision back into the hands of libraries.
I still think OCLC's Classify is a neat and potentially useful tool. And it has the ability to do a lot of good if it remains freely available. But, if it goes behind the wall of subscription services, it doesn't give us a whole lot more than what we've already got or what we can get by way of worldcat.org.
OCLC's Classify: shiny toy or useful tool?
Wednesday, April 30, 2008
"How" versus "why"
Eszter Hargittai, sociologist from Northwestern University, is interviewed in the "Wired Campus" section of The Chronicle of Higher Education. You can find the interview here.
She asserts, in this interview, that students aren't as Web savvy as we believe that they are or as they claim to be.
Hargittai makes an argument throughout this interview that loses me. She seems to be arguing that because users don't know how technology works that they are Web-skills deficient.
I read this interview think that she was trying to make the argument that it's like having keys to a car without ever having had any formal instruction on how to drive.
Students are taking their cars on the road and learning how to drive by successfully (or not) making it to their destination.
A student learns how to navigate the Web through successful (and unsuccessful) searching.
I buy that. What I don't like is that she seems to imply that the job of instructor or librarian is to to teach the student the mechanics of how a particular tool works instead of why a user should use this tool to access information.
It's teaching the user how the car works instead of how to drive it.
Hargittai says "Most students don’t know that wikis can be edited at that moment. Their eyes just open up wide when they find out."
I'm not sure the how of Wikipedia matters much to most users. Maybe it should, but it doesn't.
I think that what's more important is the why, especially when teaching students to look critically at Wikipedia as a reference source.
The how is the mechanics of the car. The why is the Driver's Ed. lesson.
Earlier in the interview, Hargittai also says "Ask your average 18-year-old: Does he know what RSS means? And he won’t."
I appreciate her question, but I think she's asking the wrong one. Instead of asking a student what RSS means, ask him if he uses Bloglines or Google Reader to read some of his favorite blogs. I suspect the answer might be "yes."
Should we spend our time, then, explaining the how of RSS? Or should we teach students the why of RSS: how to use feed readers to subscribe to sources of information that might be useful to them?
Again, it's teaching a user how the car works vs. teaching the user how to drive the car.
It is true that as librarians we might be more tech savvy than the users we serve. We should know how each part of the car works in order to help our students drive it better. But I think the burden of learning how the car works lies on us.
The truth is that even if users don't know how technology "works," they're using it. So, it's our job as librarians to help empower our users to be better consumers of information. We may never move from teaching students the why of a technology to teaching them the how, though we may aspire to.
But why, not how, is where we should start.
She asserts, in this interview, that students aren't as Web savvy as we believe that they are or as they claim to be.
Hargittai makes an argument throughout this interview that loses me. She seems to be arguing that because users don't know how technology works that they are Web-skills deficient.
I read this interview think that she was trying to make the argument that it's like having keys to a car without ever having had any formal instruction on how to drive.
Students are taking their cars on the road and learning how to drive by successfully (or not) making it to their destination.
A student learns how to navigate the Web through successful (and unsuccessful) searching.
I buy that. What I don't like is that she seems to imply that the job of instructor or librarian is to to teach the student the mechanics of how a particular tool works instead of why a user should use this tool to access information.
It's teaching the user how the car works instead of how to drive it.
Hargittai says "Most students don’t know that wikis can be edited at that moment. Their eyes just open up wide when they find out."
I'm not sure the how of Wikipedia matters much to most users. Maybe it should, but it doesn't.
I think that what's more important is the why, especially when teaching students to look critically at Wikipedia as a reference source.
The how is the mechanics of the car. The why is the Driver's Ed. lesson.
Earlier in the interview, Hargittai also says "Ask your average 18-year-old: Does he know what RSS means? And he won’t."
I appreciate her question, but I think she's asking the wrong one. Instead of asking a student what RSS means, ask him if he uses Bloglines or Google Reader to read some of his favorite blogs. I suspect the answer might be "yes."
Should we spend our time, then, explaining the how of RSS? Or should we teach students the why of RSS: how to use feed readers to subscribe to sources of information that might be useful to them?
Again, it's teaching a user how the car works vs. teaching the user how to drive the car.
It is true that as librarians we might be more tech savvy than the users we serve. We should know how each part of the car works in order to help our students drive it better. But I think the burden of learning how the car works lies on us.
The truth is that even if users don't know how technology "works," they're using it. So, it's our job as librarians to help empower our users to be better consumers of information. We may never move from teaching students the why of a technology to teaching them the how, though we may aspire to.
But why, not how, is where we should start.
Subscribe to:
Posts (Atom)
