On Subject Guides, Creativity and Professional Worth

Pre(r)amble

I've been a "real librarian" for 14 years now, and it seems as though during that entire time I've been involved with the Subject Guide Issue. Almost as soon as I started my first job I got involved in the HealthWeb project, which started with a well intentioned and triumphant bang but eventually ended with a quiet whimper in the face of the Two Point Oh onslought. I was briefly enticed by the OCLC CORC project during the HealthWeb days, but this was before the spirit of sharing and trust (that 2.0 stuff again) was in fashion, so that didn't go far. When I made the change from reference librarian to information architect or web developer I thought maybe I could make faster, stronger, better subject guides by supporting librarians who wanted to create the content for them - I still do that to some extent but let's just say that hasn't scaled very far. It seems that in all cases reference librarians want to be able to create these "subject guides" (or research guides, or pathfinders, or link lists, or link farms, or...) quickly and easily, find some magickal way to automate the maintenance (i.e. link checkers and such), and still do other things like answer reference questions. In some cases this has actually happened, but in others (most in my experience) it hasn't. Here's some reflections on why that may be:

The Voicemail Issue


The rise of telecommunications and information technology has led to the centralization or "place shifting" of services. Call centers could be located on the Moon with fast enough connections and access to the necessary information. But people are expensive and needy, so the next step in the march of progress is to automate things or take people as far out of the equasion as possible - hence its common for you to be literally unable to find a local telephone number or address for a company and can only speak to a live person after being triaged by a machine of some sort. In some ways I see the subject guide as the library response to this - on the one hand I think most reference librarians love to interact with patrons, but if they can't they want to lay out all the possibilities available in answering their questions on these guides for patrons.

This creates something of a conundrum - fresher, higher tech subject guides now provide tools like chat widgets for patrons to just ask a question directly, even if using a web browser rather than a telephone. But these subject guides are created by "subject specialists" - how often are they actually available to answer questions which come in from their guide? ("Please call back during business hours"). There is also the issue of a large amount of content on many of these pages - it seems to be a cue to the users that there's a lot of resources available to help them with their subject, perhaps they just haven't taken the time to explore them all before giving up and asking for help. So I guess my takeaway observation is "less is more". Just like I shouldn't need a paper and pen to write down all the options in Voicemail Hell because there are too many to remember, there shouldn't be so many options in a subject guide that I have trouble telling if I've checked enough of them to know I'm not going to find my answer myself.

The Personal Worth Issue

I don't want to get too snarky here, but I have a psychology background and have no personal life at the moment so its sort of unavoidable :-). I just can't shake the conviction that some of the more voluminous subject guides out there aren't really a tool to help people answer questions so much as an expression of one's personal worth or prowess as a librarian. The impulse is almost always to add one more resource rather than remove one. The rationale is "it might answer that one obscure question", and indeed it might, but the overall effect is to drown the signal in a sea of noise. If you can come up with some way to design for the Long Tail as websites like Amazon do then fine, but most guides are more like voicemail - more options, more confusing navigation, and ultimately more frustration. I say this as someone who's experienced this on the creative end as well as the user or patron end. If your guide has so many tabs it needs subtabs, and you need to add order to the subtabs to make it all clear, um, perhaps you just have too much content?

Its really an issue that affects web design in all areas, but I think it hits home particularly hard for librarians. We pride ourselves on our resourcefulness and tenacity in answering questions but there's one catch here - nobody has asked a question yet! So much like our legendary FAQs we wind up creating "inventories of all possible questions people might conceivably ask us" (we really do have OCD at a professional level, most of us). We are trying to answer as many different questions as we can before anyone has asked, just like a voicemail system. The idea of providing an actual list of top resources in a subject area for when there's nobody around to answer those questions does, of course, make sense. We're not always open, people do wait til the last minute to write papers and submit grants, and some people (yours truly included) often prefer to try to answer a question ourselves before asking for help. Its really a question of proportion. So, again, the takeaway is "less is more". I'd think more highly of you as a librarian if you only pointed me to the best of the best, but were there to gently let me know (even if only virtually) that maybe its time to let a professional find that answer.


How Buildings Learn, or If You Build More Will They Come More?

There's a great book by Stewart Brand which, while apparently about architecture, took the Information Architecture field by storm (enough to get him to give us the keynote at the IA Summit in 2003). Its called How Buildings Learn and while you should read it for yourself there's one idea in particular that keeps resonating for me, in librarianship or web development or really any service-oriented creative act (i.e. our entire profession). Its the idea that an architect builds a building for the future occupants and visitors, not for themselves. Often "real architects" and information architects (or librarians) fall into the same trap of building something based on how they think it should be rather than for the people they're building it for. That's exceptionally easy to do when creating web pages because unless you're doing it for hire (and I mean really for hire, like you're a professional designer/developer) you don't really have people giving you input throughout the process, let alone after its "done". And while, of course, you are the Professional and do have Great Experience you are still bulding something to be used by other people.

