Preppin’ Pika for 960

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.