Several readers have written to me over the past while, asking for an update to an article that I wrote for the July, 2003 issue of MSDN Magazine. In that article, I expressed a lot of optimism for the future of Scalable Vector Graphics (SVG). However, based upon how the market has evolved since then, and the amazing clarity of hindsight, I have come to believe that SVG is effectively dead as a mainstream, desktop technology. To many this will be a painfully obvious fact, but I thought it had to be addressed (and it allows me to respond to queries with a courteous link).
SVG, as a quick primer, is a vector graphics technology that allows for gorgeous layered designs using basic primitives. SVG also offers a wonderful DOM programming facility to allow for animations and programmatic alterations - I won't go into SVG in technical detail (not only are there plenty of resources out there that do, but I also don't pretend to be an expert in SVG), but I will say that in a nutshell SVG is a standardized, owned-by-no-one alternative to Flash: With a simple XML layout and clear, logical specifications, SVG was compelling in its approachability and low barrier to entry - No special authoring kits, or understanding of convoluted binary formats, was required to begin creating dynamic, vector-graphic solutions.
Nonetheless, based upon some observations and occurrences since, I will confidently state that SVG is dead on the desktop:
These, along with other factors, have led me to believe that SVG on the desktop is a non-starter, barring some jarring schism in the marketplace. I think it's too little, too late for Firefox to offer a wide deployment of SVG, and I doubt Adobe is going to do much more than let SVG fade away (of course they'll claim otherwise, but let's be honest).
I do, however, continue to believe that SVG on the server, as a component of the image processing pipeline, is still entirely viable.
[UPDATE: A followup can be found here]
I try to keep on top of the various important releases from Microsoft, testing assumptions and seeing what's new with each release. Tonight I decided to install the September 2005 CTP of Microsoft SQL Server 2005.
While it seems like a pretty trivial exercise to update to a new release - and from a difficulty perspective it is - it is remarkable how much time each of these iterations takes. While I don't need to sit here looking at the screen for the duration of the install, there nonetheless is a lot of user interaction that is necessary (even if it's just saying okay to random dialogs), and it soaks up PC resources for quite some time. First one performs all of the various deinstalls of the prior iteration, and the lengthy installs of the new one. Add in various incompatibilities just for fun. "Whoops, I have the Visual Studio July CTP .NET Framework, which is conflicting with the September CTP of SQL Server 2005". Almost sounds like ".dll hell". Of course to really keep on top, add in all of the CTPs of Visual Studio, and the other tools. You can basically fill your days uninstalling and installing various tools.
There is no real "point" here, and I can't see any possible solution (except for perhaps completely touchless installs that require zero interaction from setup.exe to finish), but it could be the reason why so few people seem to have any hands on experience with either SQL Server 2005, or Visual Studio 2005.
Made a bit of a fool of myself today, mistakingly implying that I was building webpages using brushed-aluminum backgrounds back in 1990 (my actual statement was that I was doing so "about 15 years ago", but I didn't actually think through what that would mean). In reality the date was closer to 1994, where I was building a little PC configuration tool for a retail computer shop (which was a component of a complex corporate structure that included a music store, home theatre equipment, and computer consulting and sales), allowing users to dynamically configure a PC and get a price (the server-side scripting was some innovative completely proprietary script), and then print out their config and bring it in to place an order.
The impetus for the discussion was the implication by an individual that if Microsoft used brush-metal backgrounds, clearly they're ripping off Apple (as Apple fanatics believe that Apple invented everything. I view Apple very favourable, but more times than not they're simply executing ideas better and more beautifully than people before them).
My reply was that brushed-metal backgrounds were some of the first uses of the BACKGROUND attribute: I fondly recall upgrading my PC configuration web "app" to use a classic brushed aluminum look. This was long before Apple started using brushed metals on their desktops. I was hardly an innovator, and such backgrounds were pretty common because they looked like something people could relate to in the real world, yet they could be low contrast and compatible with overlaid text. They are an obvious and inevitable background.
Outside of my chronology problem, what struck me as most disturbing was the impression some have about the state of computers in 1990 - that the ability for brushed-metal graphics to even exist was simply an impossibility. How absurd. In 1990 the Atari ST and Amiga, both very graphically rich PCs, had existed for a half-decade, and were certainly capable of creating and displaying a trivial brushed aluminum graphic. Apple was already up to the immensely powerful Apple IIfx (I lusted over ads for that "Wickedly Fast" PC). Windows was already out for 5 years, and Microsoft was already a billion dollar company. The WWW didn't exist, but a lot of us had been using bulletin board systems, and interconnected message systems (Fidonet, Usenet, and various others) for quite some time. While you couldn't run a Photoshop effect and generate a brushed metal, people would load up long-existing raster graphics programs and plug in the pixels to generate the desired effect.
The point, if there is one, is that Google didn't invent the internet, and Apple didn't invent graphics. This whole "computer thing" has been going on for a while.