IT and Sympathy is a great little article by Karen Schneider with wise counsel for IT planning by “non-IT” managers. It is written for a librarian audience at ALA Tech Source, but offers insights and lessons applicable to all, with a dose of Maslow’s hierarchy of needs thrown in for good measure. My favorite bit in the article is her now familiar but still sage observation that open source or other low-cost tech goodies so often promoted with evangelical fervor by resident geeks are anything but free: “Nothing is ‘free,’ even if it didn’t come with a price tag. … Instant messaging isn’t ‘free.’ WordPress isn’t ‘free.’ … Or, more correctly, all of these technologies are ‘free,’ as in ‘free kittens,’ not free as in ‘free beer.’ They come with maintenance and deployment issues, from opening ports on a secure network, to how much bandwidth they will use, to how much time IT personnel need to devote to deploying and maintaining the ‘free’ software.”

That would be 960 pixels. Let me explain.

In 2005 when LSNC began to build out its initial redesign of the Pika CMS, the design was premised on the prevailing horizontal scale for a web-based user interface, namely, a 760px fixed width for display in an 800-by-600 viewport. Our redesign conformed essentially to the production version of Pika that, quite sensibly, is built with a fixed width to assure that the full width of the UI displays as intended, without any need to scroll horizontally, at least for the vast majority of desktops. (Sure, one could build for a 640 by 480 pixels display if you have users with 13″ or smaller monitors, but if that is the case, well, it is likely your organization is simply not ready for web-based applications of any kind. Really.)

And this made practical sense at the time because the universe of monitor displays within the legal services environment, or at least in ours, was predominately 15″ CRT displays set at 800 by 600 pixels, with a replacement cycle moving toward 17″ LCDs set at 1024 by 768 pixels. While we could have initially built a design that was more forward looking, for those users with a bigger piece of viewport real estate, the reality on the ground was that the overwhelming majority of users were living their lives at a more modest display scale. So we built out our version of Pika to a fixed width of 760px, which allows adequately for browser chrome in both Firefox and Internet Explorer, with no need to scroll horizontally provided the user maximizes the browser within the viewport. Users working at 1024 by 768 pixel got the full UI display, of course, with a nicely textured background on the left and right sides of the UI. A touch of sauce béarnaise to go with the steak, so to speak.

But that was then. This is now. And by “now” I really mean 2008. As mentioned earlier, once Aaron releases Pika 4.0, the Webdogs team will set up a test bed for the new version, mount a full-on assault on his new templates, and begin to build out Project Grace. And that project redesign will build out to a fixed width of 960 pixels, for display in a 1024-by-768 viewport. This second redesign of Pika will not be nearly as daunting as our first go around, since the Webdogs now pretty much know where everything is in Pika and how the basic template structures work. The goal is to have the Project Grace redesign ready to hit the ground in early 2008.

This discussion, of course, begs the question, “Why 960?” Here’s how we’re looking at it:

First, I’m know I’m preaching to the choir on this now obvious point, but the web world view(port) is already predominately a 1024-by-768 world. The debate over whether there is a need to design to 1024 is largely over. Apart from reading web design articles, how do I know that? Because even the populist LSNC main website tells me that the world of 800-by-600 is in steep decline. Here is the Google Analytics graph on screen resolution of our main website this last week:

Sure, 800-by-600 is ranked second but only so with less than an 18% share, and I guarantee you that number is going down incrementally month by month. Every other screen viewing our public site is set at 1024 or wider. That’s an 82% share and growing. And the LSNC percentage exceeds the web-wide percentage identified by others. (For what it’s worth, the percentage of screens set at 800-by-600 viewing Webdogs 2.0 in the last week was zero, zip, nada. No surprises there.)

Second, we’ve run an inventory of our monitor stock, and we think we’ve hit the proverbial tipping point. With a modest amount of capitalization, combined with our regular monitor replacement cycle, by early 2008 we should have all our desktops positioned to take advantage of a 1024-by-768 viewport. True, there will undoubtedly be some hold-outs who simply won’t want to change and will hang on to 800-by-600 viewports. And if they want to scroll horizontally, that’s their choice. That quirky reality is not a rationale for holding the rest of the organization back. When the hold-outs are ready to move to 1024, Pika will be ready for them.

