HealthLinks
Client
Details
HealthLinks is the portal to the Health Sciences Libraries at UW. In 2002 it was decided that HealthLinks needed an update to its look and feel and a reorganization of its content to better serve our users. We also wanted to move from static HTML to a database-driven site with reusable content.
I worked on a team comprised of content specialists, web developers, and system administrators to develop specifications and a scope of work for our custom content management system (CMS). My contributions included creating W3C-compliant XHTML templates and CSS to style the interface. I also ran usability testing sessions using Camtasia to record the tests. I verified the accessibility of the site using the Web Content Accessibility Guidelines provided by the W3C.
Later on during the project, after one of our developers left, I was brought on to the development team where I learned Java and JSP, helped build out some of our requested features, such as RSS integration, and squashed a few bugs.
Skills Used
XHTML, CSS, JavaScript, Java, JSP, Camtasia, usability testing, user-centered design, accessibility
What I Would Do Differently Today
HealthLinks and most portal sites in general are basically collections of links. They are lists of lists filtered by content experts that point to external content. Most portals have the same problems that physical libraries do: unfocused or unbalanced content (what I like to call content-arrhea) and a rigid organization scheme.
To succeed, portals must niche themselves (and protect the niche at all costs) and implement a faceted classification system. Why? The days of using Yahoo or MSN with one-home-page-fits-all are long gone. The web is remixed in real time for each user according to the needs of the moment. We no longer trust so-called experts because you being an expert in your area doesn’t necessarily translate into me finding the information I need. We’ve been burned before. That was Web/Media 1.0.
Portals must pick a topic with dissertation-like focus and become the preferred node for that topic. They achieve this by proving over and over again that they know their stuff and by not straying too far from what they know. When portals delve into content areas they know little about, users can sense it. They can smell the unease. It smells like a marketing ploy to gain a new audience, or at least, it smells like dabbling. Bloggers can dabble. Artists can dabble. Portals can’t dabble. If it continues down this path without either demonstrating expertise or spinning off a new web site (to continue dabbling), the portal is doomed.
Regarding faceted classification, almost everything on the web can be organized in more than one way. Portals must reflect this. If I call it ham and you call it pork and another person calls it bacon, we should each be able to find the product we’re looking for. Tagging and folksonomies are simple ways to give users a lot of power in this regard. RDF, OWL, and other Semantic Web technologies provide a formal structure for faceted classification and should also be explored by portal developers, and especially by sites where subject heading systems like MeSH and LOC already exist.
On the site management side of things I would ditch our custom CMS and use an open source package that we could customize for our needs. The library runs with a very lean systems support staff and the rate of change in information technology trends has outpaced our ability to add new capabilities to our software, much less explore interesting areas in data mining, management, and visualization. With an open source package we would be able to take advantage of the contributions of a larger group of developers as well as have the ability to contribute our own additions and improvements for the benefit of others.
