Unfettered Visualization


I was thinking today that there might be a different way to draw new web visuals.  So far I have used numerous frameworks which provide some canned and variably flexible interface on top of the browser’s innate capabilities.  These range from relatively low level API’s like D3 to higher level ones such as Google API.

They are great, however, inevitably, I seem to hit some sort of barrier expressing what I wish to do regardless of the framework.  I see how one might do it in svg, perhaps the framework chose to express a line as a path rather than a polyline, whatever.  At some point, these helpful frameworks fall short.   Maybe it’s a case of “can’t get there from here” or a case of “don’t know how to get there from here”.  Either way, the net effect is the same — you’re stuck.

So I started thinking, what if one were to draw the diagram they wished to implement in some WYSIWYG tool capable of outputting a fairly minimal form of SVG.  SVG is much more powerful than most people realize.  There are far less barriers to expressing an idea in such a drawing.  Once you draw it, it exists to some extent.  Even if you don’t carry the work forward, someone else might.  The idea is there, fragile as it might be, but it’s there.

Now that our visual, or a drawing of it at least is expressed in SVG, some sort of helpful annotations might aid a SVG to SVG.js type conversion.  Maybe no SVG.js conversions are needed.  Regardless, at this point you have a visual which looks roughly like what you want.  However, it’s a static javascript program incapable of parameterization save for direct DOM manipulation.

You’re far from done, but you really have a tremendous head start at creating a visual expressed either directly through svg or progmatically through SVG.js.   And more importantly, since it’s initial creation was essentially created with no bounds, it is more likely to be original and creative.  When we start with another existing component, we tend to take path of least resistance and in the conversion.  The new component behaves much like the old.  Sometimes this is desirable, but sometimes it is a tradeoff which compromises the pristineness of the original idea.  So the idea is to start unfettered, pen and paper, then SVG editor.

From here, perhaps the annotations could add this automated parameterization which would allow direct control of the view through CSS and also expose non CSS aspects of the svg.

Eventing gaps might be shored up through the adoption of lightweight frameworks such as React.js.  I’m not sure it’s needed, SVG has events already, but we will need a painless way to communicate back and forth between SVG and Javascript.

Imagine a decent UI written in a very thin layer on top of SVG.  I bet it would outperform it’s competitors with a minimal footprint.  This might be important on a large scale SPA application with a large number of pages and controls.

Now to take this notion further, it seems that WebGL is another good candidate for this same approach.  WebGL boggles my mind.  However, with a decent editor I might be able to scratch out a decent prototype and convert it over to a programmable visual.  But let’s walk before we run.

I am planning to try this approach.  If it turns out to be an interesting enough experience, I’ll let you know and probably extend the concept into WebGL.

Thats all for now, take care!


About patmartin

I am a coder and Data Visualization/Machine Learning enthusiast.
This entry was posted in General. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s