I started my conference program with a case study by the BBC. They did a redesign and managed to squeeze formerly 60 images into 3 sliding doors and sprites. Their home page is now under 300K and 30 HTTP requests. Nice to see Yahoo’s Exceptional Performance guidelines go mainstream. About 5% of their users access the site without JavaScript. They don’t get identical features, but they get identical care. For them accessibility isn’t a buzzword, it’s become a natural part of their daily work. So they were able to find out that blur() is not a friend with JAWS. Also the BBC plays well with the other kids: they joined the OpenID foundation, and with BBC backstage they open their content through an API. Another charming idea is their public beta where people can testdrive new features. About 60% have personalized their home page, although one of the speakers described the personalization features with “my mom’s head exploded.” They used agile development with 2 week sprints, run the website in 12 languages, but don’t have a CDN yet because of the license fees.

Another case study about the LOHAS community Edenbee wasn’t that exiting, mostly because I knew the platform since beta and didn’t get quite why I should speak with other people about changing their lightbulbs. But it’s nice to keep track of your carbon footprint, a feature that uses the AMEE open API.

I was curious about HTML 5, so I went to the presentation of Lachlan Hunt and James Graham. Still I don’t see any advantage of having a bunch of new elements that are incompatible with older browsers when I can achieve the same with ARIA attributes. But I understand the rationale behind some of their decisions, although that doesn’t mean I come to the same conclusions.

For example people use a lot of “nav” and “menu” classes. To make their live easier, the WHATWG came up with the idea to create a nav element. A block level element, so you wouldn’t have to use those <div class="nav"> any more. But every time I use something like class="navigation" it will be an unordered list! I don’t need another div, I’m perfectly happy with my ul and role="navigation". It’s truly backward compatible, it’s semantic, I can use it today, and there isn’t a steep learning curve.

Then I went to two design talks by Andy Clarke and Dan Rubin, and though their designs were beautiful, the code examples were not. Imagine the flexibility of a newspaper article and compare that with the inflexibility of absolutely positioned paragraphs with fixed heights. Exactly. Apart from that Andy’s main inspiration came from comic books. It never hurts to throw in some colorful images.

Like in comic books, usability is not about getting from A to B, it’s about the experience of getting from A to B. In comic books the size of a panel and the amount of text strongly influences the reading speed. So you can emphasize content and add dynamics in your web design. That doesn’t mean necessarily that everything has to be in boxes. Emphasis can also be added by removing the boxes.

Dan Rubin used a lot of effects on his designs, like a noise filter to add texture on monochrome surfaces. Nice idea, though that implies the designer explaining the rationale of such a feature to the front-end engineers. They would either ignore it because they overlooked the subtle texture or because they assumed it would be just noise. Some less intrusive hint I will readily adopt was using a letter-spacing of −1 on headlines to prevent tiny rivers between letters.

What slightly worries me is that Dan talked about re-using patterns for some effects in Photoshop. Re-using patterns is the same in CSS, but re-usable effects in Photoshop can mean an unusable amount of work in CSS and lots of pictures making the website slow. What I miss so far is a common understanding of effects and patterns that are both easy to work with in Photoshop and in frontend programming.

The next day started with Nate Koechley’s keynote about professional frontend engineering. He chose the topic because he thinks this is critical to the advancement of the Internet, and I couldn’t agree more. As Frontend Engineers we write software with XHTML, CSS, JavaScript, and quite some amount of PHP. Douglas Crockford calls this “the most hostile software development environment imaginable,” and if you take a look at this graphic from Nate’s slides you will understand why. There are a number of knowledge areas that can be applied in a number of ways on three operating systems and half a dozen browsers in two rendering modes. If you ever wondered why you sometimes see little clouds of smoke coming out of your frontend engineering heads, that’s why.

There are four guiding principles:

1. Availability and accessibility for all users worldwide
2. Openness: share, learn, support, advocate
3. Richness: provide, but not too much
4. Stability

