A Slight Frustration- Libraries and the ‘Net

I’ve been working on redesign of our library website.  Now I’m not a professional…at all and nearly everything I’ve learned about web design is stuff I’ve picked within the last year so take whatever I have to say with a (very minuscule) grain of salt.  I’ve gone from a straight HTML design to xhtml to PHP (which is where I’m staying dammit!) all three enhanced and spiced up via CSS.  Now one of the main tenets of CSS is the obligatory “Tables are Bad!”  At least from a design perspective.  Tables are to house data/information and SHOULD NOT be used in the LAYOUT of a web page.  Which is where CSS comes in.  Admittedly designing a layout via CSS that is accessible and (nigh) identical across a variety of browsers IS a bit of an uphill battle but the payoff, especially in terms of code simplicity,  is absolutely worth it.

In order to fuel my erstwhile designing I’ve been visiting a number of (mostly local) library websites in order to get a feel not only for how they have their websites laid out but for how they handle their coding as well.  Unfortunately what I’ve noticed is an increasing divide between current Web Design (from the professional world) and Web Design (in the library world).

Take a look at Princeton Public Library’s web page. I admit their design is attractive but a glance at their code reveals that, while readable, it lacks in some areas.  Most of the major content is delivered via tables, contains a fair amount of inline styling (again with the tables in particular), and a uses bunch of repeated code (header and footer).  Even if you didn’t want to use CSS for layout you could move the inline table styling to a style sheet (especially since most of the tables are contained in a div with a unique id).  Furthermore switching to PHP would allow a simple include once call for both the header and the footer leaving only the major content of each page.  I simplify of course, it is probably slightly more complicated than that, but designing an elegantly coded well designed page is within reach.

In terms of content PPL is a great example, I’ve seen some truly disgusting designs out there, and melding design with content, especially for libraries in this age of integrated services, isn’t exactly an easy task but that doesn’t mean that current web design practices and standards are inapplicable to libraries.  I’ve developed almost a perverse habit of running library websites through the W3C Validation service and have been almost universally disappointed with the results.  I suppose I’d have more to complain about if the choice in coding actually interfered in the operation of the web pages in question, as of now it doesn’t, but I still find it a little depressing that, if not out right ignored, current Web standards seems to be such a low priority for library web pages.

There is more I could say on this, but I’m already rambling and I have a stack of magazines that need to be checked in and shelved, so maybe more later.

Also if anyone knows of any literature, from either side of the information world (web designers/analysts, librarians, etc.) that discuss this please feel free to point in that direction.

Advertisements

A Note: Firefox 3 Beta 2

I had beta 1 installed previously but didn’t say anything much about it.  Beta 2 added a feature that I felt necessitated some comments.  The address bar.  Our old standard friend.  Every browser has one with some slight variation on implementation.  To date Opera, with its address bar search was king (enter “g” in the address bar followed by your query and it posts it to google, enter “z” and it searches amazon) FF3B2 added an interesting and wholly useful enhancement to standard auto-complete that gives Opera’s search a run for it’s money. In fact, the feature is so simple and obvious that you’ll wonder why no one (as far as my limited knowledge extends) has done it before.  Rather than simply auto-completing a URL FF3B2 auto-completes website titles as well.  Simple, effective, and more useful than you might expect.  Can’t remember the URL of that article you were reading (that you forgot to bookmark, shame on you!)?  Simply start typing the title and it shows up in the address bar!  Simple.  Effective.  Damned useful.

Beta 2 Address Bar

To give the beta whirl head on over here.  Don’t forget to check out the release notes.  For more detailed impressions check out the Wired blog or the mozillalinks blog.

CSS Stupidity

Well I wasted a whole morning on this.  See I have an imagemap of the library I work at. Clicking on a section of the map brings up a description of a collection and a search box specific to that area (or a link to the relevant area on the webpage). I decided today that I wanted these pop-up sections to have a translucent background. After a whole morning fiddling around with -moz-opacity, alpha filter, and opacity I threw in the towel and reverted to my old opaque background. You see, apparently setting opacity in CSS automatically applies the same setting to child elements.  Which, under normal circumstances wouldn’t be a problem since typically you can specify a different value for these child elements, or add a class or id with the differences.  Unfortunately, in the current version of CSS, opacity (once set) can’t be changed in child elements AT ALL.  There are several workarounds but (transparent PNG, tricking the cascade, etc.), IMO, they are all just bloated code. This is especially true given that my desire for a translucent background is entirely ascetic and doesn’t impact the function of the feature at all.  I’ve seen several mentions of using javascript to set opacity but again that seems to me a violation of the whole principle of separating structure, style, and function. Blah!!

I look forward to some of the CSS3 element currently being worked on.  Border-radius and  and RBGA can not come fast enough.  Lord knows when CSS3 will be ready, or even fully implemented in other browsers though.  I haven’t been paying attention too closely myself but after today’s opacity debacle I’ll be sure to keep a closer eye on developments.

UPDATED- AIR vs. Silverlight vs. Prism

So Mozilla announced a new product recently: Prism.  Prism, as noted by the devs, is designed to compete with Microsoft’s Silverlight and Adobe’s AIR.  What are these obscurely titled things you ask?  Well as far as my neophyte ass can tell both Silverlight and AIR are plug-ins/development platforms used for web applications.  Web applications, like gmail, are the current internet development craze.  Finding new ways to deliver content to a population spending increasing amounts of time living in their browser.  The difference between the two programs being developed by evil corporate society Microsoft and Adobe and Mozilla’s Prism are hard to spot out of the gate (and with no experience with any of the aforementioned platforms).   As best I can tell the differences lay in the fact both Silverlight and Air are separate tools for delivering content.  Web apps are developed straight into and delivered directly by Air and Silverlight.  The advantage of Prism, as far as I can tell, lays in its ability to take already established web applications and wrap them in code that allows them to be directly accessed via one’s desktop using a browser stripped of unnecessary accouterments (navigation bar, etc.).  In other words allowing one to access web applications as if they were simply desktop applications and thus better integrating the desktop experience with the web itself.  Interesting stuff.

Of course I could completely wrong about how any of this stuff works, at least until I try it.

EDIT:  Thanks for the comments below.  For others curious I found an article from Infoworld that describes AIR a little better for us unititated types. 

Also, from Microsoft’s Scott Guthrie comes a good blog post with some more good information about Silverlight.