Jan
19
On doing something cool
January 19, 2012 | Leave a Comment
Web Technology moves at a very fast speed. (obviously)
But the hardest part of being a web developer is the question of “when can I use this awesome new technology?” If you haven’t seen the site CanIUse.com, its a great resource for approximating what portion of the web is using a browser that supports said technology.
For example, @Font-face which allows web site designers to embed real fonts into web, rather than sticking to the same thirty or so fonts and creating fonts-stacks [nevermind this site’s “Mystery Meat” navigation, a blast from the dark past for sure]. Mainstream web use of this technology really took off in the last 12 months, once the percent of users supporting this technology crossed the 75-80% threshold.But even this was rather earlier because the font technology gracefully degrades. If you aren’t on a modern browser, you’ll see Arial. This is called “Graceful Degradation” and has been a buzz word since at least 2005, but its use among professionals goes back even further. Now this post isn’t going to be a long essay about the importance of designing with this in mind. Graceful Degradation is old hat, its part of the standard canon and really is at the foundation of modern web design. But I’m going to take this as a given, and talk a bit more about a decision I made on a website I personally run (my labor of love): The GIN is IN.
On the what and the why for that specific what.
I’ve been intrigued by the power of the web as a textual medium for a long time. Especially as a professional very interested in issues of accessibility (Section 508) and universal access, I’m really interested in the ways that a web page can implement a whole array stunning design techniques, tricks, and visualizations in a way that degrades gracefully and does so in a way that fulfills not just the letter of the law, but the spirit of the movement.
Little Known fact: I actually started my career as a flash designer. I picked up PHP a few years after I made my initial foray into design world. Actionscript (I think it was 2.0) was the first programming (not markup) language that I taught myself
So enter SVG. Of course Wikipedia explains all better than I ever could, so here is a brief explanation:
SVG images and their behaviors are defined in XML text files. This means that they can be searched, indexed, scripted and, if required, compressed. Since they are XML files, SVG images can be created and edited with any text editor, but it is often more convenient to create these types of images with drawing programs such as Inkscape.-Source
So naturally as a PHP programmer, I’m intrigued by the way that infographics can be created by using existing databases. Even more so, if you can build your graphic off of a user edited databases, your charts can change live as the content changes.
Secondly, SVG holds an interesting allure for me. Because although there are several great javascript visualization libraries out there, I’m personally biased and intrigued by the power that exists in plain old HTML.
On Audience
When at work, I always look for the most expansive technology. Javascript will work on pretty much every browser, and work reliably. There’s a great community and lots of examples of work with Raphael (WSJ uses it for its visualizations). But in my personal life, although I’d love the entire world to read my gin blog, I can deviate and experiment with doing things that I shouldn’t do at work. So inline SVG caught my interest and I decided that for the new visualization charts I wanted to make for reviewing gin that I would use this technology.
I didn’t choose it because it was going to appear on all browsers. In fact the most common version of Internet Explorer does not support inline SVG at all. If you look on IE8 you won’t see anything at all (yet). The newest version does support it. It won’t work on your Ipad (yet). But despite that I developed a feature (and wordpress plugin likely soon to be added to their archive) anyway. For the thrill of experimentation, for being an early adopter, and simply because I’ll have plenty of chances to use javascript libraries to create elegant all-platform websites. But fewer opportunities to do something just because.
On the Future of SVG
In my decision to use this visualization tool over the alternatives, I do commit myself to two sort of biases which I will own up to: 1) I think that SVG will be the most supported inline visualization tool in five years. Jquery is great, but it is separate from the actual browsers. SVG is built right in and does not require downloading any new libraries/frameworks as a developer. 2) I think that its important to see how things work behind the scenes. Sure Raphael works with the W3C specs. But I think its much more fun to go behind the scenes and make it work without a middle man.
I’m sure we’ll be seeing much more of these technologies in the future as more and more users choose browsers which support these tools. In the meantime, I’ll see how my Inline SVG experiment works out. Perhaps I’ll be moved to move it into a more widely supported method in the future, or perhaps I’ll take a shot at another fringe technology on the list.
