With Jim Heid
In the absence of finalized rich media standards for the web, plug-ins were developed that enabled websites to offer streaming video, animated vector graphics, annoying music tracks, and the like. Over the past couple of years, W3C recommendations have emerged to suggest standardized ways of doing what proprietary plug-ins already do so well.
One of these is SMIL™, the W3C recommendation for multimedia; the other is SVG, intended to deliver vector graphics such as those already used in Flash (but with some essential differences from Flash).
When faced with SMIL, many web designers shrug; when shown what SVG can do today, most Flash designers laugh. What’s really up with these two standards, and why do they matter?
SMIL (through your fear and sorrow)
SMIL stands for “Synchronized Multimedia Integration Language,” and is pronounced “Smile.” Isn’t that cute? Oh, shut up.
SMIL is an easy-to-learn, HTML-like language for creating “TV-like multimedia presentations such as training courses on the web,” according to the W3C. The current SMIL recommendation is 1.0, and you can read all about it at the W3C address cited immediately above, and at another one we’ll mention later. This is our way of avoiding adding fifty pages to this article.
Aside from the fact that Internet heavies like Real, Apple, Adobe, and Macromedia are throwing their weight behind SMIL, why should you care about any of this? Let’s see.
Harnessing media, helping users
SMIL packs accessibility features including alternative text content that can be made available to Braille readers. Such content will also enable search engines to index multimedia web content authored in SMIL.
In English: Slap a Quicktime video on your site, and search engines like Google or Altavista couldn’t care less. But add a carefully authored SMIL presentation to your site, and speeches made by the characters in your video could show up in Google and Altavista’s search results.
The educational implications are enormous. A student researching Hamlet’s soliloquy could find a SMIL-authored video of Sir Laurence Olivier performing it. The web’s potential as the world’s library could suddenly become much richer.
The commercial implications ain’t bad, either. A buyer searching for widgets could find your client’s digitized promotional video on the subject. Existing multimedia formats obviously do not offer these advantages.
Lest you think SMIL is a completely wacky new technology, it is, in fact, simply a markup language that works with existing technologies like Quicktime and Real digital video and audio. What SMIL does is bring the traditional benefits of the Web (searching, finding, bookmarking) to non-text content. That is profound.
More reasons to SMIL
Other cool things you can do with SMIL include:
- With a single link, you can deliver audio to dial-up users and video to broadband users. None of that “click here for audio, click here for video” junk.
- Deliver different language versions of clips depending on a user’s system-language setting.
- Use backend technologies to deliver multimedia content on the fly. No need for expensive, proprietary programs with steep learning curves. (SVG delivers similar benefits.)
... all with a few simple tags.
Among the currently available Web tools and plug-ins that support SMIL are Apple Quicktime 4.1 and the unfortunately-named RealSlideshow authoring tool by the makers of the Realplayer. Adobe is presently developing a SMIL extension for its GoLive™ WYSIWYG tool, which should simplify the creation of SMIL content, and may help accelerate the standard’s adoption.
RealSystem’s support for SMIL has been solid since 1998. Given the number of RealPlayers out there, SMIL can already reach almost as many web users as Flash does. Not that SMIL and Flash are enemies. SMIL is often used to integrate Flash content into the QuickTime and Real players, and Flash 5 exports SMIL for use in RealSystem.
SMILsoftware’s Flution 1.5 for Windows can streamline the SMIL-creation process. Tom Wlodkowksy’s free Media Access Generator (MAGpie) for Windows adds accessibility features like closed-captioning to SMIL.
For a more detailed description of the goals of the SMIL language, see the W3C Activity Statement on Synchronized Multimedia. For practical advice on putting SMIL to work, see Jim Heid’s old-but-good tutorial at Macworld, SMIL: Markup for Multimedia.
SVG for you and me
SVG (Scalable Vector Graphics) is a W3C standard in progress. As of this writing, the W3C describes its initial SVG activities as qu currently nearing completion.” Though SVG produces vector graphics, it is a markup language. In fact, it is a subset of XML, the super-markup-language that will soon make the Web much more powerful, and is already used in many backend applications.
Like Flash vector graphics, SVG vector graphics can fill an entire screen with artwork while using very little bandwidth. Also like Flash, SVG can be animated via scripting. You’ll find examples of this at Adobe’s SVG site, which we’ll discuss in a moment.
No matter its graphic appearance, SVG remains text. To understand the implications of that fact, let’s contrast SVG with our present production techniques. We’ll use an example that’s close to every designer’s heart: the client’s logo.
Romancing the logo
For the purposes of this little exercise, we’ll assume that the client’s logo involves letterforms rather than non-verbal swooshes or swirls. We’ll further assume that you’re developing the logo in Adobe Illustrator, and that you have not yet converted your text to outlines. Once it becomes outlines, it ceases to be text, thus losing the SVG benefit we’re about to explore.
First, the traditional methods:
If you export your client’s logo from Illustrator to Photoshop, and embed it on a web page as a GIF image, search engines will not index it because it is not text. You can work around that limitation by adding ALT text to your image tag, but not all search engines index all ALT text.
If you create that same logo in Flash, it can spin and whirl and glow, but it will not be indexed by search engines because it is not text. Flash 5 has added some accessibility features, allowing you, for instance, to include ALT text for a Flash file, but this is global text, not image-specific text, and we already know about the limitations of ALT attributes as a guarantor of search engine placement.
Now, the SVG method:
Take that same Illustrator logo and export it as SVG, using Illustrator’s built-in support for that web standard. The resulting logo looks great, smells fresh, and it remains text. That means search engines can index it.
Your client’s logo no longer blushes like a maiden when the search engine comes courting. From every page of the site, the text-based logo calls out to the search engine, and the search engine rewards it with the Web’s greatest mark of love: a high ranking.
To the eye, the logo is a logo; to the search engine, it is a word. If the word “Widgets” appears at the top of every page of the site, that site will rank high when users search for widgets. When the client cries, “Make the logo bigger,” you can answer: “We’ve made it number one.” By contrast, under the old methods, when a GIF image of the word “Widgets” appears at the top of every page of the site, it is unlikely to seduce the search engines.
Because the SVG-formatted Widgets logo is a word that looks like a logo, users can also copy and paste it into a text document. It will lose its SVG formatting when users do this, but your client’s name will remain intact. Your client will like that.
And who knows? A year from now, it may not lose its formatting when pasted into a popular word processor, print layout program, or email message.
In fact that is one of the promises of SVG for graphic designers: that we will be able to use the same SVG image file in our print work and our web work. From Illustrator to Quark to the website, as easy as drag and drop. (Yes, you can also create SVG illustrations by hand-coding them—after all, SVG is really XML—but we doubt many designers will want to do that. We sure won’t.)
Will SVG replace Flash? Not likely. Certainly not any time soon. Will SVG evolve into a useful tool for creating scriptable vector graphics? We think it will.
Sounds dandy, but will it work?
SVG support is coming online slowly. An Adobe plug-in supports SVG in all web browsers, though not equally well. The first version of the Adobe plug-in relied on Netscape-proprietary plug-in detection that was not supported in Internet Explorer for Macintosh. Users of IE5/Mac could not see SVG graphics at all with that plug-in version.
As of this writing, a newer Adobe SVG plug-in has greatly improved its support for non-Netscape browsers, though Internet Explorer support for Macs is limited to non-scripted SVG only. In other words, IE/Mac users can see SVG graphics on the Web, but cannot see dynamic (animated) SVG graphics.
Still, things are looking up for SVG. You may find it odd that it takes a proprietary plug-in to support an open standard, but such is the state of the Web. Once the SVG standard is finalized, we suspect that browser makers will begin investigating ways to support it natively.
While SMIL is well-supported via plug-ins, SVG is still a work in progress. A promising work in progress. An exciting work in progress. But a work in progress. It will be widely adopted when it is further along in development and can be natively supported in browsers.
Do these tools, SMIL and SVG, pose an immediate threat to Macromedia Flash? Certainly not. In fact, we don’t see them as anti-Flash technologies at all (though some may view them that way).
While SMIL is expanding and SVG is still taking shape, now would be a good time to download Adobe’s SVG plug-in, and explore SMIL presentations and tutorials. Over the coming months, you will want to remain open-minded about these emerging standards, and keep your eye on their evolution. Before we know it, they will likely be part of every web designer’s tool kit.