The Front-Trends 2010 conference took place last week. How did it go? Excellent.

Subjects ranged from web and mobile design, through CSS and markup to unit testing and server-side JavaScript. With the name of the conference explicitly mentioning trends, I was looking for some of them in the talks. In fact trends did emerge.

Mobile

I have been hearing about the need for focus on mobile web since years. Phones with web browsers have been around for a decade. So what’s the deal? Well, we reached a point when designing for mobile is not an extra activity that requires knowledge about obscure phone-only technologies (anybody still remembers WAP?). We can finally apply existing knowledge about web standards such as CSS and HTML. Surprisingly, contemporary smartphones often provide better capabilities than their desktop counterparts: Webkit has become a de facto standard rendering engine for the phones, while desktop web still struggles with IE6 legacy. Last but not least, better touch screens make browsing on the phone a pleasure rather than sadomasochistic experience it was just few years ago.

The subject of mobile web appeared in few presentations:

• “You know WebOS” by Markus Leutwyler
• “Cross-Device Applications Development”, talk about PhoneGap by Kamil Trebunia
• “Mobile UX and Current Trends in Mobile Design” by Antony Ribot
• “JSON over SMS” by Peter Paul Koch

PPK and Douglas Crockford – Panel Discussion; photo credit by Krzysztof Danek

Koch’s talk was certainly one of my favorites. For the last two years PPK has been working for Vodafone on what he does best: discovering quirks and bugs in browsers. Except this time he’s been doing this in the wild mobile world, where the sheer amount of browsers, resolutions, viewports and phone models can give a headache. In his talk he tried to predict how the mobile landscape will look like in 2018, when phones as powerful as today’s iPhone 3G will be accessible at 10 euro price tag. Make sure to check back this blog post in eight years to verify PPK’s predictions:

• HTML5 apps are the future, not the native ones. Only applications written with open standards ensure cross-platform interoperability and thus the broadest reach.
• App stores are destined to die. There’s already at least 41 of them – Apple’s App Store is just one of the many. The value they provide is either overrated (discoverability), already provided by others (payments have been handled by operators for years) or will be replaced by open standards (common APIs). What I am missing on this list is the convenience for users, so I wonder how this particular prediction will turn out.
• Access to phone features (calls, camera, storage etc.) will be standardized across different devices. WAC initiative is a step in that direction.
• High-speed network coverage will not grow as fast as the computing power of mobile devices. Thus there still will be the need for efficient and cheap data transfer format. This format could be a streamlined version of JSON sent over SMS (thus the title of the talk).
• We are about to see some totally new JavaScript events untangled by mobile devices, way beyond desktop metaphors such as click and hover. Think events like orientationchange, phonecall, move (GPS location change), cameraopen. Mobile context enables creativity that’s been somewhat missing in the desktop web in the last ten years.

My personal takeaway from the talks on mobile is that it’s worth to invest time now in learning how to design for this new environment. It’s not that hard to adapt existing web sites and web applications to mobile devices, but it requires consideration during design and development phases. Reasonably working devices and standards are already there. The share of users accessing the web through phones will only continue to grow.

JavaScript as THE programming language of the web

JavaScript has been around for over a decade and from the beginning it was used to spice up user interface (as any other spice, it has been widely abused). In the last 5 years – after “Ajax revolution” – it has become indispensable ingredient of web applications with heavy client. So what’s the news here? I think there are two, actually:

Douglas Crockford; photo credit by Morgan Roderick

1. JavaScript is now used for more complex tasks than ever before. Animations and DOM interactions, integration of browser APIs and web services – all this is done with JavaScript. As the applications become more complex, development style for JavaScript has changed. It’s no longer the fragile cycle: write, reload, pray it works. With tools like JSLint, Firebug and unit testing frameworks it’s finally possible to efficiently develop and debug even large JavaScript codebases. With complexity came new design challenges and the notion of “JavaScript application architecture” doesn’t sound ridiculous anymore.
2. JavaScript expands to the server side. This idea is not new. Proprietary solutions utilizing JavaScript syntax on the server side have been around since 1990′s, with Microsoft JScript being the most popular. But with node.js there seems to be finally a framework that embraces language’s philosophy (like architecture based on asynchronous callbacks) instead of merely using familiar syntax.

This changed approach to JavaScript was reflected in several talks:

• “JavaScript: The Rise of the Middle-End” by Kyle Simpson
• “Testing JavaScript” by Morgan Roderick
• “Test-First JavaScript” by Christian Johansen
• “JS Performances vs Common Good Practices” by Andrea Giammarchi
• “Using Web Services with JavaScript” by Chris Heilman
• “Server-Side JavaScript” by Douglas Crockford
• “Reusable Code, For Good Or For Awesome” by Jake Archibald

