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...
We have been automating Adobe InDesign for 12 years, InDesign Server for 7 (since it came out), and it seems that just now we are finally being proven right in our bet long ago that going with the slowest, yet far and away most robust, composition engine would in the long run be the best path. After all, hardware just gets faster and faster. Desktop tools and capabilities do tend to end up on servers.
I only saw Steve Jobs twice, but he had a huge influence on my life at about 5 points that come to mind. I am very proud that such a person would come from Northern California, and Steve Jobs certainly represents the best you find in humanity. Really, the culture of Steve Jobs and the technologists somewhat like him (Charles Goldfarb, John Warnock, James Gosling, Larry Ellison, etc.) are to me one of the few positive spots when you look at global culture in this day and age: I'm sure there are plenty of common souls around the world, yet not nearly enough. Such people would stay up late envisioning new ways that humans would communicate, persist information, and render media, and their visions are keen enough that they become reality.
I just set up a basic Web site (WordPress blog) for a friend, Paris Tompkins. This took only a few minutes' spare time, including the hosting, DNS, customization. She chose the theme herself; I just made the side look OK and added the vital "Add to Any" plugin.
I still barely know WordPress, but I have had almost no trouble with any aspect of it recently: I played around with various blogging software about 8 years ago, and it was nowhere near this easy. I have only had to do something with PHP within a WordPress site once, and probably because of the nature of the template.
I have been working with XML since it was a glimmer in the eye of Jon Bosak. In fact, before XML was conceived, there was SGML; this evolution of SGML represented a streamlining for the web, but at its core there was not much functional difference; in fact the new invention was defined as a mere SGML subset. The key concept of semantic markup is central to the core value of SGML as well as its "streamlined for mass consumption" child.
The two main perspectives I have seen are Document-centric and Data-centric. SGML initially appeared in support of document-centric work: managing all the technical documents or contracts of IBM or Boeing, for example. Charles Goldfarb has maintained that "SGML literally makes the infrastructure of modern society possible" and I think he's right - hmm, should we blame him for the lengths to which humans have gone to destroy the earth?