Rumblings Underfoot

Well, WWDC 2004 has come and gone, and with it, another chance for the faithful to fill up on the Steve Jobs Kool-Aid. And while our respective tummies are sloshingly full of Aluminum Displays and Tiger goodness, the real news that came out of the conference may just be what wasn't explicitly shown rather than what made it into the Stevenote. And since reading the Apple tea leaves is always good wholesome fun, I definitely feel some of the ol' rampant speculation coming on.

To be completely honest, I wasn't all that impressed with Tiger. Features like Spotlight seem to be a solution in search of a problem (Steve's blanket proclamation of it being "impossible" to find anything on one's hard drive leaned towards outright demagoguery), but in all likelihood Tiger will be pretty darned good in the end despite my misgivings. I'll readily admit that I'm shortsighted, cynical, and not easily impressed, as is my usual frame of mind when I have to wait a long time between announcement and availability. It's just my way of dealing with the lag time, so it's likely that when I say "a solution in search of a problem," it probably will actually mean "enormous timesaver that I didn't even know I needed but badly did." After all, I seem to remember having a similar "ho, hum" attitude about seeing Exposé demonstrated for the first time during the WWDC 2003 keynote, and now I can't imagine my computing day without it. So I'm willing to give Tiger the benefit of the doubt. The bottom line, though, is that I tend not to buy into any hype too much until the product is shipping, so I'll try to soldier on somehow for the next year or so without wondering just how groundbreaking something like H.264 support in QuickTime will actually be until I have it in my own hot little hands. Anyway, the point to which I'm taking the scenic route is that while I'm looking forward to Tiger, I'm more interested in seeing the expected system speedups and performance tweaking than whatever whiz-bang new feature Steve finds sexy this week. BUT (big but forthcoming)...

Even with that as the stated case, I find myself thinking more and more about one of the things Tiger is supposed to ship with: Dashboard (which you can preview for yourself at Apple's Web site if you haven't seen it yet). I find myself dwelling not on the implementation itself, or the resulting stink that erupted over whether or not Dashboard was, in fact, a rip-off of Konfabulator (both interesting side discussions in their own right), but in the underlying technology that is at the heart of Dashboard and where it might be going. The fodder for this line of thought comes not from what was shown of these technologies during WWDC, but in little snippets posted by David Hyatt on his Surfin' Safari blog. For those of you who aren't familiar with David Hyatt, he was one of the original developers of the Gecko-based Camino (née Chimera) browser before moving on to become a Safari developer for Apple. I've been reading Surfin' Safari for many moons now, and while I don't understand a lot of what David talks about since I'm not a developer, there are usually some very interesting tidbits for designer-types like myself. And recent entries have proved more interesting than usual, which has started the little hamster in my head spinning 'round in his wheel.

Now, before I start analyzing some of the things recently posted on Surfin' Safari, let me put the cart before the horse and just spill what I think (or, at least, what I hope) is brewing: Apple is readying a multimedia-focused application development framework that is based on standard Web technologies while allowing for the inclusion of other media types such as QuickTime and Flash. And Dashboard is merely the early public face of this framework. Huh? I'm probably wrong (as usual), but let's delve a little deeper by examining the clues.

What's behind Dashboard

First, let's look at Dashboard itself in the context of how our esteemed Mr. Hyatt describes it. From a post dated June 30, 2004 (linked for complete context):

[Dashboard Widgets] are Web pages, plain and simple (with extra features thrown in for added measure). Apple's own web site says "build your own widgets using the JavaScript language", but that's sort of misleading. The widgets are HTML+CSS+JS.

And, later the same day:

From a browser geek's perspective, the Dashboard is a collection of HTML sidebar panels liberated from the browser window and placed anywhere on your screen. The "Web pages as widgets" concept is really just a logical extension of the Web sidebar panel metaphor fused with Exposé.

