Topic: Web Standards

What does your CSS Swiss Army knife look like?

Brian Dillard, Monday, September 22, 2008 @ 2:15 pm

CSS 2.1 is more like a Swiss Army knife than a fully stocked toolbox. We can accomplish a lot, but we have to get creative with the standard attachments. Floats, relative positioning, the box model - each tool must performs double or triple duty because they're the only ones we've got.

When we do discover a clever way to accomplish a common task using these limited tools, we're likely to employ that technique over and over. I'm not talking about CSS frameworks here; those help out more at the macro level. I'm talking about repeatable techniques that can be applied at the micro level. When done right, these simple techniques can feel like entirely new Swiss Army attachments rather than intelligent application of existing blades.

Whenever I start out on a new client project, I start off with the following plug-and-play components:

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (4)

Software Development

Selling colleagues on progressive enhancement

Brian Dillard, Monday, June 23, 2008 @ 5:14 pm

Achieving progressive enhancement at the view layer takes a lot of coordinated effort between server- and client-side developers. A lone UI developer can't make it happen without assistance and buy-in from the rest of the team. I'm not talking about selling the client or the business team. I'm talking about selling one's fellow developers.

I used to work for a giant company (Orbitz) with a large team of front-end developers and total organizational buy-in about accessibility and web standards. It took Orbitz years to get there, but once it did, progressive enhancement was the gospel.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Can’t we all just get along?

Sasha Dzeletovic, Thursday, June 5, 2008 @ 5:22 pm

I've came across an interesting article titled The Next-Gen Web: HTML5 - Will We Ever See A Real Standard? by Nik Cubrilovic that gives a nice overview of the history of web standards while focusing on the current HTML5 draft specification and its potential.

Web standards are not something particularly interesting to me as an Adobe Flex developer. After all, one of the reasons I've chosen this technology is that I can develop web applications without those standards limiting my imagination.

Adobe Flash technology is in part setting the standards of what Web 2.0 (and Web 3.0) really mean. Web experiences made using it are on the high end of what's available today and that's where I want to be.

One major lacking of this technology is that it is not utilizing web standards which makes some tasks harder, like making sites and apps search engine friendly, for example. I personally decided that its benefits significantly outweigh the problems.

Whatever one's perspective, I think that lack of full implementation of web standards causes a huge waste of time for people developing content for the web. Until that happens, I choose to ignore them altogether and use a medium that gives the same results on all platforms. To the best of my knowledge, content developed in Flash years ago still looks and acts the same in all browsers and operation systems.

You can find some great insight on what might be the future of web standards in Nik's article. In the meantime, my money stays with Flex.

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

A case study in Flash UI annoyances: style-card.com

Brian Dillard, Tuesday, May 20, 2008 @ 2:16 pm

Maybe I read too much Victorian literature, but I've always wanted a personal calling card. Recently, I decided to get one: a little something to help new acquaintances remember my phone number, email address and important URLs. Based on a recommendation from Time Out Chicago, I turned to Style Card, a slick consumer service that promises a less generic riff on the basic business card.

Here's how the company describes its product:

It's a social networking card created by you for the purpose of sharing your details and your style. Let people get to know the real you – or the not-so-real you.

Sure, I could have fired up an Adobe product, used a commercial printing service and gotten 1,000 copies of my own design for about $25. But owing to my lack of graphic design mojo, I decided to shell out $59 (plus shipping) for a mere 80 shiny, round-cornered Style Cards. The 3,000 percent markup is ridiculous, but I wanted to see whether I could benefit from the company's idiot-proof design interface. Besides, I figured I could get a blog post out of the experience. I wasn't wrong.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

HTML5 custom data: A possible savior for the poor, overloaded class attribute?

Brian Dillard, Monday, May 19, 2008 @ 6:01 pm

The HTML5 custom data proposal received a lot of attention last month, but I forgot to post about it during my preparations for Web 2.0 Expo. Reviewing the proposal now, I'm excited all over again. After doing lots of jQuery work lately, I'm sick and tired of the poor HTML "class" attribute getting used and abused for unobtrusive JavaScript. I think HTML5 custom data gives us a graceful way out.