Then there are three core techniques: Graded Browser Support, Progressive Enhancement, and Unobtrusive JavaScript.If you haven’t heard about those concepts, please read about them now.

At that point the presentation turned into giving advice for quite a number of best practices and tips, like using JSLint, YUI Unit Testing, or YUI Profiler to enhance the quality of your code. Or serving cacheable assets from cookie-free domains. Or anticipated preloads: sneak in your new JavaScript and CSS files a week before the relaunch. Or did you know that the iPhone 2G can keep only 19 assets in cache, and that it doesn’t cache anything larger than 25K? Uncompressed 25K? Needless to say, Nate’s presentation was one of the conference highlights.

Later I heard a few things about building applications with existing frameworks and APIs, a timely comparison between JavaScript libraries held by no other than jQuery’s John Resig, some tips on internationalization by Richard Ishida, and a panel about accessibility. The one sentence that stuck most in that panel was: “Don’t be the guy with the problems, be the guy with the solutions.” In fact it’s very hard to be passionate about your job while being pragmatic and providing solutions instead of just saying “no.” Something Richard Schwerdtfeger wrote about in a different context:

Working in the accessibility field is extremely difficult. It requires very specialized skills — including incredible persistence. Accessibility is often viewed as additional work that is not always planned for. It requires a person who is tough, committed, patient, and caring to deliver an accessible solution that is usable to our customers. To do this you must have tremendous passion for your job as there is always someone or something to trip you up.

Combining passion and diplomacy is a goal many web evangelists still have to work on… In the meantime remember that accessibility is most likely to have a sustainable impact when it is supported by senior management, when there is an accessibility policy for a company, and when smart companies realize that there is money to be made by maximizing the target audience.

In this post

• Jesse James Garrett
• Molly Holzschlag
• Mark Boulton
• Jon Hicks
• Hannah Donovan
• Shawn Lawton Henry
• Richard Ishida
• Andy Clarke

First off was Jesse James Garrett, the creator of the term AJAX, who held a keynote presentation with all the usual quotes, big stock photos, historical references to technical pioneers (this time the inventor of the Kodak film roll) and such (podcast). I’m afraid I can’t bear victorian black and white photos of technical pioneers in the context of web development any longer. OK, so this guy changed the way photos were made in 1885. Also web applications are a little more convenient now than server roundtrips. But where’s the common element? One made photography easier for the mainstream, the other is a much hyped technique with the potential to make things easier, but quite often people just blow it.

Don’t believe the hype. Most web applications still don’t innovate, they just copy desktop behavior. And who is really comfortable with the restrictions of desktop software anyway? If it’s only a matter of response rates, learn from Yahoo! how to minimize the amount of data being sent on server requests. If I can update a whole page in 1-2 seconds using smart caching and other techniques, there’s no need for an AJAX request except for immediate form feedback helping users to avoid errors. Film rolls have faded from the face of Earth, it really would be more interesting what’s next, after AJAX. Jesse talked about user-centered design, cited Tim O’Reilly with the paradigm to “design from the outside in.” But that only means: after having taken one usability step back, eventually we will move forward. Where to? Jesse failed to deliver that.

A key factor to understand why browsers are such a pain is to remind yourself that they are just a piece of software, said Molly Holzschlag, now working for Microsoft (podcast). In fact very complex software. She compared the pros and cons of different browsers and what we can learn from them: short iteration circles and automated updates from Firefox, a strong brand and user identification from Opera. Otherwise she recommended that if you really need a feature in IE, make yourself heard. Put pressure on Microsoft to get priority. Just telling them you “want” something like multiple background images or WAI ARIA support won’t be enough. Your voice and your friends’ might weight more than that of the W3C, because you are their customers, their userbase.

