famo.us is a 2.5-year-old Silicon Valley startup that claims to have solved the performance challenges of HTML5.
"Performance challenges?" you might ask, but only if you hadn't yet heard the tales of Facebook and LinkedIn turning an about face from HTML5 in favor of native applications. As I blogged about a year ago, HTML5 has had mixed results in the wild, driving many to adopt native or hybrid native/html5 strategies. As I discussed in describing the event where I first encountered famo.us, the classic example of poor HTML5 performance is the scrollview. Quoting Trunal Bhanse of LinkedIn:
At the time Adobe InDesign was created, 15 years ago, it was generally impractical to store print-quality assets on web servers. A decade and a half later, however, the maturity of cloud-based file storage and asset management systems is making links from InDesign to assets housed in modern platforms, such as Box, a powerful solution for creative professionals.
Asset storage as of Adobe InDesign 1.0
Adobe InDesign is the tool of choice for the creation of high-quality print documents. It is nearly ubiquitous among those creating newspapers, magazines, books, catalogs, marketing collateral, or almost anything that prints. InDesign started out as a competitor to QuarkXPress, and given the dominance of Adobe in tangential technology (PostScript, PDF, PhotoShop, Illustrator) along with substantial and well-focused investment in the product, it was inevitable that InDesign would take the place of Quark at the center of high-end publishing workflows.
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.
We at Silicon Publishing have come to specialize in developing online design applications, with years of extensive work building web-to-print solutions based on InDesign (yes, pre-server) and Adobe InDesign Server. Because we didn't start with a product, but spent our first 9 years as a custom development shop, we have not tended to guide our customers on UI but have typically let them define what they wanted.
When we did create a product, Silicon Designer, we focused on the core common layer of what we had built for solutions, keeping in mind that the user interface would have to be quite different for different clients. We continue to see that different companies have wildly different concepts of what is important, even given similar document types/workflows, and there are differences between document types and business context that will in many cases require different UI approaches. We are glad we worked so hard at keeping the core functionality flexible with respect to user interface. Following are five UI considerations we see as we build online design tools.
Anybody who works with automating Adobe Illustrator long enough will find some level of flakiness in the behavior of this application. It is very old, and doesn't enjoy the same level of support for automation as does InDesign, a much more modern application. I got this email this morning, and it seems we are one step closer to taming the Illustrator beast...