1 August 2011
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):
Each feature page contains:
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?
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.
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.
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:
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.
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.
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.
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:
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.
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.
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.
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.
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.
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 firstname.lastname@example.org.
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.