Mark Boulton’s presentation about typography gained more momentum after a while (podcast). He explained why Verdana is lighter than Arial, and that you should blur your design to identify the optical gray gradient of a page. Then he continued to talk on grids and how to design to a vertical rhythm, a topic well known from print but rather unrecognized in web design until last year. Quite fashionable are headlines in a serif font for a better structure, and paying attention to small details like using the correct quotation marks or dashes can make a difference.

Jon Hicks showed us how to be a creative leech sponge (podcast). Get your inspiration everywhere — with two exceptions. Do sketches, keep those you draw during phone calls, take photos of typefaces, keep photos gone bad just for the color effects, collect labels from clothes, get leaflets (the “all you can eat buffet for designers”; get even the bad as you might need to mimic bad design some day). Get inspiration from book covers, graphic novels, books for children, magazines, patterns, prints, or packaging design. Blogs and flickr groups also help you to get inspiration, delivered right to your desktop through their RSS feed. The two exceptions? Other websites and logos, because there’s a high risk you will come up with a copy instead of an original idea. They are too close to the desired product so there’s no room for creative transformation.

Once you have collected inspirational material, it needs to be cataloged. That can be done in a sketchbook, but iPhoto, Yojimbo, or flickr will do the job.

Catalysts against a creative block (the dreaded blank page) can be deadlines, changing your environment and going for a walk or drive, going to bed, some peace and quietness (in the bathroom, where you keep the magazines for inspiration), taking a shower, or traditional techniques like brainstorming, mindmapping, criticizing and learning from bad examples, or moodboards. If your clients are adventurous enough, they can even do their own.

Some people are angry about Last FM’s sell-out to CBS, but Hannah Donovan didn’t make the impression that a petty-minded corporate spirit has taken over (yet). She talked about lessons you learn in a startup, like getting started, getting out the product very quickly (before others do it), taking small iteration steps with the rapid development technique Scrum, and using broad brushstrokes as a designer. Perfectionism is no priority for startups. Also she recommended that designers and developers work on a team (really) and hold 5 minute stand-up meetings every morning, “that makes a world of difference.” That actually means sharing a room, you know.

Shawn Lawton Henry works for the W3C WAI and the MIT, naturally she talked about accessibility (podcast). That’s something most people take as “what you can get away with,” but it’s really about people. So it’s important to understand how people with disabilities use the web. Technical standards like the Web Content Accessibility Guidelines 2.0 (WCAG) only supply a shared definition of requirements. Because they are not going to change for a while you better take the time to review the current version. However, the WCAG Techniques document will be adaptable and more flexible. There will be subversions, and although there’s no issue tracker at the moment, you will be able to submit additional techniques to meet the WCAG requirements as they are intended to grow with time.

I didn’t take notes on Richard Ishida’s presentation about I18N because I was familiar with the slides already, but I was deeply impressed by this man (podcast). Richard lives and breathes internationalization. He speaks about a dozen languages and doesn’t let a chance pass to practice them. He is the perfect personification as head of W3C I18N activity. I only wish he had said a few things about the I18N tag set because it’s a mighty tool for translations and fairly new.

On a related subject Andy Clarke asked designers worldwide if they thought their country or region got a distinctive design style, and he compared international websites of global players (podcast). While most of them just work, they could do better by adapting to the local customs and style. Culturalization is the key, anything else is modern imperialism. Check his presentation (PDF, 18 MB).

Somehow it was different than last year. Of course I came home full of inspiration, but this time it was more like deepening knowledge, while last year for example the concepts of microformats or browser performance were totally new for me. I met more people than in 2006, and I feel some of them can become my friends. That’s a new experience at a conference. I even found some parallels with Joe Clark. No, I’m not a “sarcastic gay vegan,” but we both don’t drink, prefer tea, and can be quite pedantic… I even linked to his website without rel=nofollow now, what an improvement! Anyway, I’m looking forward to meet some of my new friends in Brighton at d.construct.