Which is why the Field of Dreams quote is perhaps my least favorite quote of all time (it was a movie, folks, and a fantasy movie at that ;-). I get the impression that people really do get swept up in the Subject Guide of Dreams idea and that if they just added one more thing, had one more link pointing to it, or tweaked their guide just a little more and then wished hard enough somehow they'd get more traffic. I guess the analogy I use is more the WalMart or Arena Rock one - if its so damned big and crowded that you need a shuttle bus to get to it is it really worth it? Well, maybe its not quite that bad but I really do get the feeling that people think the potential non-use of subject guides is an issue of "its not done yet" or "we need to market it more" or the dreaded "maybe we need more guides/subjects" and the like. It could be that there's just not much of an audience out there for it and never will be. Yes, it may be a useful tool - esp. if maintained and you accept feedback or input and (crucially here) you actually get feedback or input. No news isn't necessarily good news (we've all probably seen that classic customer service movie "Remember Me"). I hate to be a curmudgeon here but its quite possible you could spend your whole career building it and nobody would ever come. And passive expectations that people will let you know why they aren't finding your guides helpful are unlikely to bear much fruit.

The other part of the If You Build It idea that drives me crazy relates to a second idea from How Buildings Learn - that a building is a living entity. Once you build it that's the beginning, not the end. Its never "done". People focus so much on getting subject guides up that they forget that, like kittens, they're not "free" - each one requires ongoing care and feeding and love. Which is why the "link checker" idea strikes me badly - link checkers aren't terribly reliable, and only alert you to technical problems. Subject guide editors really should check the links in their guides regularly to see if the resources they link to are up to snuff content wise, not just still there. It depends on the resource of course, but the people who seem to want automation in the maintenance of their guides also seem to be the people who tend to the "more more more" approach. If you build a guide you can't possibly devote enough time to maintain is that a smart use of resources? Perhaps its better to have something smaller, more easily maintained and that gets regular use and input from real users, not a bloated corpse that just sits there "just in case" the right info scavenger should happen along.

Conclusion

Much like many journalists appear to be frustrated authors, many library subject guide editors appear to be frustrated reference librarians wondering why people aren't taking advantage of all the great things they know. And I share your pain, really I do! I guess I just think that a few things need to change. First off, lose the Field of Dreams quote :-) Secondly, do some research into the actual usage patterns of your users so you can get an idea of what your real primary audience wants or needs (the web expands your potential audience to the entire human species, which could make your subject guide way too long to be useful in any subject area). Lastly, do try take the "less is more" idea to heart - rather than trying to show how much you know or how resourceful or clever you are try being merciful and respectful of the user's time. "First, do no harm" as the doctors say. The ideal guide would have a reasonable number of resources, well designed and arranged and checked frequently, with the ability for users to give input easily and would then guide users to a real live reference librarian should those resources not do the trick. I'm starting to see signs of hope in the input and referral areas, but the trend toward creating more and longer guides still seems to be raging unabated. Research is starting to show quite clearly that most users don't find the comprehensive lists useful (or even usable) so don't put those up front, despite how creative and competent it may make you feel. "But wait, there's more" is far more compelling than "here's everything I know on this subject, in bone-crushing detail and meticulously organized".

On Competition, Creativity & Credibility

