Archive for April, 2010
The following thoughts are my response to John Mason’s recent post “Is Mike Chambers a hypocrite?” Well, It’s not really a direct response to John’s arguments. I enjoyed reading what he wrote, as it is nice to see unbiassed and fresh opinions out there. There are too many fan boys with an axe to grind. John’s post got me thinking about some issues. So it was my catalyst for the following stream of loosely related consciousness:-
For years, Flash was the only serious choice for rich media experience on the internet. The success of Flash can be attributed to innovation.
I’ve never seen open-development innovate and popularise anything really new and different. This is why I prefer closed, proprietary, patented, and commercially driven technologies. I’m no tree-hugging free and open idealist. I’ve never seen the open approach plant the seed of innovation. The open approach is only successful when the paradigm had already been defined by (closed architecture) commercially driven innovation pushing the envelope and creating the future.
But if Adobe had innovated faster – there would be more to distinguish Flash from the alternatives now. I’ve also felt held-back waiting years for features in AIR or the flash player. Perhaps they were resting on their laurels. The survival of Flash could depend on more aggressive innovation from Adobe in the years to come. I think a revision of their culture, vision, and technical leadership could be on the cards.
For Adobe, the shortest distance between two points isn’t a straight line. It’s not a path ascending the pinnacle of engineering elegance and excellence.
This is something about Adobe’s commercial approach that I DON’T like.
More often than not, their path is dictated by the maximum incentive to pay to upgrade to the next version. So we took some detours and got stuck in some cul-de-sacs. ActionScript-2. The Bloated Flex Halo Framework. The Advanced Data Grid.
The poor performance of the Flash player on the Mac platform hasn’t won Adobe many Mac allies in the current conflict. (I’m not talking specifically about Video performance – let’s not hear the excuses). To be truly ubiquitous – the performance has to be comparable across all platforms – otherwise you need to engineer your application to the slowest platform, wasting any speed advantages on the faster platform.
What I consider hypocritical about Adobe’s claims to openness is that Flash platform development is not a level playing field.
It appears to be dominated by a clique of best buddies in San Francisco. I’ve been involved in Flash platform programming for a decade. A pioneer of RIAs. Yet always outside the inner sanctum.
My biggest gripe about Adobe’s openness is that Adobe builds applications that compete with the developers who buy their products. It’s a peculiar relationship that Adobe has with its customers. On the one hand, we buy their tools, on the other hand, we compete with their developers and their applications.
While it’s unlikely that Adobe will reject your AIR application from the marketplace – but you may find yourself in a situation where you put a lot of time into a project, only to get into a situation where Adobe will throw a lot of money, development effort, and publicity into a competing product.
Maybe I’m biassed, but I always thought that e2publish, with its clever text wrapping and potential for publishing to be a much more interesting project than BuzzWord. Certainly more ambitious. Just think about what I could have achieved with BuzzWord’s development budget. Nevertheless, I didn’t like the odds of going up against Goliath – so I abandoned e2publish for a couple of years. It’s still an unfunded prototype with a lot of potential.
e2publish is an AIR application that utilises the Text Layout Framework (TLF) and Squiggly spell checking. It has two powerful text wrapping modes, and plenty of features to customise the look of document pages.
The following video tutorials provide an overview of the most important features.
Introduction: Pictures and text…
Advanced text wrapping…
Layouts: Customising page appearance…
Tables and top text shutter…
Sharing documents online…
1. e2publish can import e2spreadsheet graphs, or e2vector illustrations. You can import from your computer’s filesystem, or shared documents online.
2. Because it can import from e2vector, you can import illustrations that originated in Flash. Export them as .fxg files, import then into e2vector, then import the .e2v file into e2publish.
3. Make sure you have the latest versions of e2spreadsheet, e2vector and e2publish.
. . . . . . . . . .
These applications are beta versions. Please let me know about any bugs or feature requests. (You can leave your comments here).
A few weeks ago, Ricardo Cabello (Mr Doob) published an inspirational “procedural drawing tool” called Harmony. I was impressed by the code simplicity of Ricardo’s brush effects, their natural look, and the responsiveness and speed of an application made with HTML5 and Canvas. As a Flash/Flex developer on a Mac, I’m not accustomed to speed and responsiveness.
Anyway, Ricardo’s experiment not only caused me to consider HTML5 and Canvas more seriously, but also to try to implement some harmony-like brushes in e2vector.
I had to employ several simplifications. e2vector imposes smoothing. So drawn shapes are reduced to well-chosen few points to represent them.
I noticed that Ricardo’s brushes respond to how quickly the user makes a brush stroke. In harmony, a slower motion with the brush produces more points, and a darker impression. Unfortunately, these intermediate points would be removed by e2vector’s smoothing – so I couldn’t achieve the same effect.
Also, I tried to do smoothing on-the-fly rather than at the end, but the added computational burden compromised the responsiveness of drawing. So I had to revert to the old scheme and my brushes appear to change appearance slightly once when the brush stroke is complete. Not ideal, but computationally simpler and hence more responsive.
But e2vector brushes incorporate some novel features. Like the ability to edit the path spline of a brush, and the ability to convert any e2vector shape to a brush effect.
(Note: in this latest version, the new brushes feature isn’t entirely recognised by all parts of e2vector – for example, if you export to .svg or .fxg – you’ll just see the path. Not the brush effect. I’ll get round to fixing this when/if I have time in a later version.)
One more thing…
I’ve put some effects like twirl, pinch, and spherize in this latest build of e2vector.
e2vector (AIR application) can be downloaded here.
To be continued…
Comparing my implementation with Mr Doob’s original implementation – while I’m happy with the kinds of novel heuristics and computational complexity reduction techniques I’ve employed – I’ve compromised the “look” of brushes too much. I think I lost sight of aesthetic quality, while I got wrapped up in algorithms.
I’ve since improved the look of my brushes – and I’ll report on that soon.
All will be explained more carefully in the second instalment.