Teaching students how to find information

Part of my job will be teaching students how to find information. Most folks these days would say "How easy is that -- they already know how "to Google" so there's not much left to do." Uh. Yeah. Right.

While I agree that Google has turned the world into information searchers, there is a lot we can teach students. Our Library Instruction librarian, and the other librarians, are modeling for me what this can look like. A quick example: explaining the difference bewteen popular and academic sources of information (evaluating the quality of the information, as well as how well it meets the research need). Another example cropped up in an article from Library Instruction Round Table News (June 2009, p.9). The author had been teaching users for years but had never been successful in helping more than a quarter of his students understand the concept of Boolean logic. He finally found he reached more of them when he used the example of ordering fast food (burger AND fries; regular OR curly fries; Coke NOT Pepsi). By tying the concept to a real-world scenario most students were familiar with, many more of them "got it".

Maybe not the most earth-shattering revelation, but I love the idea that part of the mission of most libraries is to teach information literacy.

ALA | ALA 2009 Annual Conference Registration

I am looking into attending the annual conference of the American Library Association. This year, it will be in Chicago. There are a number of topics of interest to me in the role of a Web Management Librarian, especially a pre-conference session on using web technologies (mashups and APIs) to deliver web-based library services.

ALA ALA 2009 Annual Conference Registration

Shared via AddThis

I find myself thinking back to my days at the University of Michigan School of Information. Back in late '93, we were getting our first taste of the web. I was a student in the school's first course on Internet Resource Discovery and Organization. I worked with a great fellow student, Sheryl Cormicle, to create a guide to Neuroscience resources on the web. We were only required to submit a printed listing of our guide (which we did, and which was eventually published in a book), but more importantly, we created a web-based guide. I wish it was still visible online somewhere, but 1993 might as well be 500 years ago in Internet time...

[Update]
SWEET! With a little determined searching (using Microsoft's new Bing search tool), I found a copy of it here. Sadly, it is just the text version (rather than the HTML version), but it still makes me proud to see it. Sheryl and I felt like pioneers in a new world, and seeing this artifact from that time makes me feel a little like an archaeologist who finds the intact remains of a stone-age hut beneath the streets of a 21st century city.

Wiki progress despite confusion setting up WetPaint administration

We decided to go with WetPaint for the trial run and three of us (E., D., and S.) met last week to work together to go through the initial set up together. Our requirements are that the web site must be private (not viewable by anyone other than those we authorize), and that anyone authorized can use the site (add pages, edit pages, and post comments in the discussion forums). Preferably, all of us who want to use the site would only need to know a single login name and password. The first two requirements were easily met, but the third caused a problem.

WetPaint's user interface is straightforward but even so, you must associate a user account with an email address. We didn't have a common email address available, and we didn't want to tie it to something like an "info@" or "webmaster@" address, so that meant the single logon user account we wanted to use would have to be tied to a specific individual's email address. We also wanted the single user account to have full administrative privileges. We used E's work email address for the main account.

After we created the account and starting page (a process needing a mere two or three clicks) WetPaint then asked us to invite others to join the page. By inviting others to join, it made them members. Members can be assigned editing privileges. This conflicted with our initial requirement of using just a single user account and login. We soon realized, though, it would be a "good thing" to have each librarian be a member, and sign in under their own account, so that whenever they edited pages or posted comments, we would know who said or did what.

So we sent invitations to join to the work email addresses of the other two librarians (D and S). That's when WetPaint did something odd. We were working on D's computer, and when D accepted the invitation to join, because we were already logged into WetPaint on D's computer, WetPaint changed the email address associated with the main account to D's email address instead of E's! Odd, confusing, and totally unexpected.

When we sent the invitation to join to D and S, we had only given them "authoring" permissions, not site adminstration permissions. We wanted to change this and made the mistake of having D "leave" the site -- meaning, no longer be a member. We clicked one button and voila, D was no longer associated with the site -- but then we realized WetPaint just allowed us to do something bad: we deleted the only account which had been given administrative privileges to the site!

After a few minutes of discussion (and searching WetPaint Help) we quickly decided to abandon the first site and start fresh. Lesson learned? We should have more fully investigated WetPaint's site creation features, workflow and requirements before diving into creating our site. What is disconcerting to me is that WetPaint's interface appears so easy-to-use and clear, that I felt lulled into a false sense of mastery. I just assumed WetPaint would guide us appropriately and especially not let us make the kind of mistake we made in removing the only account which had been given site administrator privileges!

Next time, more about project progress.

Reference Desk Wiki

One of the projects underway at the UHD Library is development of an internal "wiki" as the source of information and practices for use when staffing the library's reference desk. The idea, of course, is to create a central location for the information that librarians may need when assisting patrons. The library currently has a binder for such material, but migrating its content to a wiki provides a number of benefits -- searchability, ease of maintainance and updating, multiple authors, content control, as well as the possibility of storing conversations and discussions about the content.

The wiki is expected to be hosted externally. My colleagues have pointed out several cool resources such as SquareSpace (a web hosting company with a beautiful design aesthetic and tools), and WikiMatrix.org (great site for comparing wiki hosting offerings across many vendors). However, it's looking like the free 'community web space' hosting site, Wetpaint, may best meet the project requirements. I've recommended that we try a pilot project or prototype using Wetpaint so we can learn more about what we like or don't like, need or don't need, for the wiki.

First Morning

It's June 8, my first day at UHD! This feels more like a twitter-style posting than a blog post, but I'm delighted to find that when I got here at 7:30, folks were here and ready to go. I'll be in UHD new employee orientation until some time this afternoon, then begin following up with my list of tasks -- already more than a handful of things to get working on.

I have a list of 30+ books and resources I am interested in reading related to library web sites, design, and organizing information. My first impulse was to purchase them for a personal library, but when the cost hit over $1300 on Amazon, I switched to a "borrow it" way of thinking and was amazed to find most everything I wanted was available in the UHD or UH-system libraries!