While I skipped the talks about unit testing (having a conference with two tracks enforces tough choices), it’s encouraging to see that unit testing and Test Driven Development are not anymore alien concepts in JavaScript world. To the point that they deserved a 600-page book written by one of the speakers. (Fortunately it’s not obligatory to read it in order to start writing unit tests in JavaScript.)

Kyle Simpson’s and Douglas Crockford’s talks addressed the subject of server-side JavaScript. It’s still in its infancy – e.g. there are not many libraries out there and even node.js is in an early phase – but I hope that eventually we will be able to run the same code on the server and the client. That was the premise of Kyle’s talk about middle-end, which was a fancy name for JS code that bridges the gap between the client and the server. Think about solution for eternal problem of validation code repeated in JavaScript and server-side language.

An interesting point was made by Douglas Crockford during the (excellent) panel discussion with PPK and Tantek Çelik: JavaScript has become a Virtual Machine for the world. Any application doing anything interesting on the web right now has to execute JavaScript in the browser runtime. It’s especially striking with projects like GWT, that allow developers to use their language of choice (in this case: Java), but eventually compile to JavaScript for execution.

One of the most inspiring talks of the whole conference was delivered by Chris Heilman. He first showed how to use JavaScript to create mashups connecting data from different REST web services. While totally feasible and not too complex, the task can quickly become tedious when developer has to go through registration process for different APIs and learn their details. Therefore in the second part Chris showed how to reduce the whole effort to two lines of code. Silver bullet? In fact it’s YQL, a language for web service integration with syntax similar to SQL. It takes care of the mundane details and allows developer to treat RESTful services or even regular HTML websites as database tables that can be joined and queried. For instance, imagine a query that takes Twitter messages in Polish with the keyword “Warszawa” inside and automatically translates them to English using Google Translation API. Sounds like a lot of work, but in fact it can be done with one line of YQL code. I knew that YQL has been around for a while, but the presentation gave me a boost to create something new with that shiny new toy. I mean tool.

HTML5 and CSS3

A conference about front-end development cannot happen without addressing web standards. On Front-Trends CSS3 and HTML5 were all the rage. While both buzzwords were repeated like a mantra in most of the talks, three presentations went into details:

• “JavaScript & HTML – Brave New World” by Robert Nyman
• “Pragmatic CSS” by Lea Verou
• “HTML5: Right Here, Right Now” by Tantek Çelik

Lea Verou; photo credit by Krzysztof Danek

According to people who have seen it, Lea’s presentation was one of the best of the conference (unfortunately I missed it). She published her slides online and they’re definitely worth checking. The presentation itself is written in HTML5 and styled with CSS3. Lea went through several new CSS3 properties, explained them and showed how they can be used to simplify the code and deliver features that were previously hard or impossible to implement. All this was accompanied with information about browser support, so one can tell immediately how feasible is the cutting edge. Spoiler: a lot from CSS3 can be used right now.

The talk by Tantek Çelik was in a similar spirit. Tantek went through most of the new features of HTML5 and grouped them into five buckets:

1. dependable now
2. roughly usable
3. awkward
4. interesting but ignorable
5. worthy of experimentation

I strongly recommend checking his slides as they give a primer of what’s possible now with HTML5 and what’s just around the corner.

One of the highlights of his talks was a call to action: send the following tweet to Internet Explorer 9 team:

Dear @IE: please implement Geolocation API, it’s Candidate Recommendation now!

Tantek Çelik; photo credit by Krzysztof Danek

Tantek is a former Microsoft employee and a person behind IE5 for Mac, known at the time for its excellent CSS support. Microsoft is usually implementing W3C specs that reached certain level of maturity, so there’s a hope that Geolocation API will make its way into IE9. I have sent a tweet, have you?

Truthy value

The conference was not without some flaws. In accordance with long tradition of tech gatherings, the wifi didn’t survive the rush of 300 bandwidth-hungry nerds. Nevertheless, the whole event was fantastic.

I’ve already heard about most of the new developments shown during the conference. Yet after leaving the venue I felt inclined to give some of them a try NOW, instead of waiting for IE8′s death in 2050. If the conference inspires you to try something new, could you wish for something more?

Adobe Flash has been dubbed a casualty of this revolution – a few days ago I saw a link to a demo of new CSS features, with animated text saying: “Die Flash, die”. In spite of all this, a few weeks ago I started to learn Flash. And, I must say, the rumors of Flash’s death have been greatly exaggerated.

