I am at the HTML5 Developers’ Conference in San Francisco. One of my friends said “it must feel like Christmas for you over there” and it actually does feel that way, not in the sense of “everything is easy now” but more in the sense of “our path forward is clear.” Like Christmas before a year-long war we know we will win.
Paul Irish spoke this morning about the various tools he’s using these days, or as of 10/16/12 (one gets the impression he’ll be adding a new one tomorrow), so certainly things are more mature in terms of the “tool chain” (in the old days we were waiting for “tools” to simply get plural, as text editors reigned supreme). Now we can say there are ToolS for HTML5. Cool.
Even more interesting to me than Paul’s talk was the talk by James Pearce on “Keeping the Dream Alive” – he had the good news and bad news about HTML5, which can be summarized by two parts of a single quote from Mark Zuckerberg…
“When I’m introspective about the last few years, I think the biggest mistake that we made as a company is betting too much on HTML5 as opposed to native. Because it just wasn’t there.”
When Facebook moved from HTML5 to iOS, they had stunning gains almost overnight.
The good (the part that has received less hype):
“It’s not that HTML5 is bad. I’m actually, long-term, really excited about it. One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us…”
Yes it is like Christmas for HTML5 geeks, finally our work is getting somewhere. It will be very interesting to see what happens over the next year. It is not easy to reconcile the formats required of modern devices, yet the range of required approaches is getting more clearly known and the tools keep evolving to make things easier.
Recently we have been working on some very exciting technology with Adobe, bringing together some technologies we’ve been working on for over a decade with one of their most recent technologies, the Digital Publishing Suite. We watched this technology develop over the past few years, and honestly had our reservations about the initial releases and apparent intentions of Adobe at the outset of this offering:
While point 1 remains valid: native apps are not always the ideal way to bring content to devices, it is still true that sometimes a native app is precisely the ideal way to provide content. Native applications may perform better, manage offline content with more power, and access a greater range of device capabilities. Also “app stores” are good and bad: bad in that they make distribution more costly, yet good in that they are often a great way to get users to find and reach your content.
Point 2 is no longer valid: things have changed substantively over the past two years. There have been dramatic improvements in the underpinning technology around DPS, with Adobe investing heavily in every dimension of the DPS solution: the “liquid layout” features of InDesign CS6 were created with DPS specifically in mind, and include technology that makes the content much more efficient than it was with the prototypical wired reader, which one senses had been built in a weekend when Adobe noticed that Flash wasn’t going on the iPad. Adobe has been contributing to CSS specifications and the WebKit project, they have core tech that is unrivaled if they really wish to make text work well on tablet devices, and their power is starting to show as DPS improves over time. As Chris Converse has brilliantly taught and demonstrated, there is now the capability in DPS to add fairly arbitrary HTML5 content. DPS’ value is proven out as devices proliferate and iPad competition looms on the horizon with an even larger distant silhouette each day.
Point 3 is no longer valid, either. While initially Adobe DPS aggressively pursued the magazine market with a fervor that would make Suge Knight proud, after they attained that market they did realize that other markets (particularly the new ones I will mention later) have more partner dependencies and are best built within an ecosystem, and extensibility is essential to the growth of DPS even in the magazine space. There are now fantastic APIs available to developers, which enable publishing workflows never before possible.
We at Silicon Publishing are now building InDesign Server-based DPS solutions of two types, which parallel our main two products:
In the catalog world, so many manufacturers and retailers produce print or print-like (some only distributed as PDF, but retaining the print design paradigm) content with Adobe InDesign Server that rendering a tablet application from the same process makes much sense, and it is easy to do thanks to the automation capability of InDesign (including most interactive features) as well as the packaging and deployment APIs of the Digital Publishing Suite.
In personal publishing, for example creating photobooks online, the process of output is largely identical, yet the possibilities even more stunning. Grandma makes a photobook online, and within an hour, can have iPad and Android versions of the photobook available to her family. Silicon Designer gives us a great platform from which to build out this functionality.
We are looking forward to sharing more about this in the coming months.
I was talking to one of the leading experts in Adobe technology, who shall remain nameless, about HTML5 frameworks, about a year ago. He mentioned “Sencha” and I asked “what is that?”
“It’s… [long geek pause] … what Adobe should have done” he replied. He was referring to Sencha Touch.
We at Silicon Publishing have been using two frameworks for HTML5 development recently: Sencha (mainly Architect and EXT JS, yet we play with the disconnected Sencha Touch as well) and Montage (which was created by an amazing team at Motorola Mobility, some of whom were previously top talent at Apple, Adobe, and Opera) – we were forced to do this on an experimental basis as we awaited news of a license we can actually deploy from. I have to say: Montage is what Adobe should have done. Sencha has a couple distinct technologies that yes, Adobe should have done, but Montage has one core technology that just plain works. (perhaps that has to do with their roots at Apple?)
Not to disagree with the expert. Sencha, too, is what they should have done. Montage just takes the notion of framework and makes it elegant, modern, and clean. Flex-like, as Tom says. Oh, and Open Source.
Montage is a better Sencha, if you will, and Adobe is a distant third in this race, at the moment. One would think Adobe has near-infinite graphics/development chops, so at any point they may return to the game, but the visions of Muse and Edge are limited and canine compared to the vision of Montage.
We have been working hard at Scene7 Web to Print for quite some time now, seeing it come of age and deploying some serious solutions. While we started out with full-blown Silicon Designer on top of Scene7, and that remains our primary form of development, we are getting more and more opportunities for which a simple, html-based interface makes sense.
Don’t get me wrong, we love the robust online design interface of traditional Silicon Designer implementations: it is very cool to work in the browser in real time as you design things, without having to wait for updates from the server, and to work from the web in ways that used to be possible only in desktop applications. Along these lines, we continue to extend our HTML5 work, and are seeing some amazing results. But here are some reasons for simple form-based entry:
It is also true that we can, even with a form-based experience, render HTML5-based imaging on the client… yet there are numerous challenges in making this as robust as what a server-based renderer such as Scene7 can offer. And serious print from HTML5 is still a ways off.
Then when we look at server-based rendition… Scene7 is far ahead of its competition: high-quality print output with very fast composition speed, results returned to the browser fast enough to be very close to direct editing. And the fact that it is coming from the composition server, literally, ensures perfect fidelity between web and print.