Even the browsers were getting easier. Webkit and Mozilla based browsers were the most standards-compliant we’ve ever seen. IE8? Not bad for a Microsoft browser. IE7 was a bit of a mess, but nothing like IE6 which finally fell below 10% usage. Mobile? To some extent there were so many different phone operating systems and phone browsers that many of us had given up bothering. Call it a head-in-the-sand approach. But it sure made things nice.

Then Apple sold 3 million iPads in 80 days.

#*@&!

Oh yeah, and the iPhone4 is out with a super high-res screen. And mobile seems to be consolidating. The big three (in no particular order) are Android running Chrome (webkit), iOS running Safari (webkit), and Blackberry running who-knows-what but people who care can download Opera which is right there with webkit when it comes to web standards. So guess what. Mobile matters. It matters a lot. And the mobile space is clearly not as fragmented as before.

All of this adds up to a big problem. People are viewing our web sites on all kinds of screen sizes. 1024 is no longer a magic number. Not when mobile growth is 8x that of desktop growth. The pace is so hot that it looks like mobile web access will eclipse desktop web access in just 3 to 5 years. So yeah mobile matters. And size matters. The number of screen sizes we should care about just jumped through the roof given the variations of phones, iPads, tablets-yet-to-come, netbooks, laptops, desktops and external monitors that are already out in the field.

So what’s a designer to do? How can we avoid being thrown back to the horrid days of browser-sniffing and coding completely different HTML layouts for different browsers and devices?

The answer is blowing in the wind, and it’s called Responsive Design.

The core principles of Responsive Design for the web are using a flexible grid, sizing design elements as proportions (%) rather than pixels, and using CSS3 media queries to make your design responsive to the size of the viewport or device.

Wait wait wait you say: this sounds a lot like fluid layouts which have been around forever. Sort of, but in the words of Jeffrey Zeldman “It’s what some of us were going for with ‘liquid’ web design back in the 1990s, only it doesn’t suck.”

The lynchpin in this technique that doesn’t suck is the use of media queries, a CSS3 feature, that allows you to change how elements are displayed based on the size of the viewport. This even works dynamically while you are dragging the corner of your web browser around. This lets you create a design that morphs into a one column layout for small viewport or device sizes, and a three column layout for large viewports, but not TOO wide if you are on a 1920px wide browser. Yep, you can even keep line lengths readable.

But CSS3 isn’t supported by IE8. Or IE7. Or IE6. No problem. Turns out there a Javascript workaround that enables IE5+ (yes, that’s right, IE5+) to interpret media queries. http://code.google.com/p/css3-mediaqueries-js/ Now we’re talking!

Media queries are supported in the latest versions of all the other browsers that matter including: Opera 9.5+, Firefox 3.5+, Safari 3+, Chrome and Mobile Webkit.

And to sweeten the deal, the Javascript workaround mentioned above also allows Firefox 1+ and Safari 2 to use media queries

Ready to learn more? Start with the definitive article by Ethan Marcotte:
http://www.alistapart.com/articles/responsive-web-design/

Follow up here, which includes links to some related articles, shares the history of the very recent evolution of the technique, and includes links to several sites already using the technique:
http://www.zeldman.com/2010/06/23/responsive-design-is-the-new-black/

I’ll be demonstrating the techniques at the upcoming Fort Collins Internet Pros Meetup on Thursday, August 12. Learn more and RSVP here:
http://www.meetup.com/goFCIP/calendar/12297128/

Wordcamp is a one-day conference for WordPress developers, designers and enthusiasts.

I’m interested in the following talks so far:

• Creating a Blog Community with Dave Taylor, Doyle Albee, Aimee Giese, Holly Hamann
• Caching in WordPress with Chris Scott (same time as Blog Community, ugh!)
• WordPress Development with Alex King, Shawn Parker
• DIY Usability Testing with Steve Martin (I’ve seen Steve’s presentation and it is AWESOME! I highly recommend attending this one. His live usability test is enlightening and eye opening in ways you wouldn’t expect. And it’s different every time. No end to what you can learn here. If you want to make your websites better whether they are built in WordPress or not, this is a talk not to miss.)
• BuddyPress 101 with Lisa Sabin-Wilson (same time as Steve’s talk, ugh!) – BuddyPress is a plugin that turns your WordPress website into a Social Networking site.
• What’s Next for WordPress with Jane Wells

Two of us from CodeGeek.net will be attending (me, Josh Mulligan) as well as Steve Szczecina from Social Media Pilots.

As a web design and development company that uses WordPress as one of our main Content Management Systems (CMS) I’m especially interested in getting up to speed on the new features in WordPress 3.0, expanding our skill set, and meeting lots of other WordPress designers and developers. I love collaborating with others and staying in touch with other Internet professionals. If you are going, please be sure to say “hi” to us and give us your contact info and Twitter handle. You can follow me on Twitter at @ron_z.

Remy reviews two HTML5 features:

1. Storage including localStorage and sessionStorage which are local data storage capabilites that surpass the capabilities of cookies (to say the least), and
2. Offline Apps: specific techniques so you can tell an offline browser to load required files for a web site or web app from a local cache, thus making the web site renderable or the web app functional without a connection to the Internet. Supported presently by Safari and Firefox though the applicationCache methods.