How I have fallen to the dark side

It all started when my friend Łukasz, a graphic designer, showed me a design proposal for his online portfolio. The project included interactive image browsers with real-time reflections, shadows and some perspective effects. It was a perfect opportunity to play with cool toys, like HTML 5′s canvas, custom fonts and new CSS properties, so I decided to code it.

However, the more I read about features required to implement this mini-site, the chances looked more gloomy:

• CSS image effects, like reflections, can be now used only with Webkit nightly builds.
• canvas element is a more widely available alternative, but, obviously, Internet Explorer doesn’t support it and needs JavaScript libraries for emulation.
• canvas API is very low-level. In practice, piles of complex code are needed to achieve the simplest effect. Libraries supporting such effects either don’t exist or have very limited functionality.
• The performance of the above libraries is less than satisfying.
• Getting custom fonts to work in CSS is a nightmare, even if the font itself is free. It’s a topic for a separate story. Let me just say that converting from Open Type Font (.otf) to Microsoft’s .eot format turned out to be beyond my skills (and the budget).

Enter Flash

Eventually I implemented the site with Flash. It was my first Flash project, but the tool was mature and well-featured, documentation was complete, and libraries and tutorials abundant. I bought the license.

The site is very simple: an animated image browser with preloader and some effects calculated in real-time. Sadly, achieving the same results with a combination of HTML, CSS and JavaScript is just not possible yet. I also noticed something even more disturbing: a guilty pleasure from using a reliable tool, where everything works as documented. This is a liberating experience for someone who used to work with web browsers. The discreet charm of proprietary platform has its price, but still: it’s so fine!

What exactly makes Flash such a great tool to work with?

ActionScript

While the future of JavaScript 2.0 is still unclear, ActionScript 3.0 – the programming language of Flash platform, already offers the best of both ECMAScript and compiled languages:

• Variables can be (optionally) typed to allow compile-time type checking and type-based code completion in the IDE.
• The code can be neatly organized in namespaces, packages and classes.
• Inheritance is supported through prototypes (like in JavaScript) and classes (like in Java). Though JavaScript is a fully object-oriented language, I find Java’s syntax for OOP more straightforward.

Rich API’s

Flash provides today some API’s which web developers are craving for. Few of these API’s (e.g. E4X) are already available in some browsers, but developers cannot rely on their presence. On the other hand, Flash already shines here:

Multiple file upload: we still need to wait few years for this to work in HTML

• URLLoader class provides the ability to send HTTP requests and get progress information necessary for preloaders.
• DOM interaction is simplified with the support for E4X. Mozilla Firefox has supported it for the past few years, but it still doesn’t work across all browsers.
• FileReferenceList class allows multiple file selection and upload. I think it’s embarrassing that <input type="file"/> still needs to wait for HTML 5 to adopt this “technological breakthrough”.
• ExternalInterface serves as a bridge between ActionScript and JavaScript. It can be used to access DOM and populate Flash movies with content coming from HTML.
• Animation is easy. Originally Flash was a tool for annoying users with bouncing balls and flying rectangles. In the course of the years it has become more useful, but animation is still one of its biggest strengths. What I like the most about animating with Flash is a straightforward programming model: elements on stage are objects whose properties can be manipulated. It’s not yet possible with HTML 5′s canvas, where the scene needs to be composed from individual pixels or basic shapes in a loop, frame by frame. This difference alone already makes animating with Flash easy compared to HTML/JavaScript alternatives – and I didn’t even touch the topic of browser performance and compatibility…

Speaking of which:

The platform

Flash Player is now the most widely available programming platform. Adobe has managed to deploy new versions really fast so that developers can safely assume the presence of the player which is one-year old or newer. Combine this with the fact that Flash is backward compatible and you’ll get a platform you can rely on (with the notable exception for the iPhone). Again, this is refreshing for anyone tired with differences among web browsers. To be fair, Firefox 3.5, Google Chrome and Safari 4 offer high levels of compatibility and performance, but IE6 and IE7 are a few years behind. Most likely IE8 will be equally outdated before it disappears from the market. Most of the development time in modern web apps is spent on fixing differences between browsers. Libraries, like jQuery, make life easier, but it’s unlikely to ever have a homogeneous environment with so many rendering engines out there.

Meanwhile, Flash is backward compatible, quickly adopted and robust. And when you’re done with writing the code, it just works. Unbelievable.