• Andy Clarke: Royale With Cheese (PDF, 18 MB); Podcast
• Dan Cederholm: Interface Design Juggling (PDF, 22 MB); Podcast
• Dan Webb: The Mysteries Of JavaScript-Fu; Podcast
• Drew McLellan and Simon Collison: High-Noon Shoot-Out: Design vs. Implementation
• Håkon Wium Lie: One Web, Acid2 and CSS3 (PDF, 3.7 MB); Podcast
• Hannah Donovan and Simon Willison: For Example… Last FM (PDF, 1.8 MB) and Doing Local Right
• Hot Topics Panel: Podcast
• Jason Santa Maria: Diabolical Design: The Devil is in the Details (PDF, 22 MB); Podcast
• Jeremy Keith: Bulletproof Ajax (PDF, 2.1 MB); Podcast
• Jesse James Garrett: Beyond Ajax; Podcast
• Joe Clark: When Web Accessibility Is Not Your Problem; Podcast
• Jon Hicks: How to be a Creative Sponge; Podcast
• Mark Boulton: Five Simple Steps to Better Typography; Podcast
• Molly Holzschlag: The Broken World: Solving the Browser Problem Once and For All; Podcast
• Nate Koechley: High Performance Web Pages; Podcast
• Richard Ishida: Designing for International Users: Practical Tips; Podcast
• Shawn Lawton Henry: Advancing Web Accessibility; Podcast
• Tantek Çelik: Microformats, Building Blocks, and You; Podcast

Update

Thanks for the reminder, of course Joe Clark wrote detailed protocols about some sessions. Also I would like to point you to Chantal Slagmolen’s original notes — I wish all designers were so creative!

First he was giving an update on his workover of WCAG 1.0 under the label of “the WCAG samurai,” something he announced a year ago in his article at A List Apart, To Hell with WCAG 2.0. A few anonymous people he will not disclose finished their collective update, also there were two peer reviews of the final paper without the reviewers knowing about each other. Clark said he hasn’t read the reviews either, so this was kind of a premiere.

Then he talked almost an hour about a couple of things that shouldn’t be your concern (in his opinion) as a web developer:

• Pixel units: per definition, pixels are relative units as required by the specifications. Blind people do not care anyway if text is resizable, zoom readers have their screen magnification software. But he misses the point when he concludes that therefore resizable text is not an accessibility issue because disabled users don’t have trouble with it. Accessibility doesn’t only affect severely disabled persons, it begins with elderly people who need to adjust the font size. And as long as IE6 is around on a considerable number of desktops, it is our problem to enable text resizing. We cannot just shrug our shoulders and put the blame on a certain browser vendor. Although we can get rid of those resize buttons on web pages. That is really a matter of browser vendors and user education. Patrick Lauke proposed to put such an explanation on the default page of newly installed browsers.
• Link text being used out of context: Clark showed an example of a fictitious car sales page with recurring links to the car’s features. Of course the features link of one car is different than the features link of another, but you can clarify that ambiguity through a link title. A list of links on a page is a well known and appreciated feature of screen reader software, why should we cease to support that? But one thing I agree on is using an anchors type attribute to clarify that a linked document is a PDF. Though to my knowledge screen readers don’t make use of that attribute.
• Abbreviations, acronyms, initialisms: We cannot cover all cases, and there are cases like “DVD” or e. coli where there is no written out meaning of an acronym, or an abbreviation that is so common that it is neither needed nor any help to give the full meaning. But I strongly disagree of dropping the whole concept of contextual help for abbreviations with the argument that cognitive disabled users won’t get it anyway.

Clark’s disputable (unfortunately not at the session because of a lack of time) arguments will certainly be addressed on the Royal National Institute of the Blind’s blog, so watch their space for a controversial debate. I will also try to get I got also a shot of a hilarious illustration of Joe Clark that Kristiaan Thivessen drew next to me.

In this post:

• Dan Cederholm: Bulletproof web design
• Robin Christopherson: Beyond a code audit
• Cameron Moll: Mobile web design
• Nate Koechley: Yahoo! vs. Yahoo! vs. Yahoo!
• Tantek Çelik: Microformats: evolving the web
• “Hot topics” panel
• More presentations