In the good olde days of the Internet (say 1995 - 2000) the library profession used to teach courses on how to evaluate a good website - things like clear statements of responsibility, the "authority" of the producer of the information, how often things were updated, etc. It made sense because it used to be fairly hard to publish content on the Web, and harder still to have much of it and keep it up to date. Doing so at all was a pretty good sign you were earnest and cared, and if people could get ahold of you with suggestions or corrections you were golden. (While ideas like HONcode were good ones I'm not so sure I really believe they ever did much to make or break a health website - good design and updated content seemed far more important).

Fast forward a few years and suddenly the ability to create and maintain a website becomes much easier, esp. with the advent of blogs. Even building a database-driven site (usually necessary for large amounts of content) became more trivial with the availability of open source scripting and database tools (i.e. PHP and MySQL). Then several years later some clever people started adding more interactivity and dynamism to websites with things like AJAX and Flash, which made websites start to act and look more like desktop applications. Suddenly what people had been saying years ago about websites supplanting their competitors, even desktop application competitors, started to come true. Upstart companies came out of nowhere and wound up changing entire businesses (witness the decimation of the travel agent when sites like Travelocity, Orbitz and Priceline really caught on).

Libraries and other information providers haven't been used to competition, and are finding it hard to adjust. Some clever programmers have come up with websites which provide the sorts of information tools libraries or library vendors used to provide exclusively. Often these new tools work "better" than traditional ones in the sense of being more intuitive, up to date, etc etc. Some tools provide reference-type information (i.e. Google Maps) while others provide library-like services for individuals rather than libraries (i.e. LibraryThing). These newer tools may not be as robust and authoritative as the older tools but they work, they work fast and they work painlessly - in short they provide a good user experience.

The future of library applications is, hopefully, going to be in a sweet spot between all the fun and easy to use interface things you see in "Library 2.0" and the more structured, robust, authoritative tools we've known and loved as a profession for years. I find it ironic that in the years prior to fast, cheap computing power and unlimited storage space librarians did an excellent job structuring data and providing some level of control, or at least good ideas for where large data sets could get unwieldy. In short we thought like computers before computers were ready for us - making data clean and interoperable and thinking ahead to prevent problems with systems that wouldn't scale. Now that cheap ubiquitous computing is here we're sort of asleep at the wheel, letting our lunch get eaten by people who do good programming and sometimes good interfaces but haven't thought ahead to what happens when their neat mashup becomes the next big thing. Looks like a perfect opportunity to me - combine the energy and new ideas with some way of making the thing scale and work together with other tools and systems (and making sure we bring our vendors along for the ride) so we can "leapfrog each other" and come up with easy to use, fun but useful and robust systems. What the Michigan Public Library system did by building a new interface on top of their ratty old OPAC's core system (same thing at NC State) is a good paradigm shift in my book - and eventually we can get rid of the old legacy systems underneath when they're no longer needed. An OPAC makes a great back end but a terrible front end in my experience - let's use the best of both worlds so we can have friendly competition, creativity and credibility.

On Vocabulary & Language

Controlled vocabulary - sounds like a great idea, esp. for computer systems (which don't handle ambiguity well). However the first decade or so of assessing website usability shows that differences in language are perhaps the single most difficult thing to get right when doing website design. I say "interlibrary loan", you say "document delivery" and administration or PR wants to call it "WhizBangPlus" (the older WhizBang Classic being something of a disappointment in initial user testing). Coming from a health sciences background I was used to singing the praises of MeSH and figured that all disciplines had such a tool, so why wouldn't we use it? We could even do some clever search engine tricks like synonym rings so if a user searched for "cancer" they got "neoplasm" too.

When first getting to meet other website designers I was horrified to learn that they had a best practice of creating a controlled vocabulary (if they were really good at their craft/trade) for each and every website! A virtual Tower of Babel - horrors! Then as we talked more it quickly became apparent - many other disciplines don't have the luxury of a MeSH. And even if we were talking health sciences there were many terms having to do with site navigation or the particular community which uses a particular website (i.e. a school, professional organization, patient support group, etc) that each site really might warrant its own limited vocabulary - after all if the users of your site call things something doesn't it make sense to also call it that thing? Do we really think we can "train them" to use "the right language"? I heard a story about a developer somewhere large (Intel?) who said the reason people couldn't find anything using their search engine was because they were "typing in the wrong words". Guess again, fair developer! We need to understand how they think and what language they use, nice as it would be for that to work both ways. Much like the OPAC being an excellent back end system for storing information about books, journals, etc a controlled vocabulary like MeSH is an excellent system for cataloging or classifying information in general - its just not good for everyday conversation, and most likely not the way people will be thinking when looking for things on a website.

Peter Morville, in his Ambient Findability book, talks about the rise of tagging at sites like Flickr and how the practice has caught on like wildfire yet hasn't exactly started to transform the way people find things other than at a pretty casual level. Its nice to be able to look at all the "German Shepherd Dogs" or "Bush Coronation" pictures but such an informal and idiosyncratic system is unlikely to replace a powerful set of descriptors like in MeSH anytime soon. But people can *use* tags without 3 days of MEDLARS training or special software so they do. Peter points out that there's a convergence likely to happen in the future, where unstructured vocabulary (like tagging or search engines that only look at keywords without any weighting or structuring like inside HTML tags) and structured vocabulary (like MeSH) learn to co-exist and even feed each other. Tags are potentially an excellent source of research for how people talk about things and the more common tags could be added to search engine synonym rings. They could also speed up the development of controlled vocabularies by fast tracking new terms which aren't just trendy but are actually useful and widely used to get them into our systems faster.

Robert McNeill's excellent documentary The Story of English (sadly out of print, hopefully coming soon to DVD?) is a great starting point for showing how dynamic language is, and how attempts to lock it down too far (i.e. The Queen's English) are doomed to fail. Recent years have seen normally staid publications like the Oxford English Dictionary starting to add words like "blog" and "bling" at a much faster pace than they used to. Seems like its time for libraries to loosen up and speed things up a little and start using some of this unstructured vocabulary to our advantage, to help our patrons use our websites better and, ultimately, find what they need faster and more painlessly. George Lakoff (of "Fire, Women & Dangerous Things" fame) reminds us that language and categorization are at the heart of how we make sense of the world as humans. If language itself is in a period of great churn we'd be wise to figure out how to use that to our advantage. Perhaps we librarians can come up with a way of allowing the churn to be our little petri dish in a laboratory and out of that come up with great easy to use systems that modern users can relate to. What we probably will never succeed at is "training" them to use our version of a controlled vocabulary as a way to find information quickly. Our controlled vocabularies are a great back end tool for configuring search engines and other software to quickly and efficiently retrieve information - but our users need to be able to talk to these systems or they may as well not exist at all.

On Wisconsin!

Just had to say that, sorry. Go Badgers!

On Collaboration

Collaboration, collaboration - seems like such a good idea. "All of us are smarter than one of us" as the saying goes (or in a very perceptive counterstrike I ran across "One of us is smarter than all of us"). Is it the wisdom of the crowd or mob rule? Exciting emergent behavior from a group of like-minded folks or the tragedy of the commons? Well, I could go on like that forever but here's my take as it deals with tech projects and libraries.

Collaborative efforts are largely a good idea - frequently to accomplish something big and sustainable its unreasonable to expect one person to do it all. The question is how do you collaborate effectively and at what points of the project? Clearly the brainstorming phase is a good one (was going to say no-brainer but that would be unfortunate). Clearly its good to have people able to divide up the work, evenly if possible but at least according to their talents and interests if not. My experience is that collaboration fails largely in the design and management areas (and, as a result, sometimes in implementation).

Let's start with the idea of the structure of the collaboration. It seems there are some really neat things out there coming online that start with little or no structure - literally Two Guys (or Gals) and a Garage. While this is an exception to the rule it shows it is possible. I'd put this on the opposite end of the spectrum from the Major Organization or University initiative that started somewhere high in the adminisphere and slowly made its way down to the parties involved in actual implementation like a brain-trickle (think of a Rube Goldberg device in the Amazon rain forest collecting the rain if you need a visual image). Somewhere in between you have the collaboration of equals in a volunteer or non-profit project - probably the cast of characters is wider and fits somewhere between the "let's just do it" and the "this should get done, let's appoint a task force to study the possibility of a committee charged with determining the feasibility of doing it".

The small, nimble project can do a lot and do it quickly and has great fidelity from idea to implementation because its such a small and presumably like-minded group (not to mention voluntary - the Two Guys both want to do this and believe in the project). If the project doesn't go anywhere the Two Guys will be unhappy (may even lose their garage!) but its probably not the end of the world. Its like a garage band - a few become hits, the rest wind up working day jobs. Everyone takes equal responsibility and everyone basks in the rewards (or punishments) of their results.

The large, adminisphere based project usually takes a very long time to produce an actual product, but in all fairness they also have a more realistic chance of "scaling up" to a national or global capacity should their product catch on (it may also be a product that integrates with other products they already have). On the path from idea to task force to committee to implementation there are delays that are unavoidable due to logistics (how much time is spent in meetings? How much time is spent planning and traveling to and from the meetings? How complicated is it to get capital and labor when you have to compete with all the other projects out there trying to do the same?). If your project involves technology you already have a strike against you because the Two Guys can probably get their product to market faster. On the other hand you likely have a large advertising budget and existing promotional or sales and technical support staff. If in an educational institution just substitute the word "curriculum" for "sales" (they both serve similar functions - getting the "right stuff to the right people in a timely and coordinated fashion" - and require similar administrative overhead; the main difference being a captive or non-captive audience).

The volunteer or non-profit project is the most interesting, and dear to my heart. It also suffers from the most challenges. Its usually large enough to have administrative overhead like a business or university. It usually has a variety of people with different points of view which is good in the brainstorming and implementation phases, but requires more administrative or management time than Two Guys would. Unlike the business or university it usually does not have funding or any sort of advocate to take them under its wing so to get things done it either needs to have extremely motivated participants (who stay motivated over time) or a way to get external funding. This could be grants (which necessitate a whole painful new level of administrative overhead, hoop jumping and slowdown) or donations (which then require a financial infrastructure and usually an attendant administrative one to make the money gathering legal - translation: bylaws and legal status). In short, these projects have none of the advantages of bigness (existing infrastructure and talent) or smallness (nimbleness and lack of necessity for a lot of infrastructure).

The good folks at 37Signals (developers of fine and dazzlingly useful software products of limited scope - they don't do a lot but they do what they do very well) put out a book called Getting Real which really turns the thinking of much of the "big" project people on its head. In fairness to the big people, many of the suggestions are probably not realistic for, say, a corporate or university environment. But I think the book is essential reading for anyone involved in technical projects and, who knows, it could be the savior of the "middle way" volunteer projects. They focus on being nimble and agile, not adding unnecessary stuff to your products or your workflow and management structure and generally dispensing with a lot of what I'd call "inertial management nonsense". Thankfully they're also not going the Stephen Covey route and trying to pass this off as the "next big thing" in management or living your life or the like - its just things that worked for them, and may well work for you if you'd give them a chance.

My take on where bigness vs. smallness works is this; in general larger groups are good for brainstorming, evaluating the project closer to rollout, and doing the maintenance or updating work, but in the planning and design phases its often better to have a very small group to actually carry that work out. Design by committee is usually an ugly thing, but if the larger project people can work out the ideas, hand it off to the smaller design group, then they can in turn give it back to the larger group for implementation things may work very well indeed. All of Us can, indeed, be smarter than one of us, but All of Us can also suffer from diffusion of responsibility, groupthink, laziness and a tyranny of the Big Mouthed. One of Us will have trouble pulling off a project of any large size, and for any length of time, and so should seek out All of Us for input and evaluation. They should then go off and do the work, adding their own special magic that doesn't come out of an assembly line, and deliver it back to Us to bring to the world.

Projects of all sizes would also do well to look into newer, distributed collaboration tools which are starting to become more prevalent and easier to use (and I don't mean Microsoft Project). 37signals makes really neat hosted products like Writeboard (shared note space) and Basecamp (entire shared project management space). There are also cheap or free tools like blogs and wikis and social networking sites like del.icio.us which, with the proper technical support and training, can supplement projects in ways email lists can't. If all your people share a network you can have a shared network file space, or if not its trivial to set up a basic project intranet on a website. Again, having a small group of people maintain something like this can benefit a much larger group with a minimum of effort (and the more your people get used to using such tools the easier it gets - remember, most of us didn't used to have email and the web browser). Using shared tools like this also give far more people the ability to participate meaningfully in the project and often serve as a useful way to collegially "keep each others' feet to the fire" along the way - too often things locked up in committee or board meetings drop off other people's radar screens and the whole project spends way too much time playing catchup. Its a fast track to discouragement if decisions take forever to make and nobody knows how far along things are in process.

Shorter this column: Sometimes a collaboration takes place in a large environment, where much of the time is wasted on administrative overhead and worthless meetings. As things get closer to the implementation phase perhaps the collaboration can be saved if its going off the tracks, though if you could get all the people impacted by it in the loop earlier that would be better. Sometimes a collaboration is just a few people who work well together and come up with something amazing on their own. Often these collaborations won't scale but that's not always the case, and sometimes they can beat the pants off a better funded and more "eminent" competitor. We could all learn a lot from these people. Sometimes a collaboration is more in between - a group of professionals or dedicated people who know they need a larger infrastructure to spread out the work and survive long term but aren't supported by a large company or organization. These people could *really* learn a lot from the Two Guys in a Garage approach. No matter what the size of your project you'd probably well to keep the management and design functions down to a small group of people who work well together - you can handle the larger, unwieldy parts (and benefit from them) if you keep them to the brainstorming or initial input phase and the implementation or shaking out the bugs evaluative phase once the product has been largely built. You can also use a variety of new collaboration tools (many of which are cheap or free) to cut through confusion and save wasted time in meetings going over documentation. Repeat as necessary until everyone reaches nirvana.

On the Life Cycle of Projects

As an academic I have been involved in many projects - some self-initiated, some assigned, some sort of accidental. Its striking the variety of dynamics I've seen, from inspirational and deeply fulfilling personally and professionally to some which would qualify for their own Circle of Hell had Dante lived long enough to write about doing a website in committee. This has led me to some thoughts about how technology projects work, and don't (particularly in academia or the non-profit sector - you for-profit types can feel free to ignore me and say that "our product changes everything" or "quality is job one" or some such. Hope those stock options work out for you).

One of the first signs of trouble in a tech project is when someone comes to you and says "we have to do this" because someone else is ("by god we're an Ivy League school, if this community college has an uber-portal with customized features and Flash animations everywhere why don't we?"). My favorite initial retort/shutdown is "yes, but do you have any idea if its been successful?". One of the dirty little secrets of the internet is that lots of people do lots of things but few could be considered a genuine success - those you will usually hear about in the business news (congrats, YouTube dudes! Bet you never thought *that* would happen, eh?). But professional jealousy aside, I actually think that friendly competition with your competitors is a great thing for generating new ideas - the key is to analyze the idea well enough to answer a few questions. Would this work in our environment? Are we already doing something like this but its not well known or well done? Do we have the resources and skills to do something like that? Is there anything coming down the pike that would render it meaningless or could be adapted to give you that magical function you liked? And of course the ever present "did their actually work or were they just too embarrassed to kill it" (good luck answering that question - I'd talk to the techs more than the administrators if you try). Apply these same questions (except the last) to any internally-generated ideas. Oh, and encouraging lots of internally generated ideas is a great plan - your own people probably know what they need better than your competitors, even if there is that whole keeping up with the Jones's mentality prevalent in management.

When I first started my information architect-y position I did a lot of reading, surfing, asking and talking and quickly hit on what I call a three legged approach to any project (primarily technical but who knows, perhaps it has legs elsewhere). I call them the Administrative or Business Goals leg, the Staff or Implementation leg and the Audience/User/Patron leg. Once the "stool" is built then there is the sitting test, I suppose (can someone actually use it? would they? will they forever?)

The first leg is adminstration or business goals - does it meet a need or desire from Management? Often this is the hardest one, believe it or not, because it can be hard to get Management to clearly enunciate what they want. In my mind "Harvard has one" is not a goal, its an observation (they may have a lawsuit about "it" too, did you also want one of those?). For a project to have a jot of a chance to succeed the projects goals need to be clear, or at least bear a strong resemblance to something that can actually happen. "We'll be the pre-eminent global online portal to resources in [fill in the blank]" is a bit too wishy-washy, particularly if [fill in the blank] is a single word (like "health").

The second leg is the staff/implementation leg - do you have people who are willing and able to both create and implement the project and then (most importantly) maintain it? A big trap here is the infamous grant-funded website project (you know, "we'll use our own staff and maybe hire some temporary staff to set up the uber-portal-of-Death in an incredibly large and complex area, not think about technical support and then when the grant money runs out not be able to maintain the parts we actually were able to get implemented on schedule"). The internets are littered with the bloated corpses of well-intentioned and often well-funded sites that just seem to sit there rotting in the sun - a shame, particularly since they still come up in Google searches (I suggest a new metric, the carrion factor we might call it). Credibility is a function not so much of constantly changing content (Flash animations don't count as constant change) as appropriately updated content. Some things age differently than others, and if your audience is at all savvy they'll be able to tell the difference between needed change and change for change's sake (corollary to the Flash statement: fixing typos to get your "last updated" date to change also doesn't count) - if you really wanted to be transparent you might try a Wikipedia-esque versioning approach to content changes.

The third leg is the audience/patron/users leg. Its very encouraging to see libraries start to embrace usability testing and evaluation when creating or updating websites - it took a long time for that message to sink in (i.e. you're building the site for other people, maybe you better be sure they can use it without too much trouble). Not to rain on anyone's parade, but I feel strongly that we need to go beyond usability to usefulness and a variety of other higher goals (Peter Morville has a nice 9-piece approach to what needs a resource should meet, usability being just one of them - check out Ambient Findability for more on that). Jared Spool has an excellent definition of usability - its the opposite of frustration. But building a resource "that isn't frustrating" isn't exactly as noble of a goal as we might want to shoot for (its like Detroit using the motto "our cars only rarely get recalled or kill people due to our negligence"). User-centered design is the common term for going beyond usability, actually involving users from the beginning of the project through to the end - that's much closer to the mark. But I'd like to suggest one further goal (this one is dedicated to the administrators in the audience) - try to cultivate a sense of experimentation and risk-taking on the part of your staff (particularly your programmers) when doing such projects. A dear friend of mine had a sharp, yet good retort in the early days of the user-centered transformation in my career - he pointed out that engineers are the ones who actually design the cars because that's what they know and do; why should it be any different for software? The point is that programmers will be able to tell you realistically what's out there now and on the horizon and show you things you and your users may have never even imagined, but might become an instant hit. They can also tell you why something is possible but not desirable or worth the effort (in software development with enough time and money anything short of breaking the laws of physics is possible, and they're working on that). So by all means ask people what they want and need, then go back and see what all is possible and reasonable (yes, I know, we have a tendency to think "the customer is always right" but even if it was the CEO who suggested it the Hello Kitty interface or Star Wars theme playing during the waiting for confirmation screen ideas may simply not be smart - have the guts to say that), then build (or buy) something and run it by the users to see if you hit the mark. Lather and repeat as necessary.

Speaking of "repeat as necessary", another really difficult issue when dealing with tech projects is the idea of "when is it done". This whole "Web 2.0" and "perpetual beta" idea has many people (esp. administrators and technology instructors) up in arms. If you involve all three legs of the stool in building the project the chances are you'll probably have something pretty useful with your first shot. But nothing is ever perfect - at some point you have to "shoot the engineer" (to stop adding or tweaking features) but also "shoot the administrator or marketing/PR folks" (to stop trying to second guess what people's responses will be). Remember, this isn't a print book or journal - technology projects change and evolve and grow. In fact, they should have a more organic nature (slowly changing and evolving in response to the environment) rather than having "the big rollout" (only do that if its something new or a replacement for something so old and decrepit that you, they and everyone knows it was an embarrassment). Evaluating a project once its up and live is actually a wonderful way to engage your audience (you know how hard it can be to do that if you've tried surveys or focus groups, esp. without bribes). Being open to change and growth and actually getting projects out the door will enhance your credibility immensely, far more so than your misguided attempts to "get it right the first time".

Which brings us to the final, sad chapter of our tale - people don't live forever and neither do tech projects. Unfortunately we don't deal well with death in our culture by and large and we are the same with projects - deny it can happen, ignore the possibility, curse someone else for it happening, etc etc. While I can't say I've seen any good examples in this regard I do think its something people should start to think about. Living wills are starting to catch on after enough people have had to deal with painful decisions about keeping people alive with advanced medical technology and at ages scarcely dreamt of until recently. Perhaps the same needs to happen with tech projects - most places could afford a hosting provider and access to basic things like PHP and MySQL, and students or younger workers can provide the cheap labor which means the cost of keeping a floundering project alive forever has decreased. We may face similar situations to the long term decline in health - so do we need living technology wills? If my site traffic falls below a certain point pull the plug? The success metrics really are up to the participants to decide but they should be thinking about whether they're helping or hurting their cause with their project. Removing the clutter would certainly help make search engine results cleaner (and I'm not sure they'll ever adopt my carrion metric to do it even if site managers won't). At this point my only concrete suggestions are to find partners in the same project space to see if they might be willing to collaborate or take over (be sure you don't sink *their* project in the process) or to see if there are new developments that have made your project obsolete or in need of change. Perhaps you can transition your project, Phoenix-like, into the new way of doing things and have your experience and authority help the new projects get off to a faster, better start. If not then perhaps its time to gracefully step aside and savor the good memories.

So to summarize (and perhaps editorialize a bit): If you're thinking about doing a project think about several things going in, then check in to be sure you are following through with them. 1) Be sure you have an actual project clearly spelled out by administration. Have the ability to have back and forth to clarify and, ideally, have administrative, technical and implementation staff involved so they can all give you a reality check. 2) Be sure you have a realistic and do-able workflow for creating or implementing the project initially, then maintaining both the content and the technical infrastructure. Hint: it really does take time to care for and feed a server, independent of the content providers. Be sure that workflow takes into account reasonable upgrades in the future (i.e. if you have text + still pictures now you might want audio or video later; you probably won't need to worry about heads-up displays and telepathic interfaces for a few business cycles yet). 3) Be sure that you're creating a product that your audience/user/patrons want and/or need. Don't be afraid to ask them up front, don't be afraid to show them the work in progress and (especially) don't be afraid to be sure its still working for them after you roll it out. Times change, people change - gopher was once an amazing tool and would now be considered pretty inadequate by almost anyone. Keep up with best practices and technology trends. 4) Remember that nothing lasts forever (well, setting aside some metaphysical questions for the sake of brevity) - eventually your project may wind up being unable to go on or become irrelevant. Try to have a plan, or at least the courage to deal with the situation without a plan, when (not if) this happens. Your staff and users will thank you for it. Change may be uncomfortable but its also inevitable, and is much more uncomfortable if you put it off (like getting your annual physical, which becomes more and more important with age - so too is it for your project).

