To solve the advertising problem, I created a vertical column on the right side of the design to hold 125×125 pixel ads. This size is smaller than the ads the site currently offers, but I feel this is offset by the positioning of the ads directly next to the content, rather than at the very bottom of the site. The redesign has space for five of these ads.

To solve the readability problem, I changed the central content area into a photo index of the issue’s ten top stories. The featured story gets a wider display area, and the remaining nine form a grid underneath. Furthermore, the “Community News” section, generally found in the middle of the paper, gets a sidebar on the left for excerpts from the first few stories, with a link to the full community news section.

The site’s original horizontal navigation at the top of the site was transformed into three lists of links each in the header. This groups the links by type, and also echoes the grid structure of the article photos underneath.

Finally, I kept the grid layout for the paper’s eight columnists below the main content area, but tweaked the layout a bit to give it a more open look. There is slightly more spacing between each columnist’s grid space, and I got rid of the large borders around each grid space as well.

So, that’s Design 006. Stay tuned for the License to Kill, Design 007.

The answer is a set of three related ideas: browser grading, progressive enhancement, and graceful degradation. Taken together, these three ideas help designers come to terms with their utter impotence in the face of the Web, and create sites that look beautiful on any device that views them, even screen readers.

Start with Semantic HTML

Before we get started, it’s important to point out that all of these techniques ultimately come back to using semantic HTML. If the browser can’t make any sense of what your content actually means, your job as a designer is going to become much, much harder. If you’re not sure what I’m talking about, be sure to check out my earlier article on the topic.

The Old Browser Problem

If there’s one tenet of the Web that will always remain true, it’s that old browsers take a long time to die. Microsoft, Mozilla, and Apple come out with new browsers at least once a year, each better than the last, each encouraging users of the existing version of their browser to upgrade. Yet, generally speaking, people tend to upgrade their browser only when they buy a new computer – because it comes with a new browser pre-installed. Witness, for example, Internet Explorer 6.

IE6 was a bold new advance when it came out with Windows XP. Microsoft had won the “browser war” with Netscape, and for the first time since the start of the browser wars, sites could be built that more or less worked the same everywhere. Then, as designers started adopting CSS to do all of a site’s presentation (as opposed to the older, table-based approach), IE6′s flaws started to appear. IE6 had inherited a bunch of strange behaviors from IE5.5 before it, and designers got upset. Firefox appeared from nowhere and started gaining market share; Apple started making the Safari browser to replace IE for Mac; Google developed Chrome off of the same WebKit codebase; there was massive growth everywhere in the browser landscape. Microsoft realized that it was losing the Web it had worked so hard to lock down, and so it created IE7, and made IE7 a “High Priority” Windows update – meaning that users who were receiving automatic updates would get the new version automatically. The following year, Microsoft produced IE8, with even more improvements, and again it was to be made a “High Priority” update. Now that IE8 has been released, and IE7 has been around for over a year, one would expect that no one would still use IE6. But you would be wrong. IE6 is still used by about 40% of Internet users, and it’s still the most popular browser in the world. IE6 will only truly die when developers and designers around the world decide to piss off those 40% of users and stop making sites that work in it.

Why? Because users don’t like to upgrade their software, because Microsoft (and other companies as well) has too often released software updates that break more than they fix. So users turn off automatic updates, and stop updating at all for good measure. No updates means no new browsers, which means more headaches for designers.

Browser Grading

Enter browser grading. The folks at Yahoo had the smart idea that old browsers would be around forever, and you couldn’t really expect to support every browser ever made going forward. There would have to be a cutoff point where Yahoo could say “So sorry” to a user with an ancient browser, but that line in the sand would have to be drawn very carefully so as not to drive away potential customers just because of their browser. So they made a list of what they considered “A-grade” browsers, which they would do everything in their power to support, along with a “C-grade” browser list that should expressly be given the most toned-down, simple version of the site possible. Every other browser is treated as “sink-or-swim” – the browser will be given the “A-grade” version of the site, but if it doesn’t look right, that’s the browser’s fault, not Yahoo’s. As long as your site works in all of the A-grade browsers, you as a designer don’t need to worry about testing your site on every combination of browser and hardware in the world. Obviously, as new operating systems and new browser versions come out, Yahoo revisits their browser gradings to keep everything up-to-date.

Some designers, upon hearing about graded browser support, think about the “C-grade” category and say “This sounds like more work – I have to make two versions of every page now?” The answer is no, and the reason why is semantic HTML. Just serve your HTML page with no CSS or JavaScript to the C-grade browsers. If your site has been properly written with progressive enhancement and graceful degradation, the C-grade browsers will be able to use your site just fine. It won’t look pretty, and it won’t have any of the behavior that JavaScript provides, but it will be functional enough to use. (HTML5 may throw a bit of a wrench into this idea, but we’ve all got at least ten years before it becomes a final standard.)