Pretty interesting stuff to keep an eye on. These capabilities alone are a good reason to me to start using HTML5 now. As more browsers support these features we can create web sites using just HTML5 and Javascript with capabilities of full blown web apps. And they’ll work even when not connected to the Internet. Awesome.

I’ve been fascinated with the idea of “occasionally connected apps” since Macromedia Central was introduced in 2003 (since discontinuted, Adobe Central Developer Support Center, Anatomy of a Central App, Central Blog). Adobe AIR is making good inroads as the present platform of choice for occasionally connected apps. It would be a major improvement to have this capability without the requirement of a proprietary pluigin, i.e. the Flash Player. I’m excited to see active progress in that direction.

The first article this year is “Working with RGBA Color” by Drew McLellan.

Key points:

• This is one technique for setting the opacity/transparency of HTML elements
• The CSS opacity property is available starting with CSS3
• opacity adjusts opacity for all parts of the selector (HTML element), so if opacity is set to 0.5 for a heading element, the opacity of both the text color and background color are 50%.
• Using RGBA color specification allows finer control. The “A” part = “alpha channel”, which controls opacity, and can be applied to each color declaration as opposed to the entire selector. RGBA allows you to specify different opacity values for the text color vs. the background color.

Quick CSS terminology review, CSS syntax:
Selector {declaration1; declaration2;}
declaration = property:value;

example:

h1 { color: #000000;}
selector = “h1″
declaration = “color:#000000;”
property=”color:”
value=”#00000;”

Back to Working with RGBA color:

• To specify RGBA, use rgba(0-255, 0-255, 0-255, 0-1) as the value in your CSS declaration instead of hex codes, see the article for examples
• RGBA is supported by the latest versions of Firefox, Safari, Chrome and Opera, but is not supported by IE (of course)
• See article for ways to specify fallback colors or PNGs when RGBA is not supported (important)
• Opacity/RGBA can be changed on :hover or manipulated with JavaScript for elegant rollover effects
  
• RGBA can be applied to text color, background color, and border color

Why does it take clients so long to put together content for their new web site? Because creating content is complex. More complex than it appears at first. Because everything takes longer than you think. Because we all get interrupted all the time and we don’t plan for it.

Scenarios:
Using copy from their existing web site (short sighted, stale)
Writing all new copy (all the old content is garbage? really?)
We’re writing the copy for them (fastest, best results)
They’re writing the first draft of the copy and we’re editing it (standby for substantial delays)

What about photos?
Video?
Flash animations!?

Putting together high quality and relevant content for a web site is hard. It is. Just a fact.

Thoughts on a comprehensive content strategy for web sites

At CodeGeek.net we like developing web site content for clients. We work with several great copy writers, and we enjoy the overall process. I’ve been giving some thought to a comprehensive content strategy. Here are some of the steps involved with creating great web site content if you already have a web site. And I bet you probably do.

One: content inventory. What content do you have now? Catalog it: URL, page title, headings and sub headings on the page, possibly a one sentence summary, staleness on a scale of 1-5 (one being still fairly relevant, five being completely stale, planning to dump it)

Two: competitor research. Who are your top three competitors. Content inventory of their web sites. Skip the one sentence summaries unless staleness factor is a one or two.

Three: SEO keyword research. This is gold. Hire a fantastic SEO person to do your keyword research. If they’re good they’re going to discover a bunch of topics your web site constituents are searching for that you don’t even address on your web site. You need content on these topics to meet the needs of your visitors. You’ll attract a lot more relevant traffic if you do. Rank the new topics from 1-5. One = highly relevant to your industry and lots of searches. 2 = highly relevant and moderate searches. 3 = very interesting or unique topics don’t worry about how many searches. 4 = moderately relevant. 5 = relevance is a stretch, wishful thinking really. I just made those definitions up. If you have a better way to grade the new topics on a numeric scale I’d like to hear from you.

Four: Content sorting. Combine steps one through three in a blender, then sort with a centrifuge. Drop everything with a rating of four or five. Be brutal with ratings of three.

Five: Information Architecture. Time for card sorting with sticky notes. Organize the survivors into content silos, make sense out of the chaos.

Six: Finalize the site map.

(Wow, we haven’t even started writing yet! Yep, that’s right!)

Seven: Content strategy. Where will the content for each page come from? Is there value starting with what’s on the current web site? Or are we starting from scratch? Who needs to be interviewed to get the needed info? Does other research need to be done other than interviews? Who is going to write the first draft? Who needs to review it? Who will edit it? Which stakeholder is responsible for signing off on the final draft? What’s the expected lifetime of each page of content. Write down the refresh rate in months for each page. Then assign responsible parties to all content pages. Who’s going to refresh this stuff at the appointed time? There’s more to content strategy than this (voice, tone, when do you refresh the research and look for new content, and more, but this is an important slice).

Eight: Start writing. Write down deadlines and group content by deadline. Distribute the schedule to the copy writers. Some may be internal to the company, some may be hired hands. You had a project manager involved five steps ago to organize this, motivate the writers, and hold their feet to the fire, right?

Nine: Drink a bottle of wine. Sleep well.

Ten: First draft. Review, edit. Second draft. Keep everyone on track. Adjust time lines that have slipped. Hey – how far behind schedule is the photographer? (Yeah, there’s other stuff going on too!) Edit. Stakeholder reviews, edit. Final draft and sign off.

Eleven: Hand over the content to the web designers and developers. While the PM gets the design process rolling with your ace designer, have a party, the writers get to have a drink now, and take a day off for a job well done.

That’s it – great web site content development in 11 easy steps. Is it that complicated really? Maybe. Maybe not. But there’s always more involved than we think. And we never budget for the interruptions.

Tell us how you manage content development for web sites. We’d especially like to hear how you educate and inform your clients about the content development process and how long it takes. We want to hear from you!

An Event Apart Boston 2009 “the design conference for people who make web sites” just wrapped up today, and that was a strong message from no less than four of the fifteen presenters. In the past there has been a tacit assumption in the web design community that web sites should look the same, pixel for pixel, in the web browsers used by the majority of web site visitors. That would currently include Internet Explorer 8 (IE8), IE7, IE6, Firefox, Google Chrome, and Safari. One of those six browsers are used by approximately 97% of web site users according to the W3 Schools browser statistics page as of May 2009.

The new trend is a more realistic approach to web site design and development issues. “Different does not mean broken” said Andy Clarke, one of numerous presenters at the conference making the point that it is okay for web sites to not look identical in different web browsers.

What matters is that the content and functionality of a web site be made available to the largest number of web site visitors possible. If a button has rounded corners in Firefox but not in IE6, it’s not a big deal.

This approach allows web developers to start using some of the new features available in CSS3 right away, including creating rounded corners and drop shadows on both text and containers. Implementing these style elements in CSS saves time in the development process when initially creating a web site, and over time when maintaining it. The problem is that CSS3 features are not supported by IE7 and earlier. Many CSS3 features are supported by IE8, Firefox 3.5 and above, and Safari 3 and above. So going forward, support for these features will continue to improve.

Web site owners will be interested to know that implementing these features, like rounded corners, using CSS3 saves them money both in the short term (during development) and in the long term (considering web site maintenance). Design elements like rounded corners can be made to work in older browsers that don’t support CSS3, but that requires the designer to create separate special background images for each of the four corners of the box, and requires the coder to use extra HTML markup to apply those images. These images mask the “natural” square corners of the box giving them a rounded appearance.

While this looks great in more browsers, there are many downsides. In addition to taking more labor to create the effect in the first place, if changes need to be made to the corners in the future it takes more time than changing a few digits in a style sheet. There is also a slight performance hit to the web server, as more graphics have to be downloaded to the user’s computer in addition to a slightly more complex and therefore larger HTML file.

I am very much in favor of the new direction. What it does is focus our attention on what matters more as web site owners and web site designers: the content of the web site and the functionality of the web site. That is what we should be striving to deliver effectively to our web site visitors. Using the new techniques, if web site visitors are also using modern software, they will be rewarded with an enhanced appearance to the page.

Weather is one of my favorite topics, which is good for my health since I’m a pilot.

Upslope snow in Fort Collins happens this way: A low pressure area passes to our south. The flow around a low pressure area is counterclockwise, which causes the surface wind to come from the east, a little unusual for our area. That air originated well southeast of here near the Gulf of Mexico (visualize that large-scale counterclockwise flow), so it’s wet and moist and thinks it might be fun to take a little vacation in Colorado.

As the moist air flows from the east to the west aiming at the Front Range, it is moving uphill. The elevation in Fort Collins is just over 5000 feet MSL. The elevation at the eastern edge of Colorado is about 3500 feet MSL. The air coming at us is indeed moving “upslope”. As the air is forced westward it’s also forced upward and the gain in altitude causes the air to cool down, which (if it cools down enough) causes the moisture in the air to condense, or if it’s cold enough, to sublimate and precipitate out as snow.

As long as that low pressure sits to our south pumping the air westward and upward against the Rockies, it will continue to snow. If it sits there long enough like it did in 2003 we could get three feet of snow. This time the storm should keep mozying along and we’ll get 6 inches or so by Friday morning.

I agree with this comment on usability advantages of styling visited links differently from un-visited links, emphasis mine:

“Visited links not only help users avoid pages they don’t want to go to, they help users find pages they want to get back to. Styling the visited links in your site’s content will vastly improve your users’ experience.” [Source]

I think this point is often overlooked.

More articles I found useful:

• Mostly solid advice that has stood the test of time: http://www.designbyfire.com/deye_web/alertbox.htm
• Thoughts on using a background image next to a link to indicate that it has been visited: http://www.colly.com/comments/ticked_off_links_reloaded/
• Using symbols to indicate visited links, good points in the comments too: http://www.mikeindustries.com/blog/archive/2004/06/radical-links

I’m a big believer in using an underline as well as color to display links in general (with exceptions). I’m leaning toward using a washed-out version of the link color to display visited links in the main content for a web site, and possibly a background image or symbol to indicate visited links in a side bar or list.