First, a little background. Simon Willison, as usual, boils the issue down to its essence, succinctly quoting the proposal and nailing its implications in two sentences:

"Every HTML element may have any number of attributes starting with the string 'data-' specified, with any value." [T]his will be incredibly useful for unobtrusive JavaScript where there’s no sensible place to store configuration data as HTML content. It will also mean Dojo has an approved method for adding custom attributes to declaratively instantiate Dojo widgets.

For further background, including great debate in the comments, check out these blog posts and official documents:

• Willison's post
• Ajaxian's post
• Anne van Kesteren's post
• Relevant WHATWG wiki page
• Relevant section of the HTML 5 Working Draft

If you've never used custom properties (sometimes known as expandos) on your HTML elements, it's worth looking at how the technique has evolved over time. (Old pros can stop reading here.)

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

jQuery fade-in spoiler revealer: The failsafe, progressively enhanced version

Brian Dillard, Wednesday, April 16, 2008 @ 3:58 pm

***Spoiler Alert***

Don't read too much further if you haven't seen "Citizen Kane" and want to be surprised when you do.

I'm a big SF nerd and lover of teen-angst dramas. (That's why "Buffy the Vampire Slayer" is the Best Show Ever.) I love spoilers, but only when I've asked for them. When watching the entire run of "Dawson's Creek" on DVD years after it aired (don't ask), I accidentally spoiled Matt Laffey, the buddy who'd turned me on to the series, on how the big romantic triangle ended up in the final episode. I had no clue he had been saving Season 5 for a rainy day.

Since then, I have endeavored to include a ***SPOILERS*** alert in the subject line of any surprise-detroying emails - and to make liberal use of the return key to make sure the contents of such messages are below the fold in email clients with preview panes. This has made me a much more responsible citizen of fandom - though it hasn't lessened my outrage when entertainment websites post spoilers in their headlines or intro paragraphs without warning me and my fellow geeks. (Sci fi blog io9, by the way, is pictured to illustrate the right way to do things.)

Hats off, then, to Chris Coyier of tutorial site CSS-Tricks for his recent post on using jQuery to create a Fade-in Spoiler Revealer for use on websites. My only reservation about Coyier's technique was its reliance on JavaScript, and only JavaScript, to hide spoiler-laden content. With RSS and mobile browsing on the rise, lots of people read content in user-agents without JavaScript support. Shouldn't we try to protect them, too? I commented to this effect on the original article, then realized that I should just write the code myself as proof of concept.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (5)

Software Development

Hacking transparent PNG support into IE6 with IE PNG Fix, CSS and jQuery (part 2 of 2)

Brian Dillard, Wednesday, April 9, 2008 @ 5:45 am

For the recent redesign of the Pathfinder web site, we made extensive use of transparent PNGs to layer rounded corners and other curvy shapes on top of a non-contiguous background that mixes a black-and-gray gradient with a wallpaper-style repeating logo. Transparent PNGs are the only way to achieve this visual effect using semantic, standards-based markup and CSS - but IE6 doesn't support PNG alpha-channel transparency.

Yesterday, in Part 1 of this piece, we showed you how to install Angus Turnbull's IE PNG Fix on your server to correct this IE6 shortcoming. Today, we'll show how to overcome one use case not covered by Turnbull's script using a couple lines of CSS and JavaScript.

As we explained yesterday:

There is, however, one drawback to Turnbull's script: It can't account for PNG background images with a background-position other than top left. It will restore the alpha-channel transparency to such images, but it will reposition them to top left, potentially making your designs look even worse than they would have with an ugly gray halo where the transparency should be.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (6)

Software Development

Hacking transparent PNG support into IE6 with IE PNG Fix, CSS and jQuery (part 1 of 2)

Brian Dillard, Tuesday, April 8, 2008 @ 3:51 pm