The evening:before featured another get-together in a fancy work:after club, which can be summed up like this: Sweden won against Paraguay, and it was hard to talk to others because some notorious DJ wouldn’t turn down the volume. He desperately tried to get somebody on the dance floor switching from house music to r&b pop, but didn’t realize that was not what the audience wanted.

Bulletproof web design

If there was an award for best presentation, Dan Cederholm would get my vote! His slides were so well-designed, so clean, and the special effects (not seen in the PDF version) contributed to clarify the scope.

It was like Jeremy Keith’s presentation the day before, where you knew all the things he was talking about, still something made “click” and shifted your perception — and if it’s only that you think “that’s what I always needed to show to my designers!”

Scene from the early computer game Dig Dug (Atari 1983), where you pump up monsters until they explode

His example for thinking ahead showed a photo of a new warehouse in San Francisco, where the windows had been inserted to be future proof, but cemented over for the current use. So think ahead, because content amount and text size may vary, content changes and needs to be maintained, and because the environment can change. Take something off, like images, CSS, or JavaScript, and make sure the website still functions.

“The journey begins by letting go of control, and becoming flexible.”

John Allsopp, “A Dao of Web Design”

A lot of his examples worked by setting a 50% value for the horizontal or vertical background-position in combination with overlapping images, and he introduced the term “Dig Dug Text Test” as a metaphor for pumping up text and assuring the design is still not destroyed. Reminder to self: add more references to early 1980’s games in presentations, they are so cool!

Beyond a code audit

Robin Christopherson’s bad karma was that he relied on the unreliable wireless network in the conference center, therefore a few examples from the web refused to work.

But by struggling with the technical constraints he set a real-world example for the attending web developers. Robin is blind, and he did not notice the Windows XP bubbles popping up once in a while trying to alert him that the network was unavailable. He was unable to login on the QE2CC screen, because it was inaccessible and refreshed too often. Also most people I spoke with were deeply impressed by the incredible speed his screen reader was set to.

He had also prepared a couple of educational films about challenges on the web for people beyond the visually impaired, like a woman with learning disabilities who didn’t understand the word “disclaimer,” or a quadriplegic with a mouthstick and a voice recognition system, which was useless when the alt text in images or Flash applications did not match the displayed text. I know what a tremendous amount of work the production of such little films is, and I’m looking forward to access them on Robin’s site. Also check his speaker’s notes.

Mobile web design

Cameron Moll mentioned a few times that he had held this presentation a year ago. Therefore it was very professional, very slick, but a little unemotional and in my opinion not quite up to date.

Okay, there are more mobile phones than computers, more mobiles than landline connections, but he didn’t stress the incredible impact the wide adoption of Opera supporting JavaScript on cellphones will have. That’s finally a common platform for web applications using Ajax, as opposed to hundreds of different implementations of Java which are almost impossible to test. That’s a most remarkable development with the potential of revolutionizing mobile applications — Cameron hardly mentioned it, although this became public in November 2005.

Of course WML is dead, long live XHTML MP! You should serve content from a .mobi domain and concentrate on the contextually relevant information: People might check their eBay watchlist on their cellphone, but they don’t upload items to sell, so ignore features like that when developing for mobile devices.

Also my question about Vodafone and other carriers inserting invalid code in the pages they serve through their proxy might not have been clear enough, because Cameron replied it’s up to the carriers and the browsers how to interpret pages, while developers can control the code.

Unfortunately that’s untrue when carriers compress images more and insert JavaScript to get the original images with higher resolutions with a key combination. One script is inserted with the deprecated language attribute in the header, while the other comes after the closing </html> tag, thus rendering your valid XHTML strict code to tag soup. The problem not only manifests on mobile browsing devices, but also when you surf with a regular notebook using your mobile access. Therefore a @media handheld CSS, browser sniffing, or serving the MIME type depending on the HTTP accept header are all doomed. And there’s no way to prevent the carriers from doing such evil.

