blog

There is an interesting discussion following an AlistApart.com article entitled Where Our Standards Went Wrong, in which the author, Ethan Marcotte discusses two sides of the web standards debate. In the article, Ethan tries to refine the message we as standards advocates are delivering.

Yet while the benefits of valid code may not be glamorous, we canâ??and shouldâ??talk about them. Validation isnâ??t an end result or a final deliverable; itâ??s an ongoing process that continues long after a site launches. If we donâ??t put the proper tools and commitment in place, our work will start looking like a late â??90s throwback, and if we donâ??t provide guidance and education on validation, the polished, perfect pages we produced will be snapped into software thatâ??ll produce tag soup in seconds flat.

Ethan also discusses some of the problems with Content Management Systems (and their often third-party) text editors, which are often central to the standards issues we face when deploying web sites for clients. In the discussion following the article, several people touch on this aspect, and even (gasp) offer some solutions.

It’s a question that comes at some point in nearly every design project we do: “Should we stick with 800 pixels as our maximum width when designing the site, or push it up to 1024 pixels?” Unfortunately, there really isn’t a cut-and-dried answer that fits all situations. As a result, the question will generate debate and discussion as if it were the first time it was asked.

It would be great if it were really so simple as to just pick a width and go with it. That’s often what is done, but there are issues that make the question worth taking a deeper look at. Issues that can vary from client to client.

Simply having more space to work with is often a designer’s purpose for suggesting a wider layout, while clients are often motivated by a desire to fit more on each page. Not surprisingly, these two goals can often end up colliding into each other after the design goes into a production environment.

Unfortunately, regardless of your reasons for wanting more space to work with, it’s not simply a design question. There are accessibility and usability questions as well.

Although the percentage of users browsing the web with a screen resolution of 800×600 is decreasing (between 10% and 30% depending on whose stats you’re looking at), those that do so may be using the lower resolution (and even increasing the font size further from there) because they have trouble reading the smaller text-sizes at today’s higher screen resolutions. To not take this group into consideration violates accessibility standards. That’s not to say that we have to stay with 800×600 layouts, it just means that we have to make sure we consider the impact of any layout.

Why choose? Why not use a liquid, or expandable, layout? Liquid layouts have been around forever but continue to make up the minority of sites that we build. Why? There are a few reasons, but with the increased importance of accessibility as well as the growing number of alternative devices (Cell phones, PDAs, smaller laptops, tablet PCs and other devices) used in the U.S. and, even more so, in the developing world, our need for more flexible layouts is increasing.

Liquid layouts are a bit trickier to code, but the issue that usually trips us up is one of control. By this, I mean the perception of control that we often feel we have, or need to have, over the layout of a page.

In the design phase of a project we work with static images depicting how the page should look. Sometimes we pass these static images (or ‘comps’) back and forth for weeks, tweaking and adjusting spacing, color, layout and imagery. Since we are unable to make “fluid” design mock-ups we start to develop a sort of tunnel vision with regard to the design at hand. We start to internalize the structure of the designed page as well as the design elements, and when confronted with the prospect of how the page may stretch and resize when coded with a fluid HTML template, we back quickly away from the lack of control over the design that, to date, we’ve had pixel-perfect control over.

Perhaps the problem stems from the static representations we work with during the design phase. Are there any options?  Do we need to start presenting design comps that show the same layout as it will appear at several different resoltions (including handhelds)?

We need to let go a little bit of our need for absolute control over our page layouts. It’s been said before and should be said often: The web is not print. While this is overstated quite often, it is certainly true.  If people could easily modify layout, font sizes, column counts, etc. in print, then they probably would. Browsing applications and devices give average users exactly that level of control over what they view; And they use it.

Whatever the solution, we will continue to be confronted with the question every time we design a site. And to reduce the question to one of design alone may be causing more problems in the long run than we foresee.

Curt Hopkins (Morpheme Tales) recently conducted an informal audit of campaign sites of those who intend (or seem to intend) to run for president. Curt was intersted in seeing who is using social media tools and who is not. His findings?

