Introducing theexpressiveweb.com beta

We recently launched a beta of new site we have been working on, called theexpressiveweb.com. This is a project we have put together with the help of Big Spaceship with the goal of creating both a resource and showcase that highlights some of the most creative and expressive features being added to the web today (see Figure 1). In addition to highlighting and providing information on twelve new HTML5 and CSS3 features, the site itself makes extensive use of new features such as CSS3 transitions, CSS3 transforms, web storage and more to provide a visually compelling resource for learning more about HTML5 and CSS3.

The site highlights the following HTML5 and CSS3 features (see Figure 2):

• CSS3 animation
• CSS3 gradients
• CSS3 media queries
• CSS3 shadows
• CSS3 transforms
• CSS3 transitions
• CSS3 web fonts
• HTML5 audio
• HTML5 canvas
• HTML5 forms
• HTML5 video
• Web storage

Each feature page contains:

• A demo of the feature.
• Data on browser support.
• Links to examples in the wild that use the feature.
• Links to more in-depth resources and tutorials.
• Detection and fallback strategies for the feature.

The goal is to provide a quick introduction and understanding of the new features, and provide information and links so that designers and developers can gain a deeper understanding of what the feature is, what it can be used for, and how to use it.

So why is the site launching as a beta? Well, the simple answer is that there are still some bugs in the site, particularly on older browsers and some devices. Despite this, we decided to launch the site as a beta, so we could share the resources and information with the community, share some of the lessons we learned developing the site, and get feedback on the site.

When we started development on the site a couple of months ago, we laid out an ambitious plan for a site that leverages and highlights a wide range of cutting edge features. Indeed, in hindsight, we were probably a little too ambitious in our reach. In addition to dealing with the normal cross-browser issues when doing web development, we now had to deal with a large amount of functionality core to the site not being supported consistently (or at all) between browsers. While this is a particular issue for older browsers, it was still a problem for the most current browsers. For example, the site uses CSS3 transitions to animate page transitions, a feature which the current shipping version of Internet Explorer 9 does not support.

We could have chosen to only support the most current browsers, but we felt that even if the feature demos would not be supported, the resources and content listed on each page would still be valuable to developers and designers. Thus, the site runs on older browsers such as Internet Explorer 7, even though most of features being highlighted are not supported.

Of course, dealing with cross-browser differences is a reality of web development. You need to develop with this in mind and develop fallback strategies for when required features are not supported. In our case though, since we were specifically trying to highlight the new features, we had to deal with a lot more browser support and implementation issues than an average site normally would.

So, what are some of the lessons we learned from creating a site that makes extensive use of new HTML5 and CSS3 features?

Decide early whether to support older browsers

Supporting older browsers when working with newer features adds an additional level of complexity to the project. The more new features you add, the more work you have to spend implementing and debugging fallback solutions in older browsers.

At a minimum, make sure you have a solid understanding of how well new features degrade. For example, If web fonts are not available, then you can easily fallback to a built-in font. However, if CSS3 animations are crucial to your site, then you may have to do additional work to implement the animations via JavaScript for situations where CSS animations are not supported.

If you do decide to support older browsers, then you may want to consider scaling back the number of newer features that your site relies on.

Only use new HTML5/CSS3 features essential to your site

For each new, cutting-edge feature you use in your project you have to consider the development time and cost of each of the following:

• Implementing a fallback strategy for browsers that do not support the feature.
• Dealing with differences in feature implementations among browsers that do support the feature.
• Being prepared for new browser versions to change their feature implementations (more below).

This holds especially true when targeting older browsers that may not support some of the newer features.

This does not suggest that you should not use newer features, but you need to be aware up front of the development and maintenance costs that that can entail. By focusing on just the features essential to the site, you can help reduce the overall impact of the items above.

Plan for more maintenance after release

This is something that caught us a bit off-guard. If you are building a site that makes extensive use of new HTML5 and CSS3 features, you need to plan on having higher than normal resources for maintenance.

This is because HTML5 and CSS3 consist of relatively new features which have not necessarily been standardized. Because they are so new, browser implementations may (and will) change between releases.

Unfortunately, we discovered this the hard way. Apple released Safari 5.1 about a week before the site launched, and the release ended up breaking a couple of things on our site. The more time passes after the launch of your site, the more browser releases there will be, and thus the more likely things on your site will break. Of course, this applies to any web content, but given how new these features are, it is a particular issue when using some of the newer HTML5 and CSS3 functionality.

Performance is not just about JavaScript

When we first started the project, our main performance concern was around differences in JavaScript execution between browsers (especially older browsers). However, as we began to implement some of the CSS3 transitions for page transition animations, we had to deal with differences in animation performance between browsers.

As more and more websites use motion graphics, this will become an important issue for content creators. For example, in the case of CSS3 transitions, there were two primary causes of differences.

First, some browsers hardware accelerate CSS3 transitions, which can provide very good animation performance. However, not all browsers do this. In our case, animation performance was the same, but CPU usage could be significantly higher than when the transitions were not accelerated.

Second, animating content on devices can have dramatically different performance profiles. Not just between desktop browsers and devices, but among different devices. For example, we found that for our project the Apple iPad provided much better animation performance than that on the Motorola XOOM.

