Technology Planning

In the last week or so, I’ve seen three pretty cool things:

  1. John Blyberg’s post about how to overcome the tech deficit
  2. Glenn Peterson’s new project, EngagedPatrons
  3. Sean Robinson’s project, the PayITForward web wiki

Blyberg always has good stuff to say – you should go read his post, and let it soak in. There are plenty of good ideas to be had there. And to me, the best thing he says is this:

“Look at where your patrons are spending their time, get a sense of what they want and need. It may be that your community is happy with what you’re doing, or it may be underwhelmed by what you’re not. As always, identifying what they want should drive spending, it shouldn’t be the other way around, where patrons are forced to use what we’ve spent money on.”

Glenn Peterson, web dude at Hennepin County Library, has started EngagedPatrons.org as a way to “provide website services connecting public libraries and their patrons.” Right now, EngagedPatrons is offering a variety of hosted services to libraries, including: Library events, library blogs, contact your library forms, RSS feeds, and custom web-enabled databases. Use the site’s handy contact us form for more info.

More from Glenn (via an email Glenn sent me – yes, Blyberg, you scooped me! Dang, I’m slow… :-) -

“I’m offering to host website services for public libraries at my site and to assist libraries in customizing the services (via options I’ve built into each application) for their needs. Libraries will input data, about their upcoming events for example, using web forms I’ve built and the data will be stored in a database on my server. I’ll also assist libraries in storing the HTML for their site’s navigation in the database and integrate my code with the look and feel of the library’s own website. Libraries will link from their site to mine for the services they have chosen.The patron won’t know they are on my site – the pages I host will appear to be hosted at the library…”

Now on to Sean Robinson’s PayITForward project. From the wiki:

“This idea surfaced at the Ann Arbor Library Camp. Pay “IT” Forward.
There are lots of Public IT library professionals struggling to
implement technology. Sometimes the IT department at a library is made
up of one person. We have limited budgets and limited time. The
question was asked “What would happen if we shared our expertise with
each other?” This idea then grew to “What could I do?” “

I believe (Sean or someone else, correct me if I’m wrong) the idea is for library IT professionals to share their knowledge about whatever on the wiki. This way, library techies can start building a sense of larger community – and of course, get those techie projects done!

So – lots of extremely cool stuff related to library websites and library technology this week. Keep it up!

Be the first to comment

10 Reasons to Love Web 2.0 – from a Flickr Dude

by David Lee King on March 15, 2006

These are notes I took while listening to a podcast of Cal Henderson from Flickr, titled “From Web Site to Web Application – Ten Reasons to Love Web 2.0.”, who spoke at “The Future of Web Apps” conference. You can find it (and a lot of others) on the Carson Workshops/Summit website.

 Cal’s definition of web 2.0: “Web 2.0 is a name for a bunch of new web-based applications.” Simple enough…

 10 Reasons to love web 2.0:

1. Collaboration

  • sharing photos with a social network
  • collaborative metadata (tags)
  • Allows others in one’s social network to do the tagging for you

Me here – this is something library websites can offer to our users (ie., aadl.org as one example of collaboration).

2. Aggregation

  • shows latest information (he called aggregation a “slice”)
  • Also slice by tags, user, groups, and interestingness)

Me here – We can do aggregation – either with normal blog applications, like WordPress, or by custom-coding an RSS feed (like Kansas City Public Library).

3. Open API

  • Web services API…
  • SOAP, COBRA, REST (me – I don’t know anything about the last two…)
  • Flickr built an API because THEY needed it – it helped them in their work of building and customizing Flickr
  • It’s read-only data
  • allows people to build new things, do mashups, etc.

Me – OK… most of us probably can’t build an API – but never fear! I think many of the vendors we work with will eventually offer some form of API.

 4. Clean URLs

  • “Don’t expose the guts of the application!”
  • Mod rewrite under apache – use it
  • Then – support the URL forever

Me – we can achieve this with our websites – but we’ll have to wait on the vendors… have you ever seen a SIRSI URL to a book? Egads!!!!!!!

5. AJAX

  • Jesse James Garrett named it
  • Javascript and XML mix
  • the underlying page doesn’t really reload – just the application (me - seems like a little thing, but really – that’s huge)
  • it remove’s page loads
  • streamlining

Me – we can do this, if we take the time to learn ajax and figure out what it can do for our websites.

6. Unicode

  • internationalization
  • localization – translation to other languages
  • store data in unicode – easier to translate should you decide to
  • UTF8
  • He said “this bit’s getting a bit nerdy, isn’t it?”

Me – What in the world is he talking about?

7. Desktop/Platform Integration

  • How do we pull out interactions?
  • based on API
  • RSS = read only API
  • desktop apps – the Flickr Uploadr interacts with the web app
  • Browser apps – bookmarklets
  • mozilla – toolbars, etc
  • integrating app with email – send photos via email

