Thoughts on Adobe Edge

Last week, I dragged my snot-filled carcass down to London for a day-long presentation by Adobe called Create The Web.

I’m an occasional user of Adobe products: I used Dreamweaver in my last job (and was a beta tester for a previous version), and use Photoshop from time-to-time, although use about 2% of its capabilities. I also have some chums at Adobe, but they’re weedier than me so didn’t try to threaten me to be nice to them.

In passing, it’s interesting to note that while Twitter has lots of griping about Adobe products, they managed to get about 800 people into a Leicester Square cinema for a full-day product pitch. That suggests Adobe retains significant mindshare.

I was there because I wanted to see their new Edge range, as the tools that authors use to make websites directly affect the quality of the code of those sites, which directly affects the interoperability of the Web. I was therefore watching the day from two occasionally opposing perspectives: firstly, as the representative of a browser vendor that is sometimes disadvantaged by developers not using the correct prefixes etc, but also as a web author who, all other things being equal, prefers to use IDEs than type in code.

The decline of Flash has not diminished the appetite of site owners and developers for eye-candy and movie-like effects. That’s why Adobe is pushing for lots of new effects in CSS: cool stuff like CSS Filters and CSS Compositing and Blending and also anachronistic “we wish the Web were print” specs like CSS Regions.

Regardless of your opinions on Flash as a technology or plug-in, there’s no denying that the Flash Pro development IDE beats coding canvas in raw JavaScript. It’s also true (according to my good chum and co-author, Remington Sharp) that those developers just coming to canvas and motion graphics now are bumping up against problems that the Flash developers solved decade ago.

Therefore, Adobe has made a very smart move by making the new tools for animating stuff feel familiar to Flash developers. This was explicitly called out: Flash devs, your skills are not dead; the technology might be, but your experience and creativity are still in demand. This is true, and a shrewd business strategy.

(A word about product nomenclature and confusion: the DHTML tool that was called Adobe Edge is now called “Edge Animate”. “Edge” now refers to the whole suite of new Adobe tools. Animate seems to produce DHTML, flying <div>s around with CSS and JavaScript. Apparently, the Flash IDE can produce “HTML5″ output, but that’s <canvas>. If your stuff involves text, use Animate so the text remains text and is therefore accessible.)

I haven’t had a chance to download my copy of Edge Animate yet. Lee Brimelow gave an excellent and entertaining developer-focussed presentation building up an animation and there were a few nasties in the code produced.

For example, it seemed that, by default, the code is simply empty <div>s with everything else injected by JavaScript. This means that someone without JS sees nothing at all. The “static HTML” export (which ought to be the default, in my opinion) at least puts the images in the markup, so a browser without JS sees *something*, albeit it unanimated. That code, however, was invalid: it produced <img>…</img>, and there is no closing </img> tag in HTML5 (or any previus incarnation of HTML, for that matter).

Encouragingly, Ryan from Adobe contacted me after I tweeted about this, asking for further feedback which I gave.

Other products that interested me were PhoneGap Build which allows you to upload a PhoneGap project and receive all the different packages through The Cloud™. I’d definitely use this. Who wants to dick around with all the different SDKs?

Edge Code is built on top of an open-source project started by Adobe called Brackets. Some hard-core developers (eg, those who wouldn’t pee on Dreamweaver if it were on fire) I spoke to seemed impressed. It seems they’re very serious about getting external developers involved; pull requests are reviewed daily; Agile sprints mean a quick iteration time, so your contributed code doesn’t languish interminably, and priority is given to external contributions.

The last product that interested me is Reflow, which isn’t out yet. It’s a drag-and-drop visual editor, which allows you to shrink the “stage” and, when your design starts to fall apart, set a breakpoint (which writes a Media Query) after which you re-design the page for the new page width. I haven’t seen the code that’s produced, but it feels to me an intuitive way for a designer to work.

Overall, it was exciting to see a company working hard to come up with a new strategy. The jury is out on the code it produces; Adobe is very heavily investing in WebKit and one of the presenters’ saying “this also works in old browsers like IE9 and Firefox” makes me uneasy. But it doesn’t have to be bad: Microsoft’s Web Essentials Visual Studio extension does an excellent job of adding all the vendor prefixes, even though Microsoft are heavily investing in IE.

The success of the product will ultimately depend on the price. And I’m curious to see how they’ll integrate with Dreamweaver, which is pricey and currently lacks many of the Edge features.

(Note: this is a personal post and doesn’t reflect the opinion of my employer).

Give Paul Robert Lloyd’s Thoughts on Adobe Edge a read, which prompted me to write this up. Fellow HTML5 Doctor Ian Devlin says PhoneGap Build is Awesome.