Third, less is more. Step back from the whole UI construct for a second and think in a broader design sense. There is a reason why an uncluttered display of information in any setting is “easier” for one to view or scan. It relaxes the eye and it is easier to locate objects in one’s view. This is why good typography, including web typography, demands proper leading (line spacing). Booksellers refer to this concept as “space sells.” Been in a Wal-Mart lately? Compare their display philosophy with that of your local Target. I rest my case. So, more pixel width means more available space between screen objects. Which means tangible gains in usability.

Fourth, more is more. A corollary here is that more space means that selective screen objects can be scaled larger, e.g., label text, input fields, buttons, and so on. As can basic text. And the option to do so is also a usability and accessibility issue. With Project Claire we postured a lot about making text display more scalable. One criticism we had of Pika was it’s reliance on a default font setting in pixels, which were not resizeable in Internet Explorer, rather than ems or percentages, which are. (Full disclosure: Aaron has promised to fix this in his upcoming iteration.) But we never quite got the Claire design to where we wanted so it could readily scale at least a bump or two up without breaking the layout or positioning of some page elements. But going to 960 will give us an extra 200 pixels of width in the Pika user interface, and this is a huge thing. How much so? It is equivalent to having an entire additional vertical menu column available for use on a typical web page. Take a look at the vertical menu on the right side of every page here at Webdogs 2.0. It is less than that, only 178 pixels wide. This is some serious real estate we can most definitely exploit.

What does a 960 pixel fixed width look like? You’re looking at it right now. Webdogs 2.0 itself is a web laboratory experiment, which like OpenPika will some day be put down. But when we built it, we did so with the forward notion that we could use the site to generally test out better, more compliant markup and CSS, and more specifically how that would work best with a wider page display. So far, things look damn good at 960.

We’ve spent the last calendar quarter getting our legs here at Webdogs 2.0. Now, with all the apparent site bugs worked out — anything here not working or displaying correctly for you? — and with a modicum of post content in the can, we will shift our focus increasingly on building out the major content areas inventoried on the right-side menu. Most notably, we will begin to give attention to where LSNC is with the Pika CMS. Here’s what’s coming up in the months ahead:

• Pika Lessons Learned: With a long-form narrative at OpenPika and a high-volume posting habit at PikaDocs, LSNC from August 2004 through May 2006 engaged in an institutional experiment in technology transparency and accountability. We called our initial Pika development cycle Project Claire and let LSNC staff, the Pika community as a whole, and the larger legal services community watch as we thrashed out the details of evaluating, adopting, modifying and then deploying a entirely new (for LSNC) web-based case management system. And you ask, “Well, how did it go? What worked? What didn’t work?” We will begin to answer those questions here.
• Pika 4.0 = Project Grace – Like others in the larger Pika community, we are cooling our heels as we await Aaron’s release of the next version of Pika. The moment it is released we will be setting up a test bed and will begin to twiddle, tweak, and tear apart if necessary his revamped template system as we integrate Pika 4.0 into our current version. We’re calling it Project Grace. Predictably, we will write about that here, and we will document what we are doing at PikaDocs. Why? Because that is what we do. It’s the Webdog ethos.
• Valid ≠ Best Practices – Truth be told, despite all the “validation smackdown” posturing here at Webdogs 2.0, we are not such dumb mutts that we think “valid” code is “optimal” code. As Roger Johansson wryly observes, validity does not equal best practices. Yes, all our Pika templates rebuilt for Project Claire nominally validated. But the Webdogs are where they are now, not where they were when they began that project, and there is one certitude we have come to know in the interim: the Project Claire templates are OK, but they are not remotely optimal. Building on the new Pika template system, we will undertake for Project Grace yet another full-on structural markup makeover. We promise new model templates with more sensible markup that is valid and semantic and accessible. You can count on it.
• Optimal Pika = Pika Usability – Among other things, we are working on tweaks to our initial intake workflow, enhanced file attachment integration in case records, improved data “findability,” and other usability enhancements. As we work these elements up, we will detail what it is, where it is, and why it matters.
• Bottom line – It’s all about Pika love.

Less a real book (pun intended) and more an extended set of web developer “talking points” in narrative form, Getting Real from the famed Web 2.0 geekmeisters at 37signals (most famous for Basecamp) is now available in toto online and free, albeit only chapter by chapter. Why might you want to read it? Regardless of the scale of your own development experience, regardless of your chops at project management, or regardless of your personal web-user ethos, the design and usability rationales of 37signals projects are always worth looking at, pondering, and dissecting. There are things to learn here, as many did from their first book, the most excellent Defensive Design for the Web.