A good example is of the above is custom font support. Flash has it for what seems like ages. It’s been the foundation of sIFR. On the browsers’ side of things: latest versions of Safari and Firefox support direct embedding of TrueType font files, outraging font foundries. IE supports its own format EOT since 1997, but nobody else seems to be interested in implementing it. There’s dozens of hacks using anything from drawing letters from vector curves with canvas to centrally-hosted font licensing service. In short: it’s a mess with unknown outcome, whereas in Flash it just works.

Before you jump in

Having said all that, I still believe that open web standards are the way to go. Incompatibilities are the price for progress and competition. Features of HTML pages, like Unique Resource Identifiers or readable source code can be easily overlooked. Yet, they made it possible for the web to grow so fast and become an integrated system rather than a set of separate data islands. As it sometimes happen to Flash pages, forgotten by God and search engines.

Flash has improved over the years, but it still has some serious problems. Some of these problems might be solved someday, some are innate:

• The only practical way to develop with Flash is to buy an expensive IDE.
• There’s a single vendor controlling the format. It makes developers’ life easier, but introduces the risk of lockdown.
• Flash files are alien objects on web pages. Only recently they received (rather limited) support from main search engines. They cannot be crawled so easily as HTML or XML files.
• For the same reason, significant effort is required to enable URL-based linking on Flash pages. With HTML, it comes for free. And even with an added bonus: Back button support.
• Flash still poses serious accessibility problems for disabled people. SWF files are not part of the tabbing order in browsers other than IE on Windows, making Flash sites virtually inaccessible. More importantly, Flash is an intrinsically visual environment, built around graphics and animation. HTML is deep-rooted in text, with other layers, like JavaScript, added on top of it. It makes it much harder for Flash to be easily translated for vision-impaired users.

2advanced.com – Flash at its best, as of 2001

There’s also one non-technical problem, raised by Jacob Nielsen in his famous essay Flash: 99% Bad: Flash encourages design abuse. With Flash it’s so easy to abolish conventions and develop “creative” and “innovative” projects. For a long time the safest way to win a web design award and recognition among “progressive designers” was to create an unusable clone of 2Advanced.com. Apparently, such sites served no other purpose and are now long forgotten. To the surprise of progressive designers, users turned back to “ugly” and “uninspired” sites, built without bells, whistles and Flash.

Fortunately, a lot has changed since the original Nielsen article. Flash still offers a wide range of tools for harming users, but it can be used for the good too.

Flash enhancement

Gmail – Flash in 2009

If 2Advanced.com was the example of a Flash site in 2001, Gmail is the example of how Flash can be used in 2009. If you check the HTTP traffic on Gmail, you’ll notice few SWF files. They’re used there to play sounds in chat, support video and display upload progress. Unlike the artificial, hi-tech interface of 2Advanced.com, Gmails feels like a normal web page. Flash is entirely transparent to the user and augments, not replaces, core elements built with HTML, JavaScript and CSS.

This attitude towards Flash is worth embracing if you’re a web standards fan. Until browsers will consistently support what web developers need, Flash will be a viable tool to overcome the deficiencies. Frankly, I don’t expect the current situation to end any time soon: legacy browsers like IE7 (not to mention the living dead, IE6) won’t disappear quickly. And even though HTML 5 is gaining grounds at rapid pace, Flash doesn’t stale either. When HTML 5 will be finally ubiquitous (in the year 2022, according to the spec’s editor Ian Hickson), I’m sure Flash will have something exciting up its sleeve.

Flash knowledge is certainly a valuable asset in a front-end engineers’ arsenal. Flash can be used today to enhance user experience and provide functionality that otherwise wouldn’t be possible with current browsers. In fact, it’s already used to enable:

• custom fonts
• multiple file upload with progress indication
• Comet pattern (aka “push”)
• video!

Flash provides numerous API’s that can be called from JavaScript and used to enhance HTML-based web apps. It also works the other way around: Flash can access the DOM of its own HTML page. SWF file can display HTML text with special effects or animate images embedded in the HTML source. It means that Flash-enabled browsers can display fully-fledged animation while other user agents, like search bots, can still crawl HTML content. That’s exactly what progressive enhancement is about: provide the best experience possible, but still allow less capable devices to access the information.

So, if you’re facing a complex problem in your web app, maybe an answer is already there?

The first argument is particularly valid. Writing stylesheets often requires magical powers and is not straightforward at all. But the problem lies at broken implementations (sometimes referred to as “browsers”) rather than in CSS itself. The second shortcoming is clear when it comes to managing large websites. During the last few months I’ve been working on a custom intranet content management system as a frontend developer. Let me share my experiences from this project. I’m really eager to hear comments from you, especially if you have your own experiences with large scale projects using CSS extensively.