Semantic HTML, and the concepts of progressive enhancement and graceful degradation, demand an entirely different way of looking at how sites are built. Again, please be sure to read my earlier article for an introduction to semantic HTML and its benefits. Because PE and GD are such a large topic, I’m going to close here for today. Just remember that no matter how many browsers are created, or how many devices your sites are viewed on, it’s OK to make your own dividing line of which browsers you will fully support and which browsers will get the “My Site for Dummies” experience. As long as you’re not cutting off users of older browser entirely, the experience of the “A-grade” site might just persuade your users to upgrade to a browser that didn’t come out when the Hamster Dance page was popular.

You may be asking yourself “wait… if you knew it was Veterans’ Day, why did you go to the library?” Well, quite simply I forgot. The only reason I knew it was Veterans’ Day was because of Google’s special logo drawing (even then, I had to hover over the graphic to find out what it was for). Plus, Veterans’ Day is not a holiday on the order of Thanksgiving or even Labor Day; for 99% of businesses, it’s just another day, or at most an excuse to hold a sale. I forgot that the library might be closed, and so did everyone else waiting in front of the building this afternoon.

How the library could have helped

Public libraries face a crisis in the modern era; fewer and fewer adults in the US read books, and research that might have required a library’s collected knowledge in the past can now usually happen on the Internet, without even saying “hello” to a librarian. Smart libraries are doing everything in their power to be convenient and helpful for their users – lending music and DVD’s in addition to books, teaching classes, and offering activities for children. Many libraries, however, still treat the Web as a second-class citizen. MDPLS could have avoided that line of people if it had just put a simple notice on its home page that all library branches would be closed today. I actually went to the library’s website this morning to see if items I had requested were available for pick-up, and I never once saw a notice that the library was closed. (They also could have avoided the line by taping a sign to the front door with the same information, but that’s another matter.)

To be fair, the MDPLS site did contain the information that the library was closed. That information was placed, though, in an out-of-the-way corner that no user would ever reach unless they were specifically searching for what days the library closed for – exactly the opposite approach that most users like myself would take. Clicking “Find a library” gave me a list of all branches, and I clicked the branch closest to me and clicked “Hours.” I found that the library opened at 12:30 on Wednesdays, and failed to see the note saying “Closed Sunday and holidays,” in which “holidays” was a link to a page listing which holidays they would be closed for. Instead, a note on the home page would have stopped me from even looking at hours and saved me a lot of time and frustration.

The general problem

Walking to a library that isn’t open is certainly not catastrophic; if anything it gave me some exercise. But there are many examples of systems that could help users, but choose not to. When was the last time you visited a health-related website (doctor, dentist, etc.) where the office hours listed were actually correct, or where the appointment time you were given was actually met when you got there? How many times have you visited a government office to do something simple, like renewing your driver’s license, only to find out that the forms you filled out from their website are not the right forms? All of us encounter “afterthought” systems in our daily lives, especially on the web – sites that were thrown together in an effort to “have an online presence” but which have been left to rot in the basement. Is this the fault of the site designer, or of the site owner, or both?

I would argue that the problem in general is the entire attitude of the web design industry. Too often, web design is sold as a commodity, an impersonal service that results in a deliverable of average quality for a set price. We, as designers, have taught our clients that designers are interchangeable and that “design” itself is just cranking a lever on some fancy web design machinery. Clients, in turn, generally want nothing to do with the process of design, feeling that design is what they hired the designer for in the first place. The end result is a site that works and (hopefully) has the designer’s best intentions, but which the client has no connection to and no inclination to maintain. It’s like giving someone a beautiful potted plant, only to have them keep it in the closet “until they really need it.” By the time they want to make updates, the site is already dead.

Instead, designers need to promote the idea that design is something a client and designer do together. Clients have to know that they have responsibility for the site just as much as the designer. Clients need to fully present their message to the designer – what exactly their company offers, who would be helped by it, what the company’s attitude is like – and the designer has to take all of that information and craft it into a design that gets that message across. (The designer can, of course, help the client find the answers to those questions, but he/she can’t just make up the answers out of whole cloth.) We, as designers, cannot afford to have clients think that hiring a designer is the extent of their responsibilities. The end results will not be our best work, and the clients will only have us to blame.

Back to the library

To return to today’s situation, MDPLS most likely built its website for the same reason that so many companies do – because everyone else has one. But that seems to be about as far as they are willing to go; everything beyond having a website that exists and lets people manage their library card accounts is “not my job.” Companies and organizations with this attitude should know that yes, it most certainly is your job. And if you are not willing to make it your job, there are plenty of others who are more than happy to take your place. Granted, I’m sure no one is itching to replace MDPLS, but even among public libraries there are strong examples of websites that do more than just exist.