Yahoo! vs. Yahoo! vs. Yahoo!

I went to this presentation because Nate Koechley recently published his smart concept paper about graded browser support, which we immediately adopted. What I didn’t expect was a most impressive roller coaster trip through browser performance!

Yahoo! has a beta version out for their new portal, also Yahoo! Photos and Yahoo! Mail is under development. All of them make more or less heavy use of DHTML and Ajax. Yahoo’s goals were increasing performance by 300%, adding interactivity (vulgo: drag & drop), and supporting web standards.

For a fast response they used techniques like CSS sprites, or memory management. In Nate’s words browsers are still “a pain in the ass,” and “the web is the most hostile software engineering environment imaginable.” DHTML leaks memory like a sieve, so for each constructor use a destructor. Instead of adding events to thousands of email objects Yahoo! used the existing document.onmousemove event and checked if the mouse was over an object or white space, then passed the event to that object or drew a rectangular choice box. Key concepts are conservation, destruction, and recycling iFrames (about:blank). Use Drip as a tool for measuring memory leaks, test extreme object counts, test long interactions, and test extensive navigation.

Also their developers prefer JSON over XML because parsing XML degrades performance greater than linear as XML size increases.

They have identified HTTP requests as a main performance killer. Browsers still only process two or four HTTP requests at a time, especially start pages are not cached as effectively as they imagined, and parsing JavaScript freezes the browser. Therefore they rather serve a single large file with CSS in the header, and JavaScript as close to the </body> tag as possible.

Regarding browsers it is faster to develop for standards, than patch. Browser support must not be binary, and it does not mean “the same.”

Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogenous essence of the Web.

There are more IE5 browsers out there than IE 5.5, and IE7 “already moved the needle.”

With all the DHTML and Ajax I was concerned about accessibility, but in a sidenote I almost missed Nate mentioned the IBM contribution for DHTML accessibility. Wonderful!

Microformats: evolving the web

When microformats are even on the radar of Bill Gates, how could I ignore them? I had no clue before Tantek Çelik’s presentation @media 2006, and now I’m implementing them in this post. Microformats are virulent.

Basically you insert a few class names into your code, like

1. <p class="vcard">
2. <a class="url fn"
href="http://tantek.com"> Tantek Çelik</a>
3. </p>

There are microformats for contact cards, calendars, reviews, geo information, and many more. Even the Creative Commons license and the PICS label implemented in this page count as microformats. XFN and XOXO, too.

You can parse this page through a Technorati contacts feed service or use a tool like the Tails extension for Firefox, and voilà, there’s a vcard you could import into your address book (if there wasn’t this Thunderbird bug which prevents exactly this). With the hcalendar microformat you synchronize your calendar with event schedules on a website accordingly.

There are a few issues I ran into when I implemented hcards, and the documentation could have more examples, but they are on Tantek’s to-do list. Also sometimes it means extra, non-semantic markup, but as microformats increase semantic meaning, I assume it gets Tim Berners-Lee’s blessing. So go for it, microformats are definitely among the web’s next big things!

“Hot topics” panel

I had the pleasure to meet Molly Holzschlag earlier in a coffee break, and while I was sorry I couldn’t attend her session I18N, awakening the sleeping giant, I’m confident I didn’t miss much information as I am pretty familiar with her old articles in her regular column in WebTechniques and the current activity of the W3C I18N group, where she is a member.

Jens Grochtdreis reports in his blog about the passionate presentation she gave earlier, and although there is more technical experience and awareness in Europe with multilingual websites, rarely they pay respect to cultural differences, like the meaning of colors. Molly gives everything to educate on I18N and promote web standards, she is also a member of WaSP. I’m glad she seems to have found a way to get some help and support, as she is an outstanding, but sensitive person.