6 Responses to “ Thoughts on Adobe Edge ”

Comment by David Powers

I’m not sure I would agree with your characterization of CSS Regions as an anachronistic “we wish the web were print” spec. Adobe does a lot of work with digital publishing, and CSS Regions and Exclusions are likely to play a big role in creating ebooks and magazines. They’re also useful for web apps designed to display on devices with known screen dimensions.

As for the code output by Edge Reflow, you actually saw it in Jacob Surber’s presentation. It outputs only CSS (including media queries). It’s not intended to be an HTML editor.

The day after the Create the Web event, the Brackets team organized the first day-long Brackets hackathon, at which about a dozen non-Adobe people, including myself, worked on contributing code to Brackets. I helped build the foundation for CSS code hints. Although Brackets Live Preview currently works only with Google Chrome, Adam Lehman, the project manager, is very keen to work with other browser vendors to make sure it works with all mainstream browsers. The current focus on Chrome is because its debugging API made it easy to implement the features they wanted. I know that Adam has been in touch with Mozilla. Not sure about Opera, but I think the door is open.

[Disclosure: I have a close relationship with Adobe as an author of books and videos about Dreamweaver. I also try to keep Adobe on the righteous path of web standards, although I don’t always succeed.]

Comment by Charlie

I really don’t get the Adobe bashing. It’s not as if the invented Flash or originally wrote Dreamweaver for that matter. They did do the right thing and stick a good codec in Flash after they bought it and pretty much put an end to the plugin wars, gave Youtube the leg up it needed and, by making it really easy to have good quality video in a website, added real impetus to the drive for a tag.

Their tools from Photoshop (though I recommend a very cheap but good clone Photoline for occasional dabblers) through to Acrobat are for a professional market which is why they’ve always been able to charge so much for them. Macromedia might have been faster at adding features but never with the same quality.

And Adobe switched to JS/HTML over Flash pretty quickly in their other products. Their analytics software, Omniture is very well done with considerably better cross-browser support than say Webtrends, which for example completely fails to work with Opera.

The animation you described where content is injected into an empty page is increasingly becoming the norm as the asynchronous approach lowers latency and gives more control for anything beyond the most basic user interface. Twitter is, apparently, the poster child of this action-based interfaces. Not sure how I think of this. I am beginning to the think that a JSON-based format might be increasingly well-suited to things we are doing with HTML: let’s face the DOM was never the greatest invention.

Comment by Bruce

@charlie, thanks for your comment.

I’m intrigued by “content is injected into an empty page is increasingly becoming the norm as the asynchronous approach lowers latency and gives more control”.

It seems to me that downloading a skeletal HTML page, then downloading a script and only then downloading images etc (once the script has been parsed) would be slower than downloading the images in the original HTML. In the simple example I saw, the images are animated using generated CSS so there’s actually no requirement for JS at all. I acknowledge that it was a simple example, however.

I’m interested to know how this approach gives “more control” (over what). Whether or not you make a DOM with HTML or use script to inject all the content, you’re still left with a DOM to manipulate with JS and style with CSS.

Comment by Steve Fenton

“The animation you described where content is injected into an empty page is increasingly becoming the norm as the asynchronous approach lowers latency and gives more control for anything beyond the most basic user interface.”

The problem with this is that it doesn’t work unless JavaScript is enabled. I know we are only talking small numbers in terms of percentages (2% to 4% of people are without JavaScript in most territories) but when you consider that there are millions of people online, small percentages represent big numbers.

I recently worked on a project that was highly JavaScript dependent – a live telephony UI that constantly synchronised with the server – but it worked without JavaScript too.

The initial page load should contain content. If you want to perform micro-refreshes of small parts of the content using JavaScript to improve performance that’s fine – but why exclude people from content altogether?

Comment by Charlie

@Bruce – “more control” is how programmer’s see the delivery of content where a(n) incremental stream is almost always preferable. As a thought experiment think how Opera Turbo works: it sends a binary stream to the browser, or JPEGS with progressive enhancement. Well, that is sort of what I mean.

All the *ML languages suffer from being written to be human readable. As a result of this requirement computers have to do quite a lot of work, though I’ve no doubt they are optimised beyond doubt now. Contrast the work involved parsing and rendering HTML + resources to something that just paints the screen. This is one of the performance improvements that Google got when switching maps from SVG to Canvas. Being able to push byte code would be even faster.

There is obviously tension between this and pure content – that for which HTML was initially developed. But it’s clear that it’s getting the investment.

@ Steve – I agree with you, especially for content, but as more and more people think of browsers as runtimes for their applications then Javascript is not considered optional.