Yesterday's post showed how to hack the :first-child pseudo-class into IE6 with jQuery and CSS. Continuing with that theme, today and tomorrow we'll show how to enable transparent PNG support in IE6 (so your rounded corners don't look like the ones in this picture).

Today, we'll look at an awesome open-source script that will cover 90% of your needs. Tomorrow, we'll cook up some custom jQuery-flavored JavaScript to cover the corner cases.

As with many of my recent posts, my use case is the new Pathfinder web site, which launched last month. We took a pragmatic approach to implementing our new visual design using web standards. We practiced progressive enhancement globally, resorting to hacks and trickery only in browsers that aren't fully standards-compliant. (To be honest, that includes most modern browsers, though IE6 is the biggest problem child by far).

Our game plan went like this:

1. If possible, implement the desired look and feel across all browsers using only CSS and semantic markup.
2. When necessary, serve browser-specific styles using CSS filters.
3. Don't deploy non-semantic markup just to achieve a specific visual objective in non-standards-compliant browsers.
4. Instead, if only junk markup will achieve the desired visual effect in non-compliant browsers, inject that junk markup via JavaScript.
5. The result is a site whose visual fidelity suffers only in non-standards-compliant browsers with JavaScript disabled.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (14)

Software Development

Web standards won’t get you into heaven

Brian Dillard, Monday, February 4, 2008 @ 12:17 pm

The endless hand-wringing over browser version targeting in IE8 illustrates what's wrong with the web standards community. For every sane, rational discussion about the practicalities of future-proofing the web, we get a couple knee-jerk anti-Microsoft screeds and at least one accusation that A List Apart - the standard-bearer of web standards - has somehow sold out by signing on to Redmond's plan.

First, a little background: Howls of protest echoed across the 'net a few weeks ago when Microsoft announced that Internet Explorer 8 would implement a new type of meta tag to enable both forward and backward compatibility in web pages. Once IE8 is out, users will be able to target rendering of their pages to a specific version of IE so that changes to the rendering engine of IE9 (or IE10 ...) won't subsequently "break" those pages. Basically, from IE8, onward, Explorer will include multiple rendering engines and display individual pages based on the browser version targeted by this new meta tag. The markup will look something like this:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

I have no interest in debating whether or not it's "semantic" and "standards compliant" to include the name and version number of a specific user-agent in my markup. That's already been debated to death (on the 200,000+ pages Google currently reports for the keywords "IE8 meta tag"). What I want to know is this: Will Microsoft's move make my job as a web developer easier or harder? At this point, the jury's still out, but I think the answer is probably "easier."

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (5)

Software Development

2007 in review: Five humble suggestions for better programming and writing

Brian Dillard, Monday, December 31, 2007 @ 1:33 pm

I began 2007 as a front-end tech lead on a multi-million-dollar software project for a global travel company with a massively distributed waterfall development model. I ended it working in small, agile teams on R&D projects at a small outsourced software shop. I got involved in open source, became (yet another) tech blogger, and set in motion lots of other writing and speaking projects for 2008. It's been quite a year.

I'm sure everybody is sick of year-end lists at this point, so let me present a slightly more personal and highly subjective list of the five most important things I learned this year about software development and technology writing:

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Fifteen years for HTML 5?

Brian Dillard, Wednesday, December 5, 2007 @ 5:30 am

A List Apart just published a great summary of the ongoing development of HTML 5. Buried at the bottom is a statement that reveals exactly why most people are paying so little attention to this evolving standard (emphasis mine):

Work on HTML 5 is rapidly progressing, yet it is still expected to continue for several years. Due to the requirement to produce test cases and achieve interoperable implementations, current estimates have work finishing in around ten to fifteen years. During this process, feedback from a wide range of people including, among others, web designers and developers, CMS and authoring tool vendors, and browser vendors is vital to ensure its success. Everyone is not only welcome, but actively encouraged to contribute feedback on HTML 5.

Ten to fifteen years? Is this a typo? A joke? No, this is standards bodies in action. As much as I object to the Flex/Silverlight proprietary-runtime thing on philosophical grounds, from a practical standpoint I can't fault the impulse. Between CSS 3, HTML 5 and ECMAScript 4, the standards process for core web technologies is a slow-moving train wreck. What's the point in getting involved when the standards take years or even decades to be codified, much less implemented by all the big browser makers?

Technorati Tags

• HTML
• web standards

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

Accessibility and Ajax: Progressive enhancement vs. side-by-side UIs

Brian Dillard, Wednesday, October 10, 2007 @ 12:00 pm

One of the most eye-opening sessions I attended at Adobe MAX last week covered the topic "Building Accessible Applications with Flex." Flash/Flex apps have a reputation for being inaccessible to assistive technologies, but presenters Andrew Kirkpatrick and John Bennett debunked that myth. Using lots of code examples, Kirkpatrick and Bennett actually walked us through Flex apps in a screen reader and showed how to use MSAA (Microsoft Active Accessibility) tools - including insepct32.exe - to make them function properly. The practical, how-to value of this presentation was on par with Derek Featherstone's talk at An Event Apart a couple months ago. The Flex world, it turns out, is just like the Ajax world: If an app is inaccessible, blame the developer, not the platform.

This session got me thinking again about the future of accessibility in a post-Ajax world. The standards crowd will argue that Ajax should be sprinkled sparingly on top of old-school webapps; it should be part of a separate behavior layer, with careful attention paid to progressive enhancement and accessibility. Turn off JavaScript and/or CSS - or use a screen reader, or a mobile device - and your app should still function perfectly.

I spent most of the last two years working on just such an application in my former life as a UI engineer at Orbitz Worldwide. Orbitz's new travel platform, introduced with the relaunch of the U.K. travel site ebookers.com, implements progressive enhancement on a massive scale. It was inspiring and educational to help build a giant ecommerce site with first-class support for web standards and Section 508. After a while, the techniques that make such applications possible become second nature.

That said, progressive enhancement sort of locks you into a Web 1.0 mindset - or at least a Web 1.5 one. It's pretty hard to imagine a full-on desktop-style Ajax app that magically degrades into a plain-vanilla website using the same markup and client-side code The more complex your Ajax functionality, the higher the cost of weaving advanced and accessible functionality into the same components. It's not just development cost; it's also performance cost. We've all seen progressively enhancement sites with a noticible redraw effect when onDOMLoaded fires. HTML form elements suddenly morph into widgets as your JavaScript transforms the original markup into Ajaxy goodness. This effect will only intensify as you move past basic Ajax effects and into full desktop-level functionality. So what's a standards geek with next-generation aspirations to do?

Plenty of developers have come to the conclusion that you should just build a separate, accessible UI. Look at Microsoft Outlook Web Access and Gmail, the two applications that put Ajax on the map. Both of them offer an advanced client and a stripped-down, plain-HTML one. If it worked for them, why can't it work for a lot of sites? Writer Bex Huff outlines the advantages of this approach pretty compellingly. The accessibility gurus at Webcredible have come to pretty much the same conclusions, albeit after a bit more hand-wringing. I doubt the WC3's forthcoming Web Content Accessibility Guidelines 2.0 will provide a comprehensive roadmap, but the draft version does at least acknowledge how much the landscape has changed.

Accessibility vs. Ajax has been a big topic for a couple of years now; my former Orbitz colleage Mark Meeker has earned plenty of kudos for his talks on the subject. But why do so many discussions of the topic still start from the premise that the same client-side code should support all users? I'd be interested to hear from developers of ecommerce sites and full-featured web applications. Are you building accessibility into your application architecture at all? If so, how? Progressive enhancement or separate UIs? Let me know in the comments.

Technorati Tags

• Ajax
• Accessibility
• Web Standards
• Section 508

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Cognitive Load, Portability and the Superiority of Client-Side Frameworks

Brian Dillard, Tuesday, September 4, 2007 @ 4:59 am

The recent introduction of TrimPath Junction got me to thinking about Dietrich's widely read post on Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks. GWT's big advantage is that it mobilizes armies of Java programmers to write browser-based applications without having to learn JavaScript. This is clearly of enormous benefit to organizations with lots of Java programmers, few client-side resources, and a burning desire to build powerful webapps. Yet for the similarly huge army of client-side programmers out there, GWT is pretty useless. Why learn a foreign language just to have it translated back into your native tongue?

I haven't yet had a chance to play with TrimPath Junction, but it sounds pretty cool. Using the open-source Helma framework, it offers Rails-style MVC scaffolding in a JavaScript syntax that executes the same code on the client and server. Basically, it's RoR meets Adobe AIR for JavaScript programmers. I hope to give it a test drive soon.

Server-side JavaScript has been around for ages, but it's never really become a common development model. I remember writing ASP Classic apps in server-side JScript back at the turn of the millennium and having people wig out on me. "Why not write in VBScript like everyone else," they'd ask. My answer: "Because I can save time by running the same validation libraries on the client and the server ... and because I can write the entire app in one language." I obviously have no argument with Dietrich's thesis on cognitive load. It's just that my brain features a JavaScript compiler, not a Java one.

GWT is a great piece of engineering that keeps getting better; just check out the new non-beta 1.4 release. But I think there are a lot of advantages to frameworks that mobilize the JavaScript masses to write front-to-back webapps. The same cognitive efficiencies can be achieved, plus client-side programmers already know all the pieces of the UI puzzle. Ask a room of Java developers how to build accessibility and usability into standards-compliant XHTML and CSS. Nine out of 10 wouldn't have a clue.

The other big advantage to developing UI code in its native language is that you can port it to any server platform. With GWT and similar frameworks, you've got to rebuild much of your UI from scratch if you want to change course in mid-stream. With purely client-side frameworks such as Prototype, jQuery, YUI or MooTools, switching libraries may entail rewiring some of your code to a new API. But switching server platforms, from J2EE to .Net to PHP to RoR, can be done without much work at the UI layer. "The right tool for the right job" is a truism for a reason. Pure client-side development of UI code allows for the development of reusable components whose only dependency is on the standards bodies and browser vendors who control JS, CSS and HTML. GWT and its peers are useful for some teams and some projects, but they're not the only answer to webapp development.

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

An Event Apart: Wrap-Up

Brian Dillard, Friday, August 31, 2007 @ 5:30 am

The dust has cleared from An Event Apart Chicago 2007. Now that I've gotten the basic reportage out of the way (here and here), on to the editorial page.

Three things I loved

• The wide range of topics: Despite increasing specialization in the web-development field, jacks of all trades still dominate our industry. An Event Apart offered sessions by and for designers, information architects, writers and developers alike. The most interesting sessions were often the ones that didn't cover my own specialties. Dan Cederhom and Jason Santa Maria both tackled visual design. There was little overlap between their presentations, yet each offered up practical device for folks who have to wing it with graphical design without much formal training. Similar cross-functional advice dominated the agenda.
• The skepticism about rules: Presenter after presenter - most especially Liz Danzico - prioritized guidelines over rules, research over dogma, and attention to one's own audience over one-size-fits-all solutions. One thing that usually distinguishes a great developer, or at least a mature one, is the ability to juggle a host of competing concerns without getting lost in the weeds. Accessibility vs. Ajax, beauty vs. usability, power users vs. Great Aunt Tilly - everything is a tradeoff. If there was on overriding message to An Event Apart, it was that we have to think deeply and often about our audience, our business and our objectives and make informed decisions.
• The focus on end users: It should surprise nobody that the ALA folks are usability nerds, standards geeks and champions of the end user. But it was inspiring to see how the speakers translated that well-worn agenda into series of discrete, actionable tips for everyday developers. As with any complex human endeavor, web development is all about picking your battles. With a potentially limitless number of improvements that could be made to any site or application, it's easy to feel overwhelmed. Most speakers showed how simple steps could provide incremental improvements in usability, accessibility, compatibility and profitability - all without starting over at the ground level.

Three things I didn't love so much

• The absence of concurrent sessions: Packing all 500 attendees into one room for the same 12 sessions (picture here) allowed ample cross-pollination. I'm an RIA developer, but I got the most out of the design, IA and BI sessions. Nevertheless, I longed for the ability to choose from multiple sessions, split off from my colleagues, and come back together during breaks to compare notes. It's not that any of the sessions were completely worthless. It's just that most were designed for intermediate skill levels in the same core technologies. I really didn't need to spend 15 minutes having xmlHttpRequest and getElementByID explained to me. It would have been great if some content had been pitched to masters as well as journeymen. The only way to make that work is through careful scheduling of multiple concurrent sessions.
• The dearth of programming content: A List Apart calls itself a site "for people who make websites," but not for people who make webapps. The broad range of topics very rarely extended to the programming realm. Only one session directly tackled JavaScript, and it was at an extremely elementary level. There was nothing on Java, Ruby, Python or .Net, let alone RIAs, widgets, mash-ups, Flex, Silverlight, GWT or JavaScript libraries. I know, I know, plenty of conferences already cater to those crowds. But as a programmer, I felt shortchanged. Again, concurrent sessions could have solved this, but I'm not sure programming - client- or server-side - will ever be on the ALA crowd's agenda.
• The lack of schmooze time: The schedule included some after-hours social events and a 90-minute lunch break each day, but I talked to lots of attendees who felt like they didn't get enough time to chat with other attendees. Other than a lonely bulletin board - and a social-networking site opened a few weeks ahead of time - there weren't a lot of structured opportunities to connect job-seekers and recruiters or peers from separate companies. Part of the problem was probably the cramped accommodations. When folks had breaks, they were too busy stretching their legs to schmooze. Still, I would have loved to see breakaway sessions aligned by job or industry categories.

Conclusions

For "people who make web sites," An Event Apart was probably a fantastic chance to hear practical advice and smart prognostication from industry leaders. For people who write client-side webapp code, it was a very good round-up of philosophies and techniques that too often get lost amidst the technical details. For pure software engineers, it probably would have been a waste of time and money.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

An Event Apart Chicago: Day 1

Brian Dillard, Tuesday, August 28, 2007 @ 7:42 am

The folks from A List Apart rolled into town yesterday for An Event Apart Chicago 2007, a two-day web-development conference. Around 500 programmers, designers and information architects flocked to the seventh floor of the downtown Mariott for a varied slate of talks by some of the biggest names in the industry. Today and tomorrow I'll give high-level overviews of each day's sessions. On Friday, I'll provide some color commentary.

Stylesheet guru Eric Meyer's "Secrets of the CSS Jedi" kicked things off with an in-depth case study in which pure CSS 1 and 2 transformed tabular data into an Excel-style bar graph. Meyer's presentation was interesting not only for what his techniques could accomplish, but also for what they couldn't. It was inspiring to see that plain-vanilla data could be given a powerful visual makeover, yet still remain completely semantic and accessible to handicapped users. But it was disheartening to see that the simple addition of tick marks within the graph demanded the addition of hard-coded percentage values to a number of CSS classes. The lack of simple computational ability within CSS declarations has long been a drawback of the "not a programming language" language. CSS remains a powerful and flexible technology, but, as I discussed at length a few days ago, it's got a lot of room for growth. For those who were already conversant with Meyer's techniques, perhaps the most interesting digression in his talk was the chance to tear through Firefox's built-in browser stylesheets and see how even the most fundamental rules of HTML presentation - such as the invisibility of meta tags and the entire <head> block - are controlled by CSS behind the scenes. Meyer also went over the basic building blocks of the kind "reset" stylesheet most jedis use.

Up next was Jeffrey Zeldman, publisher of A List Apart and therefore another another rock star to this crowd. A lot of recent ALA content has focused on the overlooked art of writing for the web, so it was no surprise that Zeldman tackled the topic "Writing the User Interface," which packed in plenty of practical advice for writers and non-writers alike. His central thesis was that copy was the cheapest and easiest thing to improve on most sites. Using lots of witty real-world examples, he provided a useful paradigm for breaking textual content into discrete components - guide copy (a.k.a. instructional text), brand copy (taglines and other branding assets), copy copy (a.k.a. real content), labels and URLs - and applying different editing criteria to each. As befits the author of "Designing With Web Standards," Zeldman was careful to demonstrate that the rules of good web writing and the rules of semantic markup are often one and the same. As with most of Zeldman's advice over the years, he started with a compelling philosophy, then showed how to break it down into small, actionable steps.

Happy Cog designer Jason Santa Maria finished off the morning block with "Design Your Way Out of a Paper Bag," a look at the process of rebranding and redesigning an existing site. An illustrated tour of Santa Maria's own iterative design process, the presentation was, like the earlier sessions, a case study in how a series of small steps can have a big impact on the usefulness of a site. Using an amusing Flickr tour of real-life signage and the abuse and misuse of the poor apostrophe therein, the designer drove home his biggest advice: "Sweat the small stuff." Along the way, he touched on typography, branding, logo development, grid-based layout, whitespace and other design concerns. As befits a designer, Santa Maria's session was probably the most visual and the least easily captured in the PDF slides distributed to attendees. He did, however, suggest some excellent further reading, most notably "The Elements of Typographic Style," "Thinking With Type," "Grid Systems" and "Making and Breaking the Grid."

After lunch, Lou Rosenfeld led with "Search Analytics For Fun and Profit." In a series of painstaking real-world case studies - most notably of my alma mater Michigan State University - Rosenfeld explained how server logs and especially search engine logs offer the keys to a successful site redesign. It's a simple idea that may seem elementary to many developers, but given how infrequently web-development teams actually use this feedback loop effectively, Rosenfeld's techniques struck me as really powerful. You would expect a session like this to show you how users' most popular search terms could serve as the springboard to an overhaul of your navigational systems. But Rosenfeld also delved several levels deeper, showing how much powerful business intelligence can be obtained from inexpensive tools with little or no custom code to support them. Site indices, metadata, search algorithms and the search interface itself - all can be tweaked based the subtle metrics that emerge from careful, detailed session analysis.

Perhaps the most inspiring session was Liz Danzico's "The Seven Lies of Information Architecture," in which the Happy Cog information architect recast the high commandments of IA as guidelines rather than rules. Danzico used copious examples to demonstrate how the most successful sites often bend or break the supposedly unwavering rules of IA. The idea of the magic number - most users can only remember 7 +/- 2 items in their short-term memory at any given time - was the first concept to show cracks under Danzico's microscope. She went on to debunk the holy status of such maxims as "consistency is good," "navigation is necessary," "the shortest path is the best path," "experience must be seamless" and "users should always know where they are." Sometimes, the idiosyncratic nature of her examples suggested that certain guidelines work for most sites and are best broken only for a specific purpose. Other times, especially in her examination of Amazon's and Apple's navigational systems, her case studies suggested that even mainstream sites do and should break the rules. It was Danzico's last rule - the idea that only IAs should do IA work - that she most thoroughly debunked by the end of her session. She argued passionately that site owners, designers, programmers and end users can and should understand the guidelines of information architecture - but, like IAs themselves, they should apply those guidelines judiciously rather than rigidly.

Last up was designer Dan Cederholm, founder of SimpleBits and Cork'd. He constructed an elaborate site prototype, ToupeePal, to demonstrate "Interface Design Juggling," his thesis that great design involves keeping lots of balls in the air at the same time. Delving deeply into typography, microformats and the development of favicons, Cederholm demonstrated that beautiful and useful interfaces can be constructed using the supposedly unsophisticated visual and informational tools already at our disposal. Cederholm cried foul on the idea that web typography sucks because too few cross-platform fonts are available. He argued that the single-font typography of the Itallian Renaissance is some of the most beautiful ever created, then he demonstrated practical techniques for getting similar mileage out of limited existing web fonts. Word-spacing, letter-spacing, line-spacing, color, weight, italicization and other simple tools can all elevate even the most familiar typefaces into the design stratosphere. Likewise, even a tiny 16x16-pixel favicon can provide a powerful branding tool when designed correctly. Cederholm closed with an in-depth look at the "accidental API" of microformats, demonstrating that a even a grassroots open-source movement can add power and value to the web without the support of standards bodies and browser vendors.

Check back tomorrow for coverage of today's sessions, from Eric Meyer's look at the post-IE7 world to Derek Featherstone's talk on accessibility.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development