Requirements

The single installation of our CMS in theory can handle even few thousands of websites arranged into groups. Typical group contains from one to over a dozen of websites. Each group is a separate entity, owned by a customer who’s also responsible for the content. While websites and groups are managed by different people, they all share similar layout and main functions. It assures consistency across the intranet. Websites within groups are even more alike to each other, as they usually serve the same purpose.

As you can see, the above setup is very similar to a typical portal or large e-commerce site. There are independent sections updated by different people but sharing some common branding elements and structure.

During system design phase, I aimed to:

1. Preserve consistency across all the sites.
2. Allow for design flexibility.
3. Maximize code reuse and avoid copy and paste programming.

The hierarchy

We (me and other members of my team) decided to create a 3-level hierarchy for CSS, JavaScript, images and template files. At the top (“root”) level we put all files needed to lay out a website. So if you set up one, it gets the default look based on files from a root level.

The particular website uses files inherited from its group and root level

To create a custom appearance for a group you’d need to put new files at lower level. The set of available files has been defined at the beginning and slightly updated when needed. For example the home icon is always /images/icons/home.gif. If you want to use a completely different icon for the group, just put this new image in the corresponding location on the group level. The same rule applies when you want to introduce further customization on the website level: you just need to place the file in the proper location at the bottom of the directory tree.

How does the CMS know which one to choose? It’s looking for the files from the bottom up. If the image, script or template is found on the website level, then it will be used. Otherwise the application looks for the same file at the group level or, if it’s not here, at the root level. CSS stylesheets are handled a bit different. The ones from lower level do not replace the files above, but instead are appended at the end of their “ancestors”. The server-side mechanism merges all the stylesheets with the same name and sends the result to the browser as a single file. This exception was made for a reason. CSS rules rarely have to be created from scratch — it’s much easier to define common setup and then to extend it by overwriting individual rules or adding new.

How this approach works in practice? Surprisingly well. Since all the files needed for laying out a new site are already at the root level, content managers can quickly create a running site and edit content. They don’t have to wait until designers will finish their work and provide finished design specification. As all websites share the same codebase they are all consistent. It’s also very easy to introduce global changes. All you need is to put the code at the top CSS file, and all the websites will inherit it. Finally, there is no need to copy the code. You just have to write things specific to the group or website.

But there is always “but”

All the good things come at some cost. The biggest difficulty with the hierarchy is to control the differences between portals. It’s easy when they have the same grid and typography, and the only differences are colors or images. Things start to get complicated when each group or even website introduce a new layout. Multiply the number of CSS files by 50, and you will get the picture. Updates that require overwriting a single rule are easy to implement, but layout changes quickly become hard to manage. In order the make it work the designer have to keep the discipline. And have you ever tried to “discipline” your client’s requirements?

Another issue is related to features that are used across few groups but not everywhere. Where should they belong? If you create a copy in each group this feature is needed, you’ll quickly face the problem of managing these different copies. Putting them at the root level sounds better, but in that case all other sites will use bloated CSS stylesheets.

Going further

How to overcome these problems? The latter could be addressed by further modularization of CSS files. Currently I’ve split stylesheets into few files. colors.css, grid.css, forms.css handle most distinct areas of a design, while main.css is used for typography, background images and small details. Distinct areas – such as navigation, header, login form – could have their own stylesheets. These stylesheets should be then included on portal level only when needed. The pros of this approach is the minimization of the code bloat — only actually used sets of rules would be included. To make it really work CSS files should be merged on the server. Otherwise dozens of HTTP requests would kill the performance.

Another idea that pops up is to provide few file hierarchies, each defining completely different visual structure. It would let the designer to have more flexibility. Moreover, a single installation of the CMS would be able to handle many diverse groups of independent websites.

I’m using a subjunctive form when writing about these improvements, as I haven’t tried them yet. What’s clear to me, after few months of learning by trial and error, is that there is no silver bullet. Each solution involves compromises and has liabilities. Managing the code of 50 websites can get tricky. Things get even more interesting when three frontend guys work on the same code simultaneously. But CSS, with all its quirks, glitches and flaws, simply works. Updates and fixes are quick. Usually I don’t even touch HTML templates: the rule “write once and forget” can be applied only with web standards approach.

Yet, I’m sure some things could be improved. What are your ideas? Do you have similar experiences? Please feel free to share!

