Well it's been a while, but I'm back after a month long hiatus to work on other commitments and a short tryptophan-induced coma, and the traditional annual period of mourning over the demise of football competence in Detroit.

<digression>
Steeler fans, before you get too complacent, please remember that PA's own Matt Millen was the architect of this present bout of ineptitude, laboring many years after taking a credible football team and rendering it incompetent overnight. If I keep thinking about this I'm going to have to go eat more turkey and head for the sofa...again.
</digression>

Competence. It doesn't matter whether you are a football team or a library staff, competence is important. Rural libraries are tasked to do much with little in the way of staff. Specialists are a luxury that we typically can't afford. Yet this blog has been pointing out that we need to add a portal web site. As if we have all of the technical competencies we need for that, too.

That is typical of the resistance I've heard about adding web portal technology to the list of things that a small or rural library must deliver. While I hear complaints about how the complex knowledge requirements make this too hard to manage, I don't hear much about ways to overcome this.

That is not to say there are not small library web portals in existence, but that there is not a discussion about how to overcome complexity. In recent years much has been made of wiki technology. That is moving in the right direction and many have seized on it as a way to utilize web technology. Unfortunately that is stopping short of the full power of a portal because it is settling for a limited feature set. It appears that many (most?) librarians don't realize that when we outsource a portal it is a lot like setting up a blog or a wiki. Yet it provides for programability and delivers a lot of built-in functions beyond that of a wiki,  that we can use to deliver content.

We've heard about a high profile project to run an open source portal for libraries by providing templates, but this requires the whole state to pay $10,000 and still requires the state to establish, staff and operate its own data center! This is so opposite of what we can and should be doing! We don't need to be wasting money on data centers at a time like this and we certainly shouldn't be paying to use open source software regardless of how well the money is being used.

We should be eliminating challenges and costs. We can.

Running a portal depends on a lot of technology including 1) a properly resourced server, with 2) a properly configured operating system, with 3) a configured security regime, and 4) properly configured and secured web server software. Can you deliver all of that yourself? Do you know how? Can you afford to hire someone? Never mind. You don't need to. As we discussed last time, we've outsourced. This has eliminated this problem of technical support for just pennies a day.

There is research involved in determining what to use and who to buy hosting from. You are welcome to investigate portal software for yourself, but I am going to tell you what I recommend and why.  I choose dotnetnuke because it has a for-pay version which helps to insure that the large and active developer community will remain and this will make us flexible and powerful for very low costs should we ever need to extend the features. It has a lot of modules already available in the base portal -- more than a number of competing portal packages.  It has a lot of web hosting providers that offer it at very attractive price points. Several of these providers also allow a free trial of the site! In my initial comparison with other packages it was the winner. I'm convinced. In a future post I will provide you with a directory that will help you find a nearby web hosting provider for dotnetnuke (DNN).

Depending on the web hosting provider's plan, you may receive the site already installed by their support, or you may be able to schedule an automatic (scripted) installation while you wait. In either case in a short time you have a bare bones portal waiting for your modifications. So really you don't need to do all of that technical support; you just have to configure and operate your site.

This is where your competencies come into play.

You need to be able to do a reference search. You need to have the skills to take an information request and to learn enough "on the fly" so that you can tell when you've found a good answer. Using these skills prior to signing up for a web portal you can do the planning that will make your site an asset.

If you have access to the Internet and a set of subscription databases you will be able to find a lot of information to help yourself, but I am going to give you my two favorites right here to further the discussion:

Church, A. (2006). Your library goes virtual: promoting
              reading supporting research. Library Media Connection,
             25(3), 10-13.

Letha, M. (2006). Library portal: A tool for web-enabled
             information services. DESIDOC Bulletin of
             Technology, 26(5), 11-16.

You can find both of these on Wilsonweb in the library literature database. Together these two articles give you a vision for the sorts of things you need to support children, young adults, and adults in their most demanding needs of research and literacy. Without abstracting both of these articles for you let's suffice to say that following through on these specifications will let your patrons use your library more effectively regardless of location and time or day.

Armed with this and your knowledge of your public and the state resources that are available, you are in a position to leverage another of your competencies: organization.  You need to sit down and plan what you will have. Next you must envision how it all will be used. Thinking in terms of a workflow will help you to plan how various aspects of the site will be used together.

Once you know what you want to do, look at the modules of the portal package to see what services are built-in. See the presentation options and the communication options available and determine how you will leverage them.  As you explore you will become proficient and your site will take shape.

Finally, you may be concerned with branding your site. You will find that there are a number of free "skins" for  dotnetnuke portals. Skins are site designs. These provide you with a starting point for your site design.  The process of modifying a design is as easy as unpacking a zip file and looking at the graphic elements. What are their sizes in pixels? You can create images of your own and put them in place of the ones that were in the zip. Now repack the files into a zip and you can upload it to the site. You can then use the interface to demo the design.  If you need to, you can probably hire someone for this at a reasonable price, but you might have a high school student working for you that knows how to do it.

I've talked a lot about how an outsourced portal can defray complexity and play to our strengths, and still there is much to say. Some people are visual learners and a lot of things become clear when they are seen. With that in mind I'm providing a link here to a portal that I built, and the companion site that explains and provides passwords for you to sample for yourself.

http://portal.mystax.org/
http://www.mystax.org/

It is based on dotnetnuke open source software and is running on a server half a country away from me. By using the passwords and accounts provided you can see what some of the modules do and how you can use the built-in security to determine what people see (like in the staff/registered-logged in patron/logged off-unregistered patron views; tall 3 are different.)

The site was built up with some research to determine what is available to use in the base package and what 3rd party enhancements there are. It incorporates workflow through its endorsement of cloud applications for registered users and incorporation of language and layout that lead the patron naturally through common usage cases.

This was not much more difficult than setting up and posting this blog. The planning and execution did take a lot longer, but the site has a lot more to do, and that is not so much a matter of increased complexity as it is of sheer volume.

This was a spare time project for a person who has a full time job and other commitments on his time as well. It seems that it is within the realm of possibility for a small or rural library with a good state library online presence to do as well or better.

What I've tried to show is that our perception of overwhelming complexity is a construct of our own minds and is born of our unfamiliarity with the options available. The complexity is not insurmountable. Use sound business concepts to eliminate costs and offset your weaknesses, then leverage your strengths.  Dictate the terms of your battle with complexity and relegate it from "bogey man" status, to that of "someone else's problem."  We should do this rather than succumb to schemes that provide less and cost more, or deny our patrons advantages that urban patrons enjoy when it is within our means to deliver them.

~dd