I was surprised that none of the Republicans are so far using any social media (except for a couple of feeds), but the Democrats are making quite a use of it.

The Democrats were also a bit ahead in using the web at all. It seems like enough time has passed that both sides of the aisle would be keeping apace with current technologies. What’s the difference?

2008 Presidential Race Websites

Added 02/052007:
Hillary Clinton posted a health care question on Yahoo Answers (nearly 4,000 answers in two weeks)

There has been much discussion lately about Microsoft’s decision to abandon IE as the rendering engine for HTML emails in Outlook 2007. It’s hard to conduct a level-headed exchange on this topic because of strong feelings about HTML vs. TXT emails, and personal, professional, philosophical, or theological issues with Microsoft. Putting aside the endlessly repetitive and unproductive argument about whether Microsoft has any idea what they are doing, and whether or not it is a good idea to send HTML-formatted email messages, let’s look at the facts.

Molly Holzschlag’s (molly.com) post on the subject says that the impetus for this change was the unacceptable differences that MS Outlook users were seeing between what they saw in their inbox (rendered by IE engine) and what their friends saw when they forwarded those messages on to them (Composed by Word engine). Or when they composed messages from scratch (Word in Outlook) and their friends tried to read them (IE engine again). So it makes sense that you’d want the same engine to create a message that you use to view it. But Word? Really?

The problems enter in when you consider Word’s HTML engine: It’s inarguably sub-par. Already, those of us who create the HTML for use in client’s campaigns are forced to utilize a mish-mash of HTML coding techniques, some of which we’ve long left behind in building web pages. This isn’t just Microsoft’s fault; ALL of the email clients we test in have slightly different quirks and shortcomings. As a result, we are still using tables, spacer gifs, and (in many cases) font tags to layout our templates. So this is a situation of something broken being broken in a different (and perhaps worse) way when it really could have been a step toward fixing it.

So what do we do? Test about a bazillion times. This has always been the case. We have always had to test the rendering of our HTML messages in (at least) Gmail, Hotmail, AOL, Yahoo, Outlook, Outlook Express, Thunderbird, Mac Mail, Entourage and — if we can, and depending on the client — Eudora, Pegasus, Lotus Notes, or Groupwise. The testing required for Outlook 2007 adds a new wrinkle to the Shar-Pei, but regardless of Microsoft’s decisions regarding rendering engines, did anyone really think that 2007 would render the same as previous versions? Not likely. However, most of us thought that we might see an improvement due to IE7s increased support for CSS.

Anyone using email newsletters as a mode of communication urgently need to have their templates reviewed in order to ensure that future messaging remains successful. Many existing templates will not be Outlook 2007 compatible, and can almost be counted on to break when viewed. After all, nobody in their right mind has been designing email or web pages to be viewed in MS Word! It just wasn’t ever something we dreamed we’d have to test.

Were not entirely in the dark, however. Microsoft is supplying us with some information on Outlook 2007 HTML and CSS support, as well as a validation tool. Read up, test twice as much and we’ll all pull through. If we just stick together.

Microsoft Tools:

• 2007 Office System Tool: Outlook HTML and CSS Validator
• Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 1 of 2)
• Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 2 of 2)

Other articles and discussions:

• Excellent article by Dave Greiner of Campaign Monitor
• SitePoint post by Kevin Yank
• Arstechnica post by Jeremy Reimer

GoogleLabs always comes up with really neat ways to interact with their humongous piles of data (sorry for the techno-babble).

I’ve just been playing with their Gapminder, with which they have designed a dynamic, interactive interface to demonstrate disparities between nations, over time.

Use both the chart and the map view to see how countries compare with regard to “Internet users per 1000 capita,” “Carbon dioxide emissions - tons per capita,” or “Women % of workforce”. Use the play button to see how things have changed over time. Select a single country, or several, to track individually.

Compelling data delivered through a whiz-bang interface. Neat-o.

http://tools.google.com/gapminder/