On Authority and Credibility

In "info literacy" or "intro to the internet" classes we often teach the importance of knowing the authority or credibility of a source of information. Thanks to the ability of just about anyone to post just about anything there we need to beware of the dreaded "snakeoil salesman" - I used to refer people to a specific site dedicated to exposing just those sites and people. Problem was, over time the site itself became suspect (and still is, to some people's thinking). I made the mistake of what I might call "spot checking credibility" - a problem also implicated in the recent rise of the "evidence-based [fill in the blank]" movement. It seems as though some of our most treasured metrics of credibility are showing signs of strain, if not downright collapse.

David Weinberg has written over the years about changes in business models brought about by the Internet or (as is now the fashionable parlance) "Web 2.0". It makes me remember the magazine Business 2.0 and wonder how on target they were during the Internet Bubble Pop of the first part of the century, and if we might be setting up a similar series of unrealistic expectations using that term, which has now metastasized to Library 2.0 . He has an interesting point I think libraries and information professionals would do well to consider - much of our current global business climate has been a century-long aberration from previous business models (that is a move towards this Industrial Age oriented marketing and advertising where businesses talked down to "consumers" from on high rather than a bazaar model where buyers and sellers interacted face-to-face, in real time, and both somehow got what they wanted or needed). Much of what I see these days in terms of how we view authority or credibility fits more closely into the Industrial Age model - big institutions (universities, professional societies, companies, etc) expecting people to treat them with deference and respect because, well, they're big and have been around a long time. "We know information, you just consume it" is not something that tends to make the consumer feel good about that relationship, just like the marketing pitch that tries to make you think a company has your best interests at heart when trying to sell you a product or service. The form letter that uses the simple mail merge function (the "personalized" approach) fails miserably precisely because its so clumsy and obvious (I feel so much warmer and fuzzier getting a letter addressed "Dear Alan R" rather than "Dear Esteemed Consumer of our Goods in an Underutilized Market Space").

The internet and rise of tools for consumers to respond back to and evaluate these paragons of authority and credibility has changed the balance of power, probably irreparably and probably for the much greater good. The bad news is it can be very uncomfortable for people used to unquestioned power and control (there didn't used to be so many choices for where, when and how to get your information, and so many ways of evaluating it on your own). So in the library world why do we still give such support for sources of information that don't perform well, don't seem to have our best interests at heart and aren't the only source of information out there? Sure, its much easier to use a single source to purchase and manage lots of information subscriptions but is more of an inferior product really a good thing? And how do we expect things to ever change if all we do is complain meekly and then keep buying the same old crap? I'd like to see a little more principled decision-making regarding how we deal with vendors and other sources of information. In fact, I'd love to see us *becoming* those sources if the sources available don't exist.

I know, there's "startup costs" and "administrative costs", etc etc. But isn't that part of why these supposedly authoritative sources tend to move so slowly and charge so much for what they do? The adminstrative overhead of a huge company or professional organization has to reach a tipping point at which it becomes inefficient and unable to be nimble enough to change with the times - so they rely on the Argument from Authority. "Yes, perhaps our codebase looks like it was written by monkeys on (bad) crack, and we innovate at a pace that glaciers find admirable, but we're the best [fill in the blank] provider there is!". Well, probably you're the last [fill in the blank] provider left standing, and nobody else sees a reason to jump into your marketspace because they're already kings of their own. Fat, bloated, slow, lazy, unresponsive - is that the resume we want our "authoritative and credible" sources to have? I think not.

Performance and responsiveness is the new credibility. That doesn't mean the McDonaldization of these products or services either - a competent provider should be able to tell you straight up why and when they will or won't do things. In many cases less is actually more - if they'd take the time to provide *good* new products or services we'd all be much better off than just slapping together more hard to use and un-needed content. "Supersizing information packages" is unhealthy and un-nutritious just like it is for food. Perhaps a return to something more closely resembling the bazaar is in order. Save the money on booth bunnies and fancy food spreads at shows and put that money into a better product. If you're a professional organization don't rest on your laurels as "the first/largest/only organization" devoted to [fill in the blank]. If you don't perform well you're not credible. If you say you will "in the next release" and don't you're not credible. If you've been around forever but haven't "done anything for me *lately*" what good are you? It used to be we had very few sources of information and prediction (Oracles and prophets). Later it started to make sense to write things down, so we'd have a running tally and could compare the old with the new (libraries, and sounds kind of like blogs too, doesn't it?). Then we started digitizing and linking things, so we could access more and compare more - some call this the beginning of the Information Age or the Technological Singularity (depending on your comfort level with it).

Whatever your comfort level it seems as though the aberration of a hierarchical, controlled dissemination of information is over with, for good or ill. I remember hearing a speaker in the mid-90s wringing his hands about the death of authority and "good information". It seemed to me that it always has been a "caveat emptor" world, and some people just got a little too comfortable placing their confidence in the Encyclopedia Brittanica, or the local priest, or those smart professors at the university. When it comes down to it, no matter how authoritative the source its still up to the individual to decide if that source is credible or not. It may be more difficult and time consuming but in the end that's how its always been. History is written by the victors, and the press is free to those who own one. Now that "the losers" can still write and we all have our own printing presses history is about to get a lot more interesting. Batten down the hatches, fire up the keyboards and lets take a fresh look at who's credible or authoritative in this new age. If you're concerned about your loss of stature all hope is not lost - now you simply have to prove yourself worthy, now and for as long as you want that consideration. Is that such a big thing to ask for?

Welcome to the inaugural issue!

Well, at this point its more just an idea than a journal. We'll talk to Zeldman about how he got the ISSN for his Daily Report site, then maybe we'll be a real journal someday. Meantime, the idea here is to discuss some issues in the field of librarianship and its travelling companions - hopefully with tongue firmly in cheek but neither too flippant nor too serious to be read and enjoyed by people we don't know very well. Sometimes scholarly, sometimes with attitude, but hopefully always enlightening (or at least stimulating).

So, what is a dissident librarian? Someone who works as a librarian or was trained in library and information science and who cares deeply about our past, present and future yet doesn't necessarily buy into the accepted wisdom thereof. Someone who, Cassandra-like, has had ideas about the future come to pass and tried to make a difference but couldn't always. Hopefully we don't have a chip on our shoulders but we do have a sense of constructive frustration (not always pleasant, but always instructive).

Are you a dissident librarian? Find the usual channels of communication just too staid, slow or un-amusing? Want to discuss issues relevant to the profession in a largely unshackled environment? If so let us know. Perhaps we can be an antidote to what ails you!