Anyway, she was part of the “hot topics” panel, where questions from the audience where considered by a group of experts: Molly, Jon Hicks, Jeremy Keith, Eric Meyer, and Tantek Çelik. They had a lot of fun and agreed CSS has become more mainstream in the last year, as you don’t have to defend CSS against table layout anymore. Well, reading the discussions in German forums and reviewing the code of other websites, there’s still a lot of educational work to be done. Also they talked about the accessibility of Ajax, and mashups as the next big thing, but you can read a decent transcript of the session in Stuart’s blog over at Muffinresearch.

Conclusions

If you have followed me this far, you can see @media was a big inspiration, it was a lot of fun, especially the after event on Saturday, and I can only recommend the conference! There are endless flickr pictures and quite a few blog entries on Technorati if you need further impressions. Um, and never mind the British food …

More presentations

Here are the presentations in the parallel track I couldn’t attend. Also there will be pod- and videocasts available soon.

• Dave Shea: Fine typography on the web
• Andy Budd: Bug hunting
• DOM Scripting: The Next Level
• Andy Clarke: The fine art of web design

In this post:

• Eric Meyer: Keynote
• Jeremy Keith: Using DOM scripting to plug the holes in CSS
• Chris Wilson: IE: 7 and beyond
• The new accessibility guidelines: WCAG 2.0
• Jeffrey Veen: Designing the next generation of web apps

Introducing geeks to a social life

There was some socializing the evening before the conference where I met with a couple of Germans, like Jens Grochtdreis who initiated the German web standardista group “Webkrauts”, Jan Eric Hellbusch whose website I had noticed before for some master theses about accessibility, or Tomas Caspers who is a member of WaSP and the mastermind behind the accessibility portal Einfach für alle. Actually I wasn’t the only one to notice he looks like the lost fifth member of the German punk band “Die Toten Hosen”?… Also that’s where I met Roger Johansson, whose technical blog 456 Berea Street is a must-read for CSS and accessibility aware coders.

So my first day on @media began with a walk through polluted London air along surveillance cameras and anti-tank barriers along the Houses of Parliament over to the queue in front of the Queen Elizabeth II Conference Center (QE2CC) where we got nice bags and name tags. I would suggest shawls with the @media logo for next year to stand a chance against the bloody cold air conditioning while it was 28° C outside.

Eric Meyer: Keynote

The conference started with a keynote by Eric Meyer with his personal impressions of the last ten years of the web. Quite interesting since I’ve been reading his articles on Web Review, where he published among other things the famous CSS browser compatibility chart, a great companion in my struggle with 4th generation browsers.

Looking back, he realized the following truths:

1. Small groups of dedicated experts can change a lot (e.g. the CSS Samurai, or Tantek Çelik who introduced doctype switching).
2. Free information is an essential part of any new web technology’s adoption.
3. You don’t hear much anymore from people or companies who kept information as a “personal advantage.”
4. You might be the first who thought about a certain solution. Savour this moment, and then share it.

Using DOM scripting to plug the holes in CSS

As an example, Jeremy Keith introduced the techniques of Buck Owens, the first musician to “hack” the tinny sound of early radios by replacing the bass with a regular guitar. So his tracks sounded better and got more airtime. Using DOM scripting to work around incomplete CSS implementations or to simulate CSS 3 behavior is basically the same, as long as there aren’t yet browsers with “great bass.”

Okay, most of the stuff in his presentation sounded familiar, and I’d rather set zebra stripes on table row backgrounds server side. Still I got some inspiration how to do some things better. For example it never occurred to me to combine selectors like

1. document.getElementById("id") .getElementsByTagName("p")

Or I never thought of using a universal selector in JavaScript:

document.getElementsByTagName("*")

Also the next time I’m manipulating an object’s class, I promise to do it by writing some reusable functions like

1. document.getElementByClassName()
2. function addClass(element, className)

And after I createElement I should set more attributes by setting a className instead of adding each attribute separately.