The conference was held in Queen Elizabeth II Conference Center on 15th and 16th June. For those who wanted to get the most of this unusual gathering of web standards geeks, there were also unofficial meetings (also known as “parties”) at Wednesday and Saturday, and after each day of the conference.

It was the first time I attended this kind of event. But I enjoyed it not only because of initial excitement. The meeting was also a great chance to listen and say hello to people like Dave Shea, Simon Willison, Cameron Adams, and many more I admire and previously knew only from their blogs. Even though it was difficult to hear something you never ever read before in the blogosphere, it’s always great to ask questions directly to the members of the web vanguard.

You could find a complete list of sessions on the conference’s website. I hope podcasts and slides will be there soon. Given that, let me focus on few selected presentations I enjoyed the most.

IE 7 and beyond

Chris Wilson back then and now

I had a really big expectations before this talk given by Chris Wilson. Chris is a Group Program Manager for Internet Explorer 7, aka The Man to Blame. If you’ve been following IEblog, there was not too much news in the Chris’ presentation: he focused on RSS related features and support for OpenSearch. The latter is a standard that allows any website to be searched directly from the browser. It is similar to custom search engines you know from Firefox, but uses XML rather than some custom markup. (Firefox 2.0 will support OpenSearch too.)

Predicting that this issue will be eventually raised, Chris mentioned the support for running IE 7 next to IE 6. He said that it wasn’t disabled intentionally, to prevent developers from testing websites in both versions of the browser simultaneously. While it’s unlikely that we’ll be able to have two fully fledged IEs on the same machine because of the browser’s strong integration with the OS, in the future we may could use both rendering engines for testing. Chris said that the Internet Exporer team is working on this. I really hope it will be possible, since now IE 7, when installed next to IE 6, requires some nasty registry hacks and eats 100% of the processing power.

Chris mentioned the highly anticipated better support for webstandards, which provoked me to ask a question about his view on the work done by WHAT WG. (This a group of people from Apple, Mozilla and Opera who work outside of W3C on updating the HTML specification to better support developers’ needs, especially in the field of web applications). Wilson is very skeptical about these developments and the way they’re done (ie: outside of the W3C). He also claims that they may break several patents. Thus I think that it’s very unlikely that we’ll see support for canvas element or HTML 5 any time soon in IE.

The New Accessibility Guidelines: WCAG 2.0

The WCAG Clan

After the lunch I was listening to the panel about the new, highly criticized Web Content Accessibility Guidelines, version 2.0. The panelists, — Andy Clarke, Patrick Lauke, Gez Lemon, and Ian Lloyd — were trying to explain the thinking behind WCAG 2.0, especially the idea of being “technology agnostic”. Yet, they didn’t even try to pretend that it has anything to do with “comprehensible”. The new guidelines don’t mention specific technology which makes them general and universal. Unfortunately, they’re also abstract to the point they may become useless: if content authors won’t be able to easily understand them, how can one expect that the guidelines will be actually implemented?

There are small lights in the tunnel, though. After recent Joe’s Clark article, To Hell with WCAG 2, there is a lot of talk about new guidelines and hopefully it may cause WAI members to make guidelines more, ehm, accessible. The last call period for the spec was extended to 22th June. Personally I doubt if it will matter much. The recently formed WCAG Samurai, the group of people with deep knowledge and interest with the state of accessiblity, may come up with something much better. The panelists seemed to be looking forward for Samurai’s work. As I’m sure Samurai people will create something worth of attention, I wonder if they’ll have as much impact as W3C has. This is an important factor, since WCAG guidelines are not just some geeky specs, but also a baseline for accessibility regulations in many countries.

One of the panelists, Gez Lemon, mentioned the page I personally find very useful: WCAG 2.0 Quick Reference. The guidelines are presented there as a customizable list, along with links to related CSS and markup techniques.

Designing the Next Generation of Web Apps

Jeffrey Veen

The first day ended with Jeffrey’s Veen presentation. I’ve read before that Veen is an awesome speaker, but what I saw on stage was beyond my expectations. All the sessions were recorded, so I hope that the video with his performance (the word presentation is not accurate enough) will be published somewhere. Although Jeff left no doubt that the phrase Web 2.0 is actually extremely passé now, he did his best to show what we could learn from this buzzword driven fad.

DOM Scripting: The Next Level

The longest part of the JavaScript panel