Jakob Nielsen’s Alertbox has stated what I’ve been saying for a long time. Usability methods don’t have to be expensive to be effective.

For everyday design projects, discount usability methods are the best.

While it’s true that an anual usability check-up will be a little more expensive, the usability methods used when designing a site can be fast and inexpensive. This allows you to implement changes while you’re in design mode.

Fast usability methods should be used once you start wireframing. If you’re using Axure you can easily generate a prototype. Have a few people, Nielsen says 5, test it. Make modifications and repeat.

As I code pages for Web sites, I’m always working on ways to improve accessibility. The online tools for evaluating a site really just don’t cut it alone. It’s fairly easy to code a site that passes tests like the one found at The HiSoftware Company CynthiaSays portal (a very popular and accurate accessibility test) but that is still utterly unusable by someone using a screenreader, unable to use a mouse, suffering color blindness or any other disability that means they are using your site in any number of different ways. That’s not to say that online tests are not incredibly valuable, just that running your pages through a single test and thinking the job is done may not cut it.

Accessify.com has provided some incredibly useful tools and wizards to help build and test accessible Web sites. There are wizards for creating accessible HTML code (forms and tables), browser plugins for testing pages, even a set of Dreamweaver objects that increases the accessibility of your code by adding additional options to dialogs for creating tables, images, acronyms, etc.

For testing usability for people with different vision needs, I love GrayBit which renders your page in grayscale so that you can visually evaluate the color contrast of your site. Another really cool color tool is Color Schemes which not only helps you develop a color palette, but also lets you preview your palette approximating eight different types of color blindness.

When you get right down to it, though, there really is no substitute for having differently abled users test your site. They’ll let you know better than any test out there what needs to be improved. Just testing with average users who are unfamiliar with the site will go a long way toward exposing usability shortcomings, which often translate to accessibility issues.

Remember: an accessible site is also a more search engine friendly site! As if you needed a selfish reason to strive for accessibility.

For the latest IA Podcast, Jeff Parks and I talked about Beaconfire’s participation in World Usability Day on November 14. Specifically, we discussed the challenges non-profit organizations have in creating user friendly Web sites. We discussed brand, navigation, screen allocation, and calls to action.

• Listen to the podcast or subscribe through iTunes
• Download the World Usability Day Event Post-event Notes document (PDF - 718 KB)

As many of you know, Beaconfire participated in World Usability Day on Nov 14. Our event — Usability Make-over for Nonprofits — saw nineteen nonprofit organizations and some professional information architects. The discussion entailed issues that many nonprofits need to think through when re-designing their Web sites, including the use of brand space, call to action strategy, navigation, and labeling.

We’ve drafted a post-event document available for download here — World Usability Day Post-event Notes (PDF - 718 KB).

Tim Arnold and I, the presenters, are happy to answer any questions you may have:

• Olga Howard — olga.howard [at] beaconfire.com
• Tim Arnold — tim.arnold [at] beaconfire.com

Stay tuned for an upcoming podcast!

As a front end developer, I viewed the release of IE7 with a mixture of anticipation and trepidation. Having spent the past several years coding around the various shortcomings of IE6, I was certainly looking forward to what purported to be, a much more standards-compliant browser. I was, however, also nervous about getting a browser that, while fixing the bugs that allowed me to “hack” stylesheets into working for IE6 (the “* html” hack in particular), failed to correct the bugs that forced me to hack in the first place.

So far, it seems that IE7 is going to make life much easier for folks like me and has required very little (if any) tweaking of sites we’ve built. I’m really hoping that Microsoft’s aggressive upgrade system will push a much quicker adoption of what appears to be a browser actually worth using.

For those as geeky as I, here are some resources from Microsoft explaining the changes to how IE7 handles CSS and PNG graphics:

• Cascading Style Sheet Compatibility in Internet Explorer 7 (MSDN)
• Details on our CSS changes for IE7 (IEBlog)
• IE7 Transparent PNG Implementation (IEBlog)