When he mentioned CSS 3, I learned that Safari is already capable of handling multiple background images. And I liked his introduction of the geeky Star Trek term of a “Kobayashi Maru scenario” for a no-win situation, or his translation of object detection

1. if (document.getElementById) { }

with “you must be this high to ride.” Rather cool, and a very entertaining presentation.

IE: 7 and beyond

Chris Wilson worked on the Mosaic browser (that’s, like, Netscape 1 — scary, isn’t it?) and on IE ever since version 2. Praise him for first implementing CSS in IE3, blame him for some nasty bugs he’s personally responsible for in IE6. Also he’s the one who wrote he will quit (and probably become a professional surfer) the day he loses his passion or IE gets mothballed again.

After some blatant promotion for all the outstanding new features and fixes in IE7, things you can read about in the IEBlog if you haven’t yet, he came to the interesting facts:

First of all, they are planning the next two releases now, and it won’t take another five years until IE8 will emerge. Also IE7+ for Windows Vista is only marketing speak, what counts is that it has the same features as IE7 for Windows XP, except for some vista-only security and parental control. IE7 will ship in “second half 2006.” More precisely, the Malaysian Vista developer Jabez Gan disclosed earlier that December 6 will be the release date.

Because of the deep interaction with the operating system they can’t push it as a critical Windows update, but they will “strongly encourage people to update.” The new fonts won’t be deployed with the update, more likely in a separate package, simply because with Unicode support some are too large.

On a technical side they are aware of developer’s problems to test on multiple versions of IE. Though it is technically hard to have a friendly co-existence of multiple IEs because they provide the operating system, it should be possible to create side-by-side versions of the browser only. Yay, that’s what we want!

Also they would like to support the XHTML MIME type, but want to do it right, later. Same is true for advanced DOM support, or passing the Acid2 test. What’s next for the web? Mashups, RSS, microformats, and XMLHttpRequest (did you know there’s a W3C working draft?). XForms is on their radar, but they need to coordinate efforts with other browser vendors.

Besides Chris recommended some tools like an expression finder to spot CSS hacks, or an application compatibility toolkit, stuff you can download as part of the Internet Explorer 7 Readiness Toolkit from Microsoft with a genuine copy or from someplace else without.

The new accessibility guidelines: WCAG 2.0

I had hoped that by visiting the panel about WCAG ['wu:kæg] I could avoid having to read the unreadable myself, but I was disappointed. You will read in another post about it. Not much else to tell about that panel, except WCAG 2.0 is probably not as bad as we have thought. There are notes and the slides available on accessify.com.

Designing the next generation of web apps

Jeffrey Veen is the partner of Jesse James Garrett who gets all the attention for coining the term “Ajax.” Anyway, Ajax is so going to change our world. Like the automobile, or the Great Depression. Some will get more mobile, some will get greatly depressed when the web becomes inaccessible.

In another panel the speakers agreed that Ajax can make live easier as an enhancement (Jeremy Keith calls it “Hijax”), but shouldn’t be a world of pain for the others. Actually I can see some of Jeff’s examples (use Stuart Colville’s notes to understand the slides) as an enhancement. Like giving immediate feedback when input fields in a form validate, while degrading gracefully by giving feedback after a regular submit.

You can enhance understanding by coloring and visualizing rainfall values in a nicely designed table, or you can further enhance it by making it interactive with a fader to choose cities on a map. But I can’t imagine how to have both.

In another example he showed a mashup of Google Maps with a Chicago crime database. Nice, but how can that be made accessible? So that people without JavaScript, or screen reader and braille display users with JavaScript can access the raw data table that lies under the visualization?

There was a lot of talk how today’s websites will be tomorrow’s web applications, but like Nate Koechley put it: You can’t just copy one aspect of desktop applications while ignoring the accessible alternatives. Desktop applications are accessible with multiple input devices, like a mouse or a keyboard. Screen readers can get the content. Don’t you forget it when developing the “next generation off apps.” There’s more than just good looks.