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?