me – we can do some of this, too. Kansas City Public Library has RSS feeds and a “send article via email” thing. Other libraries have created bookmarklets and toolbars for their patrons. We’re just lacking the API part.

8. General Mobile Integration

  • WAP is dead.
  • XHTML mobile profile 1.0 (me – apparently, it’s really called that) – sensible standard. It’s a cut down version of normal XHTML
  • think in smaller chunks

Me – we can do mobile! Or… we HAVE to do mobile. Our customers are already there – shouldn’t we be, too?

 9. Open Data

  • import/export of data
  • RSS = Export
  • Import = allows customers to easily escape if they want to
  • it’s your (the customer’s) data and you can take it with you
  • export to DVD – just built it on API

Me – ok, this is another hard one for us. But before we conquer this, we’d need to conquer the whole privacy of info thing first. SInce we try to not save much patron information in the first place, we really don’t have that much to give back if requested.

10. Open Content

  • old way – once you upload it, Google owns it
  • New way – when you upload it, you still own in
  • Creative Commons license

Me – see my comments under #9 above… same idea here.

web 2.0, library 2.0

4 comments

Michael just blogged a wonderful post on things techie librarians need to know about in 2005. It’s a great read, and I agree – definitely all stuff librarians should know about. I’m going to comment/piggyback off two of the points (’cause they made me think)…

So for the first one: User-Centered technology planning. Michael focused on making sure technolust does not guide technology planning at the library (very important point). Rather, we should find out what our users need/want, and try to provide that. But what about the flip side of that coin? I know libraries and librarians who’d say something like this: “I don’t want to blog/wiki/IM/etc, so I think we’ll not make that a priority this year.” Or “my staff aren’t there yet, so I think we’ll hold off on that one indefinitely.” Bad, bad librarian!

The goal should be user-centered technology planning. If, for example, your library serves a hip urban community of teens who IM and SMS all over the place, by all means… figure out a way to incorporate that into your library’s planning! Even if your library has never done it before. Don’t let “Techno Avoidance” or “Techno Huh?” drive your library. Instead, find out what your users are wanting to do (or already doing frequently), and try to provide that.

Another way to look at it – if your library has a website (and most do these days), don’t think this: “There. We set up our website. Now we can check that off our list and move on (unfortunately some libraries do this, too).” WRONG! Websites are living, breathing entities, and need to be “cleaned, bathed, hugged and loved” (to quote a favorite children’s story I read to my kids). Effective websites require constant updates and maintenance.

The point here? Well, how about three points:

  1. Dont’ be scared of the technology your customers use. Instead, figure out a way to make it work at the library.
  2. If you plan to do anything techie – then jump in with both feet and plan to be there for the long-haul.
  3. If your staff doesn’t know how to do some of this stuff – find training for them. In fact, make that a training priority in 2005 for staff. Most of this is pretty easy to grasp (or, maybe I’m showing my techno bias here), and training sessions on blogs and IM should be relatively easy to set up.

So put on your 2005 thinking cap and get started!

9 comments

Library Journal – Technoplans vs. Technolust

by David Lee King on November 4, 2004

Library Journal – Technoplans vs. Technolust

Cool! Michael Stephens, Special Projects Librarian at St. Joseph County Public Library and blogger for Tame the Web, wrote this article for Library Journal’s netConnect… and quoted me! How cool is that?

It’s also a great article with some very good pointers for creating and implementing technology plans. Read it!

Be the first to comment

Swiped from Tame the Web: Technology and Libraries: Planning for a New Tech-based Service — Try these.

Five “Must Haves” when planning for a new technology-based service:

Creating policy
Acquiring the Technology
Staffing
Training staff
Promotion

Think about it – can you have one without the other? Let’s see:

No policy – nothing will happen on the staff side, and customers will get irate because nothing is consistent

Getting the technology – can’t do it if you don’t buy it!

Staffing – who’s going to run this in his/her spare time? Most library staff already do this, I suppose… but at the least, the new service will be mediocre if it’s not adequately staffed.

Training Staff – staff HAVE TO understand how to run the new service, what to do when problems happen, etc. They also have to understand how to teach the new thing to customers (more on this in a sec)

Promotion – why spend all that money if the service isn’t promoted? Why waste staff time if it isn’t promoted? Technically, this point can be forgotten if the service is cool enough – word of mouth travels pretty fast.

But – one thing that the author forgot is Training Customers. Possibly, this was supposed to fit into the “training staff” part… but I think it’s important enough to make it a separate focus. Customers won’t use it if they don’t know how. Training them is essential.

All for now!

Be the first to comment