Next morning I enjoyed the panel led by Cameron Adams. The panelists have showed a broad spectrum of views on JavaScript libraries. PPK doesn’t use them at all, Dan Webb is very skeptical, Stuart Langridge use them to simplify tedious tasks such as Ajax scripting, and Simon Willison seemed to be the most enthusiastic about them. It’s clear that, as tempting as they might look, the libraries could easily be source of the disaster if you belive that you could use them without deep understanding of JavaScript. I think it was the main point of this session: use them, but only if you know what you’re doing.

Both Stuart and Simon were very positive and optimistic about dojo. Although this library is still in an early stage of development and needs more documentation badly, it also has a widest set of features and introduces many innovative concepts, such as compression based on real JS parsing or client-side persistent storage. The drawback is that dojo is a kitchensink now, with a lot of magic going on under the hood.

On the sidenote, it was really nice to see Simon talking very positively about dojo, even though his current employer promotes a different library now.

Internationalization: Awakening the Sleeping Giant

God is in the details

Later on I enjoyed Molly’s Holzschlag session on internationalization. Although Molly only touched the tip of the iceberg, she made a really important point: internationalization and localization are much more than translation. When creating a localized version of the website, we must think not only about particular words but also about text layout, keyboard usage, iconography and even color, as its meaning changes across different cultures. I feel obliged to note that Molly is very energetic and engaging speaker. It was a real pleasure watching and listening to her.

Microformats: Evolving The Web

Tantek Çelik

The last presentation was given by Tantek Çelik of Technorati and IE for Mac fame. Tantek is one the people behind microformats, a set of pieces of basic XHTML augmented with class attributes. The idea behind microformats is to build a publicly agreed standards for common pieces of data we used to put on the web very often, such as contact information.

In my opinion it’s much like a “Semantic Web for the poor”. The Semantic Web is a set of W3C standards, such as RDF and OWL, created to make the data easily parsable by spiders and interchangeable. Unfortunately, the Semantic Web didn’t make its way through the internet yet and I doubt if it will any time soon. Standards are complicated, the required knowledge level required to make use of them is high and most web developers never heard of the idea before, not to mention implementing this. After reading several articles on the topic on great Michał’s Świątkiewicz weblog (unfortunately it’s only in Polish now) I became enthusiastic about the idea, however I’m still very skeptical about the adoption of these standards.

Microformats aren’t as sophisticated at all. They’re build upon technology any web developer already knows — XHTML. Tantek pointed out two important things that make microformats so promising. First, they’re searchable by contemporary search robots. There’s also this “laziness factor” we should never underestimate — the Web has already shown that simple, open solutions based on existing technologies have much more chances to survive.

I asked Tantek whether he sees microformats as competitor to Semantic Web standards. He admitted this, but also pointed out that microformats could be easily transformed to RDF using XSLT. They’re pieces of well formed XML, after all. So even though personally I’d like to see a broader adoption of RDF, microformats can be a step in a good direction, too.

Hot Topics

“Hot Topics” panelists

For my surprise, the ending “Hot Topics” panel turned out to be one the most engaging parts of the conference. The panelists, Molly, Jeremy, Jon, Tantek and Eric, shared their thoughts on such deep topics as “What’s your favourite furry animal?” (obviously Ewok left all the competitors behing) and “Who’ll win the World Cup?” (we should soon see for ourselves whether Eric was right, betting on New York Knicks).

There were also other, at least equally insightful, questions.

In the era of web applications, what we could learn from traditional GUI designers?

Panelists tend to agree that… not too much, since a lot of existing conventions don’t fit the web or poses unnecessary limitations. Jon pointed out that on the web users have a much more control over the interface. Users can now set up the text size or use own stylesheets.

Tantek said that one big missing feature of web apps is the lack of undo function. When present, it could eliminate the need for disturbing confirmation dialogs, which break the workflow. The Back button should carry out this role but it still doesn’t work well with current generation of web apps.

Can Ajax be made accessible?

This question caused a lot of consternation. I think that Eric phrased it in the best way: “It can be, but will be?”. In order to make Ajax really accessible, significant changes are required in browsers and screenreaders. Tests show that even sophisticated Ajax applications may work with screenreaders. On the other hand, Tantek mentioned that 15% of Technorati user’s have JavaScript disabled. It’s a huge number that shouldn’t be understated. Technorati’s Watchlist was mentioned as a good example of Ajax application that degrades nicely when JavaScript is not available.

Isn’t the massive movement of high-profile web designers to large companies like Google a little worrying?

All of the panelist don’t work for Google or Yahoo! (yet) and all of them were a bit concerned. The good thing is that the companies mentioned give out for free a lot of great services. But the problem can be that they also tend to limit the sharing of the ideas. When inside the corporate giant, web designers and developers are often limited on what they can show to the world. The obvious sign of this is that many of them blog much less now.