OK, seems plain enough. The backbone of your basic Widget is simply a combination of standard Web technologies, which taken by itself is pretty cool. And considering the growing support in Safari (well, technically, WebKit, since that's what both Safari and Dashboard lean on) for CSS3 features like opacity and shadows, things which could be termed "neat-o" are certainly possible right off the bat with just the HTML/CSS/JS triumvirate. But judging from the Widgets Apple is showing off, there's got to be something else going on under the hood to make these things work. And indeed, there is.

Mo' better HTML

Apparently, Apple is planning some additions to WebKit in the form of several HTML extensions to help make Widgets work. According the July 7th entry, there are four such extensions:

(1) Slider controls. This is not only used by Dashboard but also by Safari RSS, and so this feature cannot be restricted only to the Dashboard.
(2) Search fields. Again, this feature is used by Dashboard and Safari RSS.
(3) The new composite attribute on the img tag. This feature is used only by Dashboard.
(4) The canvas tag. This feature is used only by Dashboard.

My first inkling is to a pull a "look what getting all proprietary did for IE," but it does make for some interesting possibilities, seeing as Widgets aren't really meant to be delivered over the Internet anyway. Slider controls and search fields seems to be relatively self-explanatory, which leaves an extension to the img tag (composite) and a new canvas tag to scratch our collective heads over. The canvas tag apparently provides a HTML-based 2D drawing system, and the composite attribute introduces—what else—compositing of elements into HTML. Again, interesting possibilities. But where would things like QuickTime or Flash come into the mix?

A new plugin standard

I've got to thank David here, because if he hadn't mentioned anything on Surfin' Safari, I most certainly would have tossed the recent news that Apple has joined a new consortium of companies looking to develop a more modern browser plugin system down the memory hole. But, as mentioned in the July 2 posting:

...We're working with other browser vendors to extend the plugin API to add scriptability... This means you can obviously execute native code from within any WebKit application's Web pages through the use of scriptable plugins.

Curiouser and curiouser. If I'm reading all this correctly, which is far from certain, I'm guessing that this new plugin spec will find its way into the final version of Safari 2.0, meaning that the underlying WebKit, and therefore Dashboard, will have access to these "rich" plugins that the consortium is promising. So, in theory, any plugin that has been updated to work with the new spec could be an integral part of whatever Dashboard Widget wanting to take advantage of plugins. Add in that this new spec would, assumedly, be permitted within the confines of such a Widget to execute native OS X code, Dashboard is looking less and less like a modern version of Desk Accessories and more and more like a proof-of-concept for a very accessible, very flexible application development environment.

Whither security?

While all this sounds great, I can't help but think about the potentially dangerous issue of security, what with all these scriptable plugins and HTML extensions and what-not. I mean, one doesn't have to look very hard to find just how nasty things can get when a certain browser allows all sorts of unchecked interaction between the wilds of the Web and users' systems. And while I can't speak to how the new plugin spec is being defined with regards to security, it doesn't seem to be an issue for Dashboard Widgets, which, by design, are run locally. David Hyatt writes on July 2:

(1) The native plugin code must be owned by root. This means that in order for a Dashboard widget that contains one of these special types of plugins to execute that code, you have to enter a root account password (to chown the plugin code). This plugin code cannot execute, therefore, without the widget being "blessed" just as an application that you might install on your system must be.
(2) This plugin will not be present in Safari or other WebKit applications, and is only accessible from Dashboard.

So while I'll continue to rightfully fret about security, at least between now and when Tiger ships I'll trust that security is already (and will continue to be) taken seriously by Apple until they give me reason to think otherwise.

Beyond the Widget

So now that I've put forth some facts as reported by our dear Mr. Hyatt (and that only takes us through July 7, so who knows what's popped up since then), it's time for more rampant speculation. As I said, I'm not buying that all this stuff is coming together solely for the benefit of writing Widgets for Dashboard. Or, let me put it another way: there's so much going on here that it'd be a damn shame if it could only be put to use in Dashboard. I'd love to see all this, which I'll refer to from here on out as the Dashboard framework, step into the shoes that AppleScript Studio currently fills, in that it would provide a pretty rapid application development environment that's even more developer-friendly than AppleScript. But it doesn't have to stop there. As a designer with just enough knowledge of scripting languages such as Lingo, JavaScript and ActionScript to be dangerous, I would love to be able to use the Dashboard framework to serve as a container for multimedia content, effectively providing the development environment to aggregate whatever technology fits the bill. A dash of Shockwave here, a snippet of QuickTime there, and it's all tied together by underlying Web standards. And Apple doesn't have to even produce a specialized piece of software to create this stuff in—a decent text editor and Photoshop should be all that's required. However, with Apple's recent track record for quality software, an Apple-branded multimedia development program (Apple Media Tool 2005, anyone?) that has the Dashboard framework under the hood would definitely be something I'd want to pick up.

However, for all the cool uses of the Dashboard framework, especially from a multimedia point of view, it doesn't do a lot of us a whole lot of good unless there's a way to deploy content over to the Dark Side (a.k.a. Windows). Writing a Mac OS X-only app with Dashboard technology is fine and good and all if you're doing "real" application development, but what about those of us who might be looking to use the Dashboard framework to write and deploy rich media stuff, akin to what's been done in Director and Flash (for example) to this point? I mean, for designers, the Dashboard framework could be a huge boon for multimedia development, because it builds upon stuff that designers either already know or is easy enough for designer-types to pick up. Cross-platform deployment is crucial for this user segment, and without at least a Windows runtime (if not a development environment), there's a big missed opportunity. So, there would necessarily have to be some version of WebKit for Windows for this to work, and I'm not sure if that's in the cards. David Hyatt himself put the rumor to rest that the iTunes Music store doesn't use WebKit at all, so there goes the false hope that WebKit has already been deployed to all those Windows iTunes users. Anyway, this is just a fly in the ointment that is my grand (or not-so-grand, as the case may be) vision of what the Dashboard framework could be, so unless Safari for Windows suddenly shows up out of the Cupertino ether, it's a wait-and-see proposition. And, as far as Apple is concerned, that's the only way for us mere end users to operate.

At any rate, I'll continue to keep my eye on Surfin' Safari, not only because I've come to enjoy David's insight and candor, but because it's also a rare look into at least a little of what's going on inside Apple. Regardless, it's still a while before Tiger ships, and there are so many places I could be wrong about where Dashboard might be headed that I'd be shocked if I were actually on to something here. But it never hurts to dream, and whether or not I end up being right about this particular one, it's a safe bet that whatever ends up coming out the other side should be food for thought for a lot of us.

Filed under: Opinion on July 9th, 2004

^ Top of Page

Got Feedback? to send an email. I'll do my best to answer. Really.