The key is to understand what the boundaries are for your particular motion graphics, and when performance degrades to a point that you need to consider implementing a fallback solution to a less intensive animation. This boundary will vary from project to project.

In the case of theexpressiveweb.com, when a browser or device cannot smoothly play the animation, the site switches to a less intensive transition that builds in the graphics by making them appear, as opposed to animating them in from the side.

Don't move too many things at once

This one is pretty simple, but as a general rule, the fewer things you simultaneously animate, the smoother your animations will perform.

On theexpressiveweb.com, when you change pages a couple of things happen:

• Page navigation and information elements animate out
• Page demo builds out
• Page navigation and information elements animate in
• Demo assets animate in

Some browsers could handle all of these elements animating at the same time. However, some browsers had trouble animating all of the elements smoothly. We fixed this by first animating in the navigation elements and content and then beginning the page/demo transition.

Not only did this provide smoother animations, but it also provided the user with information and content earlier, both of which make the site feel much more responsive.

Have a fallback strategy for key features a core part of the development plan

You should have a fallback strategy for any new HTML5/CSS3 features you are using. This is particularly important for features that are key to the site or the experience you are trying to create. For those features, you need to develop the fallback strategy from the beginning as a key part of the site development and design process.

For theexpressiveweb.com, we make extensive use of CSS3 transitions to animate page transitions. These motion graphics are a key part of the experience on the site. Because they are so key, we had to develop the site with a fallback strategy in mind from the beginning.

As mentioned above, if CSS3 transitions are not supported (or do not perform well), then the site falls back to simpler animations for the page transitions. This still provides a good (although slightly degraded) experience for the user.

We could have fallen back to animating the transitions using JavaScript, however, we found that JavaScript-based transitions did not perform well in some cases (especially on devices). Since we would still have to implement a simpler and more performant transition for those scenarios, we decided not to implement an additional fallback via JavaScript.

Design and develop with mobile in mind

While keeping mobile browsers in mind is important when designing regular websites, it is particularly important when designing and developing sites that use motion graphics. In addition to having to deal with differences in device resolution and input methods, you also have to pay particular attention to performance of any animations.

In general, mobile browsers provide better all around support for newer features, and provide good support for hardware acceleration of CSS3 transitions, transforms, and animations. However, any motion and animation has the prospect of severely taxing the browser and device. Understanding these limitations early in the development cycle will make your development process much smoother.

Use Modernizr

There is not too much to say here. If you are using newer features, you need to make sure the browser supports those features. The Modernizr library is hands down the easiest, and most robust way to detect which features are supported by the browser.

If you need to check frequently for feature support through your site, it might be worth it to do all of those checks on first load and then saving the results, as opposed to checking each time the check is needed. We found that in some situations this could provide a noticeable improvement in initialization performance.

Tooling

One question that we have been hearing is what tools did you use to build the site? Specifically, did you use the Adobe Edge Preview to build the site?

Well, first, the team used all of the same tools other web designers and developers use to develop websites. These include tools such as Adobe Dreamweaver, TextMate, Coda, and Photoshop. We also used Adobe Flash to create the sprite sheet animations which are used on the HTML5 Audio page.

However, we did not use the Adobe Edge Preview to create the motion graphics for the site. We began the project a couple of months ago while the Edge Preview was still being developed. More importantly, the current Edge Preview is not really targeted at this type of dynamic, runtime animation.

As the examples on the Adobe Edge site highlight, the current preview release of Adobe Edge is focused on creating static, author time animations. While you can tap into its output via JavaScript, that is not the primary focus of this release. Of course, this is just a preview release, and the plan is to provide the hooks in subsequent releases to enable the type of dynamic, event-driven animations seen on theexpressiveweb.com.

However, one thing that we learned from developing Flash, and working closely with the Flash community, is that there is a balance between what is animated at author time in the tool, and what is animated programmatically at runtime. For example, for theexpressiveweb.com, Adobe Edge would have been very useful for quickly creating the animations and transitions for all of the page content and navigation elements. However, for the block animations that build the demos, we might still use JavaScript and CSS3 transitions and animate the individual blocks at runtime. This is because of the complexity of the animation, the number of times similar animations are use (twelve on the site), the sheer number of items being animated, and the ease of reusing the code model to add new animations. Adobe Edge will enable this type of complex animation, where you animate hundreds of elements, but in some cases, you may still want to use JavaScript and CSS directly. Adobe Edge will give you that choice.

The ultimate goal of Adobe Edge is to provide the flexibility to work within both models. However, for the first preview release, the team focused on author-time animations.

The site is in beta, but we would love to hear any feedback, questions, or issues you may have. You can send feedback to us at theexpressiveweb_feedback@adobe.com.

If you want to learn more about how we developed the site or about HTML5 and CSS3 in general, check out the HTML5 Camp event in New York City on Friday, August 5. There are a number of sessions on HTML5 / CSS3, Adobe and HTML5, as well as a session on theexpressiveweb.com from Stephen Koch who was the lead developer on the project.

We have also put together a Resource page on theexpressiveweb.com which lists a number of useful resources for getting started with HTML5 / CSS3. Of course, beta.theexpressiveweb.com is also a great resource on specific features.

Finally, you can learn more about all of the work Adobe is doing around HTML5 on the Adobe and HTML5 showcase site.