Jon was worried that a lot of people now start their own web ventures just to be bought by Google or Yahoo later on, instead of providing actual value to the users. Personally I’m sensing a gloomy shadow of Paul Graham here.

Summary?

Unfortunately, I didn’t attend the Saturday get-togethers, so “Hot Topics” panel was the last session for me, beside the after conference party. The conference was a great experience. I can’t wait for the next year.

Właśnie. To chyba pierwsza z dość już sporego zbioru książek o standardach internetowych, która jest skierowana do bardzo konkretnej grupy odbiorców. Co prawda na początku autorzy zarzekają się, że jest ona równie dobrze przeznaczona dla programistów, ale myślę, że najwięcej korzyści odniosą z niej ludzie zajmujący się projektowaniem wyglądu stron oraz tworzeniem szablonów XHTML i CSS. I bardzo dobrze. Słynna Pomarańczowa Książeczka Zeldmana miała trafić i do managerów, i do programistów, i do projektantów, a ostatecznie może znudzić ich wszystkich. Co stwierdzam z przykrością i pomimo sympatii dla autora.

Osobom interesującym się CSS-em raczej nie trzeba przedstawiać autorów, ale na wszelki wypadek przypomnę, że Shea jest pomysłodawcą CSS Zen Garden, chyba najlepszej w sieci demonstracji możliwości, jakie projektantom daje CSS. Prowadzi też bardzo dobrego bloga mezzoblue. Molly Holzschlag jest ostatnio znana głównie z tego, że współpracuje z zespołem tworzącym Internet Explorera 7 jako przedstawicielka Webstandards Project. Jak widać, oboje znają się na rzeczy.

Co więc można znaleźć w książce? Całość obraca się wokół projektów stworzonych na potrzeby założonej przez Dave’a strony CSS Zen Garden. Kod XHTML napisany przez Shea’ę został ostylowany przez wielu naprawdę świetnych projektantów, a efekty ich pracy — grafikę i arkusze stylów — można oglądać na tej stronie. Miło jest odnotować, że wśród projektów dokładnie opisanych w książce jest też No Frontiers! “naszego” Michała Mokrzyckiego.

Książka podzielona jest na siedem części, z których każa omawia na przykładach wybrane zagadnienie związane z projektowaniem z użyciem CSS:

1. View Source to analiza XHTML-a, który powstał na potrzeby Zen Garden. Zawiera dużo cennych wskazówek, jak pisać elastyczny i dający się łatwo stylować kod.
2. Design — rozdział poświęcony między innymi dobieraniu kolorów, kontrastu i oświetlenia.
3. Layout to omówienie możliwości, jakie daje CSS podczas projektowania układu strony. Przedstawia różne metody pozycjonowania elementów.
4. Imaginery to część poświęcona tworzeniu grafiki strony. Zawiera zarówno garść wskazówek przydatnych zarówno podczas pracy z Photoshopem… przepraszam, programem graficznym, jak i umieszczania swoich dzieł na stronie za pomocą CSS.
5. Typography. Można tu znaleźć kilka naprawdę cennych uwag na temat czytelności i różnorodnych technik manipulowania tekstem.
6. Special Effects przedstawia nieco bardziej zaawansowane zastosowania CSS. Głównym bohaterem negatywnym tego rozdziału są ograniczenia Pewnej Przeglądarki ™ i metody radzenia sobie z nimi.
7. Reconstruction omawia bardzo szczegółowo kilka wybranych projektów i pozwala na prześledzenie krok po kroku procesu budowania strony.

Całość jest przyjemna w czytaniu, choć fani błyskotliwych dygresji a’la Zeldman mogą poczuć się zawiedzeni. Jak wspomniałem na początku, głównym adresatem są projektanci i może dlatego autorzy nie wdają się w szczegółowe omawianie różnych niuansów specyfikacji. Na przykład po macoszemu potraktowano jeden z problemów, który sprawia problemy nawet zaawansowanym znawcom CSS: tworzenie elastycznych układów z użyciem właściwości float.

Mimo to książka jest naprawdę praktyczna i nawet osoby pewnie czujące się w tej dziedzinie znajdą w niej coś dla siebie. Z tak zwanych dobrze poinformowanych źródeł wiem, że trwają prace nad polskim tłumaczeniem. Mam nadzieję, że zostanie równie starannie przygotowane i wydane jak oryginał. Warto mieć na półce, polecam z czystym sumieniem.