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.
We at Silicon Publishing have come to specialize in developing online design applications, with our Silicon Designer product and our extensive work building web-to-print solutions based on InDesign (yes, pre-server) and InDesign Server all these years. 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.
One of the first considerations in an online design tool is how guided, or constrained, the design experience will be, as opposed to free-form and flexible. Do you let users add objects to the page? Do you let them start from a blank canvas and design from scratch? Can you position an image within a frame, or re-size the frame itself?
We have seen the extremes, with some very form-based, wizard-like applications for authoring content at one end of the spectrum, and more like “InDesign on the Web” at the other end of the spectrum. Some of our more sophisticated clients offer a more simple experience for one class of user, with an “advanced” mode for “power users.”
Here, it really depends on the nature of the content and the end user. For many clients, brand management is an important concern, and in such cases a constrained interface usually makes more sense. A Real Estate agent making a brochure will want to go quickly and will want to stay within the constraints of a template, getting the job done as quickly as possible.
It is a more difficult choice when, for example, you are letting users design a greeting card, a personal magazine, or a photobook. Here is where we see strong opinions one way or the other on exactly the same document type/user type. There are tradeoffs:
We have witnessed passionate arguments within organizations on this subject, and worked on applications in the extremes. Hallmark.com is an example of a fairly constrained experience: iprint.com is very free-form. One consideration is that a constrained UI is usually easier to implement, while with a free-form editing experience, one thing leads to another. So a user can add objects to a page… next you will probably want to align these objects, somehow. Alignment tools, snap-to-grid, and other features follow such an initial opening up of free-form editing.
We have seen organizations bring data to justify one position or another. One chart, for example, plotted Complexity on the horizontal axis, with a triangle indicating the Market Size for the spectrum of applications, and it came out something like this:
I saw this chart and had a revelation – no wonder we are so poor! We toil and toil to make “InDesign on the Web” sorts of application, but these are so complex and esoteric, they make users abandon sessions from confusion/exhaustion, or render documents unprintable with terrible design choices; all our work to let them add and contort images to their hearts’ contents is entirely wasted! All the money seems to come from the old school, form-based “enter book title and you’re done” sorts of application, built by old-school programmers who don’t know what kerning is, who have never studied the mathematics of zoom and rotation. So that’s what is meant by “less is more.” Sorry Ole, you are too smart to work here.
Fortunately for us, the larger players in online editing do actually appreciate the value of free-form editing, as something to shoot for after there is an established “easy way” to create documents. The art is in balancing constraint and freedom in such a way that users can work quickly and are guided towards a successful design, yet can still work in a free-form way when it is really needed. Often this means some form of “advanced” editing mode. The good news for those that don’t have a gazillion dollars for a pen tool that does perfect gradient mesh touchup is that only 1 in a billion users will ever use such a thing, and the one that will probably won’t buy anything.
One paradigm users are familiar with from word processing software and desktop design tools is the ability to edit text or manipulate images directly on the canvas. It is probably most intuitive, if you see an image of a greeting card (as at Hallmark.com) or a business card (as at iPrint.com) to type right on the document, as is in fact the case with Hallmark, iPrint, and Flyerzone.co.uk (below).
This is somewhat challenging to implement, yet it has become extremely commonplace and almost expected with online editing. Still, even if you have the ability to do something on the canvas, is that always the best way to do it?
Again, there are different use cases, and strong opinions either way even in similar situations. The chart above would tend to speak to the value of form-based editing, while the most common argument for direct, on-canvas editing is “that is what users expect.” One of the most simple form-based interfaces we have created is the wine label maker at WindsorVineyards.com – it is extremely quick and straightforward to make a label.
Form-based editors typically have a form to the left or to the right of the canvas in which all fields are entered, and (instantly or near-instantly, we’ll discuss this below) updated on the canvas. Sometimes the fields are presented as an “accordion” in which the current active text field expands while the others collapse, as in the Createspace.com example below. This can be convenient when there is alot of information to enter.
Images can also be edited directly or via some form of pop-up or form. Moderngreetings.com, for example, is generally one of the more free-form sites out there. In the case of images, they allow users to drag and resize the frames themselves (not so common). Because they do this, they provide an “Edit Image” dialog to do image cropping. Users have to work in a form-based window to reposition an image within a frame.
The longer and more complex the document, the more effort should be put into letting the user navigate around through different pages or panels, or possibly through different documents that make up a kit, as well as giving users a clear indication of where they are at in the process. The Createspace example below, for example, has a green circle that will show up in each accordion item when it is completed, as well as a “Tasks” indicator at the top of the accordion giving a status bar of progress and a count of those items completed and those remaining.
Here again we have debate among our clients as to how far to go. Some feel that excessive visual indication of “status” can impede the creative process, others insist that guidance and real-time indication is important to helping users complete the design session without abandoning the session. There is the choice, for example, with multi-panel or multi-page documents, as to whether to even let the user go to another page/panel before the first one is complete.
Different sorts of documents present different challenges when it comes to visualizing the entirety of what is being created online. With greeting cards, for example, often it is nice to see two panels side by side: it may also be nice to have animation that shows the card being unfolded. In some situations, users are creating multiple pieces that are associated: we have seen some animate the finished card being inserted into the finished envelope, for example. With pagination, it is important that users know they have actually edited all the pages in the document: often paginated documents are presented with some form of “page flip” technology to give the feel of the final experience. Shutterfly.com‘s Custom Path application offers several ways to visualize product, from a page-flip view to sequential pages to tiled pages.
Dimensional products offer even more complex challenges for visualization, which is something we are working on currently. Technology for 3D is just starting to be sufficiently robust to support editing in an environment that can concurrently render in 2D and 3D: most current approaches will have a 3D model for navigation and visualization, which pulls in 2D snapshots from the editing of each surface. Between further advances with Flash, CSS and WebGL in the HTML5 space, and general hardware acceleration, it would appear we will eventually be in 3D space throughout the editing experience.
Sometimes the design tool itself is integrated in such a way that it doesn’t have the whole picture of what the user is creating. For example the tool will be invoked by a wrapper application such as a shopping cart, for editing a magnet and its associated envelope, or a CD cover and liner notes. In such cases it is typical for the design tool to pass to the wrapper application sufficient images so that the aggregated end-product can be visualized.
Finally, there is a consideration that should leave little room for debate about what is best, yet which is an important consideration with any online design application: when to render on the client vs. the server. In general, the rule is “render on the client, if at all possible” yet there are both times when it is not possible to render on the client and there are some application architectures where server-based rendition makes sense for some reason.
When we began building InDesign Server–based web-to-print solutions, WYSIWYG authoring was not an easy thing to do at all. If you look at Createspace.com, which we inherited from the Adobe Dandelion project, it is the old-school method of “enter text, hit the server, and wait for the image to render.” With Flash 10 and the Text Layout Framework that came with the Flex 4 Beta, we gained much more fine-grained control over rendition. With CSS3 and HTML5 we now have similar control in modern browsers. It certainly has taken the web a long long time to catch up even nearly to the subtlety of typography that is taken for granted in the print world.
The essence of our base Silicon Designer product is to have a model describing documents that will render the same in a web browser exactly as it will with InDesign Server, XMPie, or Scene7 (any of which can render high quality print output). By taking this approach, user experience is instantaneous: as you edit in real time on the canvas, or via a form seeing the canvas update instantly, you can be confident that the print output will match what you see on the screen. This is a much better experience than waiting around for a preview to come back.
That said, there are a few contexts in which you may wish to hit the server to render output:
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.
I have been working on several web development projects recently, even doing some coding myself which has been very rare the past few years. As I compare what we are doing now to what we did 15 years ago, it really strikes me that the trends in computing and communications have led us from a state of a very limited tool set where there were a few difficult ways to accomplish something, to a world in which there are too many possible ways to quickly and easily do the very same things that were so difficult years ago.
Take dynamic web sites, for example. In 1997, creating a dynamic web site typically required a programmer, and the programmer would typically use Perl or C to work with CGI directly at a low level. PHP, Microsoft’s Active Server Pages, and Java Server Pages soon offered higher-level constructs that lowered the bar and made it easy for beginning programmers to make quite effective dynamic sites. By the late 1990s there were tools such as HAHTSite and FrontPage that even showed the vision of letting non-programmers create such sites, yet these were quite ridiculous at the time and it took quite some time before that sort of approach bore fruit.
When it became apparent that the Web would be central to human communications, technology supporting it very quickly evolved. With the steady exponential improvement of processing power, bandwidth, storage, etc., the underlying hardware has evolved steadily, while software has moved more in fits and starts, with web and information standards held hostage by proprietary self-interest. Still overall the trend has been continuously upward, such that these days we actually do have software (free software, even) that makes it completely easy for non-programmers to create dynamic web sites.
I am writing this with WordPress, which I think shines as a high-level technology that enables average people to easily accomplish what was once a daunting challenge for advanced programmers. WordPress followed a decade of attempts (commercial and open source) at the same thing… software has gotten really good in some domains.
Probably the most frustratingly slow technology, for those of us developing web sites, has been the web browser itself. While technologies such as WordPress have come of age, the combination of committee-driven web standards with limited efforts from the very small number of browser creators has made browser evolution an extremely slow-moving process.
I tech edited a book, SVG Unleashed, in 2003. With hindsight we should have titled it SVG Leashed. SVG was a wonderful standard, yet it threatened browser makers and software companies more than it inspired them: it had some resonance in the Open Source community, yet it moved slowly even there. Ironically it recently rose from the ashes when Apple, Microsoft, and others saw it as a way to prevent Adobe’s Flash from attaining ubiquity. Funny for the most monopolistic, proprietary companies in the universe to proclaim a love of standards, but that is what they had to do when they found their operating systems threatened by an uppity plugin turned VM.
So now even SVG has finally won the victory we thought would have been much quicker, and there is fantastic technology available supporting the same things we wanted to do years ago. Yet while SVG has evolved, other overlapping technology has also evolved. We now have HTML5 and its Canvas, and CSS3, coupled with the wonderful capability to combine these with SVG, so there are more ways than ever to accomplish things that used to be impossible or could only be done a single (and often cumbersome) way.
There is still programming required to use SVG and HTML5. Much of the human insight required is in fact due to the redundancy of SVG, Canvas, and CSS: you can in many cases produce exactly the same result from an entirely different approach, and the art of picking the right tool for the task at hand is currently best done by humans, yet certainly tools will evolve that make this more automatic. I do not see coding going away completely, yet I love the trend that things get easier over time.
So while fifteen years ago the question was “how on earth can we do this?” now we face more commonly the question “which of the many ways we could do this makes sense in this specific situation?” There are times when it truly doesn’t matter, and times when it matters quite a bit. In the specific domain I work in, online editing, the choices between HTML5 technologies have extreme repercussions, yet we’ve seen in some of the output-only publishing cases where it is truly a tossup. Overall it is wonderful to see things where they are today and I wish I had been born many years later.
It has been over a year since I wrote a comparison of InDesign Server and Scene7 Web to Print technologies. This entire past year I’ve been asked about this every few weeks, if not every day (which was the case last week), and I continue to point to that post. I just re-read that blog post again, and I think it is still largely correct in outlining core differences between these two technologies provided by the world leader in print software for server-base document rendition to print.
I am thankful to work with both InDesign Server and Scene7 Web to Print day in and day out, both on an increasing scale. Our Silicon Designer product is rapidly becoming the tool of choice for editing documents online that render in these technologies, and we continue to watch these evolve, help them evolve, and pray that Adobe corporate doesn’t oppress Adobe engineering any further than they have in the past.
Adobe is a pendulum-swinging sort of company, turning back and forth in slow motion on directions such as acceptance/rejection of Web Standards, and I remain optimistic that the engineering-centric nature that characterized the first 20 years of Adobe will return some day and bring the company back to full health and economic stability. Meanwhile, we watch our favorite tools advance or stagnate in different dimensions depending on political climate in a business sphere far-removed from the technical.
Overall, I am optimistic. I have calculated that Adobe has 143 times the engineering staff required to make the world safe for web-to-print. Yet the game isn’t over, at a business level Adobe is at a crossroads, and the core technologies that they have succeeded with in the past are political footballs. Even if InDesign is the default application for making serious documents for print, yet we have no guarantee it won’t be destroyed by ineptitude and pure corporate politics. Same with Scene7: it is obvious that the values and criticality of these technologies are under-estimated by corporate management in this season, but equally obvious that their value will be understood over time.
If you asked me what changed with both over the past year, I would say “not much, yet both are more stable” – I think next year things may be quite different. The InDesign Server momentum is around scalability, cloud-based rendition, and DPS export, while Scene7 Web to Print momentum is around CQ integration and finishing out the feature set. Both have exciting HTML5 stories, yet it remains to be seen how these relate to the other HTML5 developments at Adobe.
So, no more Adobe Flex after version 4.6, etc. I sympathize with the comments here:
Interesting. This is hardly surprising, the Flex framework was already “open source” to some extent technically; yet Adobe has acknowledged there were few if any external contributors of substance. It will be quite interesting to see what happens with Flex… the sad thing is that for all the HTML5 hype, all the work of Google, Apple, Microsoft have not moved it forward quickly enough, and Adobe dropped the ball on standards quite a while back when they chose Flash over SVG, so they will take time to ramp up and the tools for HTML5 are likely to remain sub-standard by compare to Flash Builder for some time to come.
Conversion of Flex applications to HTML5 is not obvious or trivial, as there are just too many ways to do the same thing with HTML5: canvas, SVG, CSS3 can all do text, for example, all with unique features and limitations the others don’t have. iOS is a far easier target. Flex has been a wonderful development framework, partly because it and Flash were not open source, and could be engineered in a way that was more controlled and integrated, more guided.
Adobe had finally gotten Flex to work in so many ways: the text layout framework, the spark component model, 3-D, etc… the irony. It will be very nice when HTML5 development tools rival Flash Builder and nicer still when WebKit rivals Flash player.
Now we have the bizarre situation where most business owners are convinced HTML5 can do everything everywhere today, so there will be even more work converting “legacy” Flash apps to HTML5. When results are apparent against the real-world browser environment, many applications will want Flash fallbacks. While Flash developers today are thrilled to get HTML5 output (limited) from Flash Professional or iOS AIR output from Flash builder, in the future it will probably go the other way, with Flash being a possible output from HTML5 authoring tools, as it will remain a meaningful technology for legacy browsers and specific environments for some time to come.
I was finishing up a very busy week this past Friday, when I got an email from Ed Kotnik – “Congrats on Best of the Best at XMPie Conference.”
This was for an application we built some time ago, but one that is very dear to my heart: our Silicon Paginator implementation for Royal Caribbean Cruise Lines. We worked very hard on this, and it represented a stage in the evolution of Silicon Paginator that was important to me at the time, and is still relevant to our future.
There are many cool aspects of this application, but what I think most significant is the pure InDesign Server automation that renders the very high-quality output from very complex data, following a structure-to-style mapping that lets InDesign templates format content from (mainly) XHTML structures into output that looks hand-crafted. Also the way it was built was a significant step up from the ways we had done this before, as we took on this project right after hiring one of the first in a string of top-notch software engineers that has joined us the past few years, and he took my crude hacks of years earlier on the processing and built it out the right way with more modern technology.
The Royal Caribbean implementation of Silicon Paginator represents the culmination of earlier work with XHTML as a data source for InDesign Server applications. One particular project that had a great deal of similarity was the content management system we built for ACTS Seminaries, and attempted to productize as “Instacatalog” in 2003. This was prior to InDesign Server, but at the time we automated InDesign desktop for catalog output. The application worked by ingesting XHTML, parsing it with a stream parser (then SAX-based) and analyzing each node of content to determine its structural context to render it in InDesign in the correct style, given style mappings between the CSS for the web and the InDesign object styles for print. That application and others like it worked quite well, but I had hacked them in fairly precarious ways. In particular, the processing wasn’t elegant at all.
Despite the lack of elegance back then, it was impressive how well it worked. The one limitation (still a limitation) is that it didn’t handle absolutely arbitrary structures: you could put a list inside a list, but only so many levels deep, for example. Yet it was able even then to validate and reject cases where users would try to go outside of such limitations. And it seemed whatever structures anyone needed, it was easy enough to extend.
With Royal, it had to scale. The volumes were huge, there was certainly not going to be any manual inspection of things. We were fortunate to have more product-level developers working with us, and the whole transform piece was refactored to work very efficiently. Template setup was fairly manual, though we had some utility scripts that were helpful and we developed some straightforward setup guidelines. These days we are much better at tooling the document setup aspect of this sort of application.
The text-intensive, tables flowing across pages form of output with sources like this is still in the minority in Silicon Paginator implementations. More commonly we have relational data sources, with only crude markup from within database fields, producing directories and catalogs more than heavy stories of rich text, but here in applications like this are the fun part. How far are we going? Do we merge cells? Lists within lists within tables? Tables within lists with tables? It is fun to gain control over the transformation between different forms of rendition, with HTML posing some unique challenges and opportunities. While Royal may enjoy the tangible benefits of automated publishing, I enjoy the technical details in seeing what I had personally cobbled together 10 years ago get transformed by real developers into a truly reusable set of tools.
Today I am at SVG Open in Cambridge, MA where we are announcing the HTML5 Version of Silicon Designer. It is hard to convince some of our clients that Flash has any place at all in an applications, yet we are still very happy that we mastered Flash as it makes our HTML5 efforts focused on WebKit rather than pretending that it magically makes IE8 into an RIA (Rich Internet Application) powerhouse.
Deploying the Flash player and Webkit with parallel forms of the same application lets us reach the entire browser base, from legacy PC browsers to the full spectrum of mobile devices, without degrading user experience. We write once, and don’t have to test everywhere. Our approach is: ‘Flash where Flash goes, HTML5 where Flash doesn’t go.’ And we don’t see Flash going away anytime soon in the online editing space; it still provides the richest experience in many contexts. Targeting the most powerful media available on each distinct client lets us ensure the optimal user experience across all devices.
That is my philosophy for Silicon Designer. Not for all web apps. But with Silicon Designer, here we have an extremely rich client experience using Flash, which currently has no parallel in the HTML5 world, quite, though Safari Webkit and Chrome Webkit are getting close, and the Adobe extensions to Webkit bring them closer.
At SVG Open we saw various approaches to legacy browsers, when apps start out in standards-based mode vs. in Flash:
These all can be fine, depending on user base, application characteristics, etc., but with an online editor for high quality print documents, none are currently ideal. Flash still has the ultimate power for robust vector graphics… Webkit and other implementations of HTML5/Canvas/SVG are just catching up. SVG Web is not an option for us, as our HTML5 version uses HTML, Canvas, and SVG, not pure SVG (I doubt there is currently an “SVG Web” equivalent for the full gamut of HTML5).
Deriving one format from another generally leads to poor quality in the format that gets derived. It is more powerful, if you can afford it, to have both forms of something derive from a model that is not tightly coupled with either one, using a higher level of abstraction.
In our case, as we already have a robust Flash app, and we specialize in defining the document model agnostic to rendition engine (as this model has to work in Flash, InDesign, and Scene7) it’s not the biggest deal to have two versions, one Flash and one HTML5. With the HTML5 version, do we really want to target IE9? Firefox? It would be nice, yet it is not critical.
Essential to us is hitting the iPad, especially, secondarily providing good mobile experience (as designer tends to be most relevant to larger screens, phones are not often used for high-end forms of design) and providing on each device/OS the best possible experience. Targeting just Flash and HTML5 that works with Webkit, we get all we need.
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.
But it isn’t just the technological genius of Steve that is amazing, it is also his integrity as a human and his devotion to his work. If those things were present in more humans around the world, we would have no war or hunger.
I got into computers early in life, first doing a little bit of programming at the Lawrence Hall of Science in Berkeley in about 1974 when I was a kid. I even ran into home-built computers at the time: at summer camp there was a man there that taught us how to build a computer from a minimal set of chips. If this same guy wasn’t part of the Homebrew Computer Club (which is perfectly possible) that Jobs and Wozniak were part of later, he might as well have been, it was inspiring to be able to say “I built a computer” even though it was pretty useless. I wasn’t really interested in such things at the time, but the memory comes back when I read about early Apple history.
Looking back, any great invention will appear obvious, like it would have inevitably happened, but there are at least two dimensions to any major technological advance, the concept and the implementation. Steve Jobs had a very fundamental concept of the personal computer that might not have been original, yet he had such an ingenious vision of its implementation that for all practical purposes he is owner of the conceptual advance.
Once the conceptual battle is won with a new invention, the implementation and evolution provide a lifetime of potential work, and Steve took this on as few others in the history of science. So many scientists who push forth a new idea are blind to its repercussions and unable to produce further advancement, yet Steve was the opposite extreme, re-thinking technology even in the last years of his life, 35+ years since his fundamental breakthrough.
I first encountered the work of Steve Jobs when I saw the Apple II computer, which I learned to program in 1980. Concurrent with this I was working on a DEC-20 mainframe, and the difference between the two was night and day. The personal computer liberated one from the centralized system, from punch cards, from the ridiculous sharing of sparse resources such that you might wait 24 hours to see if your program had compiled or not. It is impossible to explain to young programmers of today just how bad it was pre-PC, but I had a glimpse of it and it definitely sucked.
While I was in awe at the fundamental chasm between PC and mainframe, I didn’t appreciate the design of the Apple II in relation to its competition until I looked back, as I later saw Apple’s computer design evolve through the variants of the Macintosh over the years. Yet with hindsight I can see that the Apple II already expressed the phenomenal design ambition/insight of Steve Jobs.
At the time I used the Apple II, it was simply one of the few options available, and given that I was using it for digital audio at a time when processor speed and availability were so anemic, it still felt more something like the time I had played with a home built computer; certainly there were some use cases for which this was already a practical device, yet it had extreme constraints compared to what would come next.
The second time I was impacted by Steve’s work was when I started using and programming the Macintosh, back when it was that single box with a keyboard and mouse circa 1984. It is amazing to look at this compared to the Apple II and compared to today’s Macs… at the same time it looks advanced and ancient. That is how far we have come with personal computers, and shows the incredible speed at which Steve’s innovation went. The early Mac was also interesting not just in terms of design, always Steve’s obsession, but also in terms of the early adoption and focus as a tool of expression as opposed to a business device. Once there was the IBM PC to compete with it, the vision of Apple could be seen clearly, and here was the expression of Steve’s great mind. The Mac was what one used for art or music, right from the start. And here we saw digital audio (my obsession back then), which had been completely painful with the Apple II and IIe, find a home. Ever since the first Mac, the personal computer as a tool of artistic expression has been owned by Steve Jobs.
There was a whole evolution of the Mac from the mid 1980s to the late 1980s, where it seemed to get more powerful, yet while the continuous incremental improvement in terms of things like processor speed and monitor/video card power, coupled with the evolution of the software on top of it suggested evolution, the form of visionary transformation that had happened between the Apple IIe and the Mac left Apple, along with Steve Jobs.
I never actually used a NeXt box, but I dreamed about one and read about it for 2 years. I was at that point starting to realize how incredibly important a visionary like Jobs can be. It was no accident that stunning advances in technology were now happening over here instead of at Apple. NeXt was quite innovative in so many ways, and it was of interest to me through my interest in computer music (that was my only interest in computing the first 15 years or so).
NeXT was in some sense vaporware: academic departments across the US (around the world?) made plans around it, based on promises of free/cheap NeXT machines for academia and a significant amount of testing/input from academics. Computer Music Journal would present the NeXT audio capabilities as second to none, right above the digital audio and multimedia that at the time was starting to fully work in the Macintosh, with all the newer more expensive models that iterated throughout Steve Jobs’ absence.
Many have spoken of Steve Jobs’ “failures” and some would cite NeXT as such. The complaint is similar to complaints about Larry Ellison, that he has a loose concept of “we’ve done that” equal to his ability to think through how one might do something. But technology is fragile, in many senses the concept *is* the advance, as long as you have the integrity as Jobs and Ellison do to fulfill the implementation of the concept.
The Mac kind of left my life when Steve Jobs left Apple… I dreamed of a NeXT box but it never materialized as such. Eventually, everything in NeXT showed up in Apple products.
I saw Steve Jobs in person the first time at the JavaOne conference in 2000, when he showed a preview of OS X. It was quite stunning, and the Unix underpinnings, NeXT features, and built-in Java ended up being quite compelling for developers, who really hadn’t been enamored of the Mac other than in specific cases (those developing multimedia software, for example). At subsequent JavaOne conferences mac laptops became increasingly prevalent. This and some of my work requirements led me to start buying Macs again in the early 2000s.
I saw Steve Jobs for the 2nd and last time a the Apple WWDC in 2006. I had been using Macs more often, yet was not impressed with the performance of pre-Intel Macs, even with OS X. When my company worked on benchmarks for Adobe of InDesign Server across Windows and Mac servers, the results were unreportable because the Mac performed so badly compared to Windows boxes and nobody at Adobe wanted to make this public (they still had hopes for the Mac/fear of Microsoft at that time). The G5 chip was nothing to write home about, and Apple noticed and moved to Intel.
The move to Intel proved to be brilliant, for at least two reasons: performance surpassed windows, and running virtualized windows proved good enough that I could stop lugging around 2 computers. I was impressed that as an Apple developer, they shipped Intel-based hardware to me prior to the official announcement of the move. From the time of the Intel chip and Mac OSX, Mac has once again been my primary operating system and all my laptops since 2006 have been macs: Windows is still there when needed on the VM, but I have needed Windows less and less.
Of course the impact of iTunes, iPods, the iPhone, and the iPad has been another aspect of Steve’s incredible vision influencing the world. My family has become an Apple ad, with iPhones, MacBooks, etc.: my one-year-old knows how to swipe the iPhone, open apps and use them. I am not completely fond of Steve’s vision of tablets (I’m still expecting more freedom and computer-like features, not just a large phone), yet I have to acknowledge he got it right enough to finally reach the public with such a device footprint, and Google is too dumb and fat (they are clearly as arrogant and inept as Microsoft) in trying to compete. On first glance his staunch opposition to Flash looked somewhat tainted by a monopolistic tendency, no doubt gained in his ongoing rivalry with Bill Gates (certainly he took on a few traits of the enemy along the way) yet I think he ultimately had a positive impact on Adobe by challenging their overconfidence in the Flash “platform” and at least partially supporting standards.
If I had to pick the greatest technologist born in the 20th century it would either be Steve Jobs or Charles Goldfarb: I am very thankful to have been able to live in their general neighborhood (Northern California) and enjoy the technologies they have brought us. I am glad Steve died now rather than two years ago, as only in the past two years did he truly “win” in the Jobs/Gates war by every last objective metric.
I loved the dialog from Pirates of Silicon Valley:
Steve Jobs: “We’re better than you are, we’ve got better stuff”
Bill Gates: “That doesn’t matter”
I am glad that Steve hung in there despite his health battles to show once and for all that right can triumph over might, and the best can prevail. He will always be a great inspiration for us all.
It does matter.
My report about this Adobe MAX is delayed and mainly based on post-conference analysis, as in the conference I was busy announcing, explaining, showing, promoting and helping develop our Fotolia CS Extension. This year we had a booth for Silicon Publishing, which meant I attended keynotes and sneaks but no sessions, yet it also meant I was able to talk quite a bit with people who did have the luxury of attending sessions. Thanks to our recent success as a company, I think the majority of the people I spoke with were the ones leading sessions, and I am thankful to have the honor first of working with the Silicon Publishing programmers who today are of such strong quality, and by being associated with them getting to meet other geniuses of publishing today such as Chris Converse, David Blatner, and James Boag.
Overall, the news is postive, very positive… Adobe has many HTML5 initiatives, the Creative Suite is going to move to do what it should have done all along, allow InDesign to be a control center for multi-channel publishing, and Adobe does have some sensible understandings of a low-end market after all for its Digital Publishing Suite. The “Creative Cloud” was set forth as the main message, in that Adobe seeks to put Creative Suite sorts of capability, relevant to the new mobile/tablet/HTML5 reality, into SaaS- or PaaS-model offerings.
I am still trying to look deep enough to find evidence that this is being done in anything but a Google “spray and pray” way (i.e., putting out 100 apps and keeping the surviving 13), and if there were a down side to the current apparent trajectory, that would be it. Given the disruption of the initial introduction of Adobe to Macromedia to the creative suite (for a moment InDesign looked “legacy” while Flash looked like a “platform”), and the concurrent “anything for the street” mentality of a company that spent $3.5 Billion and needs to get it back somehow, I am thankful for the Google approach, it is at least trying the 100 things along the lines of their core competence as a business, unlike random non-sequitur unrelated ventures such as Business Catalyst. After that one, I was waiting for the Adobe announcement that they sold toilet paper on a subscription basis. But I digress.
Before diving into the present, let’s look at the past 6 years a bit.
Ever since Adobe bought Macromedia, I have been attending the MAX conference. The first “Adobe MAX” in 2006 was interesting to me… I spoke there about DITA and eLearning, and was able to discuss technologies that had roots in both Adobe and Macromedia, with assistance from experts from both companies. The SCORM expertise of those who had put SCORM support in Macromedia Flash, the DITA and print rendition expertise of FrameMaker and InDesign technologists. In a pure technology sense, it was exciting to consider the merger. As usual, I considered it in relation to standards… as far as DITA and SCORM, I had little to complain about, as expectation/hope had hardly been raised: these tangents to rendition technology were obviously better off thanks to the merger. SVG? Good thing I wasn’t presenting on that topic.
Politically, it was strange. Hanging out with speakers waiting to present, I noticed a surprising degree of fear and suspicion between the former Macromedia people and their new colleagues. The impression was that Macromedia people were in fear of their jobs, and resentful of the acquiring company. Presentations around Macromedia products (and at this point non-Macromedia products were just barely mentioned at MAX) would often include bashing of Adobe equivalents… “you’ll notice our software loads quickly: we hope to teach the Photoshop team a thing or two…” Such jabs really didn’t fit what Adobe had been before, but were probably natural side-effects of fear and uncertainty.
Where was HTML5 at this time? There are two perspectives:
Adobe had actually led the SVG effort in 1999 and 2000, but had not invested in it in a broad way, and by 2006 many were proclaiming the death of SVG. To the great credit of Open Source software, Mozilla and some others didn’t see it has dead, yet they were quietly working away at SVG support.
As far as HTML5, it was right around the time of MAX 2006 that Tim Berners Lee and others embraced the HTML5 effort.
Adobe at the time had swallowed the Macromedia egg and started to delete SVG support from its applications, starting with discontinuing the Adobe SVG Viewer
Within a year, the nervousness of Macromedia speakers at MAX 2006 proved completely unfounded. The tables had completely turned… By MAX 2007, it was clear that the Adobe acquisition was balanced to a fault: the joke by then was that Adobe “acquired” Macromedia but Macromedia took over Adobe. Former Macromedia people were enjoying great political clout, Dreamweaver had replaced GoLive, and the Flash Platform was starting to look like invincible technology. By MAX 2007 there were some very cool examples of collaboration between the amazing engineering talents of the two companies.
In my case, I was fascinated by the Dandelion project that was demonstrated in Chicago: my company eventually had the honor of inheriting this prototype application (Adobe didn’t wish to support it after it was officially abandoned), which represented a high-level combination of technologies. I had hoped for a more low-level reconciliation of the extremes, but while the acquisition was ambitious, it was extremely pragmatic. There were very early indications at MAX that Flash 10 would have much better text, but the Flash 9/InDesign integration that Dandelion represented had to hit the InDesign Server for high quality text rendition.
Adobe MAX 2007 also included the first demo of “Thermo” which later became Flash Catalyst. It looked quite stunning, a rich internet application now could be instantly created by a Photoshop designer, apparently. Ever since that first one, Catalyst demos have showed a much less rosy picture. We didn’t as of MAX 2007 have much insight into FXG or the Spark component model, which would be the underpinnings not just of Catalyst but also influential across numerous Adobe application, and would have direct relevance to the “Flash vs. HTML5″ question.
I am the gullible, naive optimist that can imagine a company like Adobe having the guts not only to spend $3.5 Billion on Macromedia, but also to think of technology first when assimilating such a company. Hadn’t Adobe supported SVG, the standard for vector graphics? At least one person did, as he wrote the spec. Yet I have gradually gained some insight over 15 years of having my hopes for standards constantly disappointed: even by 2007 I realized that if anyone at Adobe supported SVG, it wasn’t the person with the $3.5 Billion. No, that person supported the goals of the public company, like any good corporate shepherd.
Adobe could have had the guts to kill Flash right then and there. They actually could have killed it in 2002 or 2003 if they had been more ambitious and less fragmented with SVG, in my optimistic opinion. But as a public company they have to be so prudent, the SVG “silo” had to be incubated and analyzed to see what chance it had to bear fruit… and oops, it is not just a technology, it is a standard. The sensitive issue of when/if to support what form of “standard” is a balancing act for corporations, there is rarely an actual person leading these companies, capable of true support for standards: instead, committees define the proper balance between cheering on the standard (when politically convenient) and copying it into proprietary formats.
But no, in 2007 SVG was off Adobe’s radar and they were full steam ahead with Flash. Flash in Adobe’s hands made huge steps forward. They dramatically improved performance, they made stunning text improvements (“Vellum”), and Flex took shape as a serious development environment.
Adobe MAX 2008 showed the fruits of the first low-level integration work between the two companies that made a difference from the perspective of our company. We saw the Flash 10 Text Layout Engine, and thought for a moment… maybe standards just aren’t so important. For the first time, on the web, we can do things with text that should be basic to human communications. This is through proprietary technology, but it isn’t so bad…
Adobe MAX 2008 was the point at which the glimmer of Flash as a ubiquitous “platform” shone brightest. The fact that it didn’t run on mobile at all didn’t bother us then, because there were still graphs and charts implying it *would* run everywhere, naturally, of course. As of 2008 they weren’t spinning or faking these graphs and charts. It was already apparent that iPhones weren’t supporting Flash, it was becoming increasingly noticeable and some were already proclaiming it would never happen, but as of MAX 2008, many still believed that Adobe was working out the engineering and there would be an announcement any day.
Where was HTML5? The spec was moving rapidly, WebKit was advancing quickly, and Mobile Safari was starting to support SVG.
By Adobe MAX 2009, the Adobe/Macromedia rivalry was a completely internal affair… the public didn’t care/know about anything going on there, by this time it was Apple vs. Adobe, pure and simple.
Johnny and Kevin pretended all was fine in terms of Macromedia/Adobe, and that a VM approach to iOS apps would cure everything. Yet (a) Macromedia technologists had been given responsibility beyond their capability, and (b) Apple was hell bent on attacking any such VM approaches, thanks to the rare case where a human being actually ran a huge company. It appears that Steve Jobs personally made sure that Adobe would not casually virtualize iOS development.
By 2009 HTML5 was moving rapidly, there were cool demos on Apple.com, and demos based on nightly builds of WebKit were getting quite stunning.
This made for interesting shakeups prior to Adobe MAX 2010… by MAX 2010, Apple had relaxed its restrictions on virtualized iOS apps, and Adobe had gone further with Flash to HTML5 export. The 2010 keynotes had more dumb messaging and less content than any MAX I had seen, including puppets representing Flash and HTML5 learning to “live together.” In a rare moment of meaningful content, Kevin Lynch spoke of the work of Adobe to contribute to WebKit with an implementations of CSS Regions and CSS Exclusions.
Since MAX 2010 these minor efforts have born fruit… Adobe contributions are in the main WebKit and early Chromium builds, and have been implemented in IE 10 preview. Kevin Lynch recently summarized his perspective on the state of HTML5/Flash just prior to MAX 2011. Yet there are probably much deeper repercussions of the growth of HTML5 on Adobe’s technology path. Certainly the Flash “platform” is not aiming where it once aimed, and FXG is either deprecated or relegated to maintenance mode; there are still advances with Flash that keep it ahead of HTML5 in some respects, but there is also a rush to embrace HTML5 with new tools like Edge and Muse, as well as new features of Dreamweaver and other CS apps. Adobe is covering both bases, probably putting more emphasis on the HTML5 side.
Packaging Flex for Mobile devices has improved over the past year, and AIR support on the iPad 2 offers a better option than previous “build in Flash, run on iOS” attempts. Using Flash or other Adobe tools to create iOS native apps (as targeted by the Adobe Digital Publishing Suite) seem better handled and more of a priority to Adobe than reconciling Flash with HTML5. Flash Media Server can now serve up HTML5 video, Scene7 has some HTML5 features. Many small moves in the HTML5 direction, nothing fundamental.
Adobe MAX 2011
So here we are at MAX… based on what Adobe had put forth recently, as well as the sessions scheduled for MAX, my guess was that we would see a two-track approach: Flash will get better, staying ahead of HTML5 in some respects, yet there will be more HTML5 tooling, more HTML5 features, more forms of conversion. My main question was whether there would be anything fundamental and core tech that takes shape. When “Apollo” (AIR) came out, there was the big question of how to reconcile all the formats… the FXG effort was a possible move towards reconciliation. Flash Catalyst did not live up to expectations, the Flash “Platform” didn’t live up to expectations. In terms of HTML5 they have scrambled to rush out patches and prototypes that do a few things, but is there a fundamental core tech direction that has taken shape yet?
From MAX 2011 it seems my suspicions were correct that Adobe went after both the HTML5 and Flash tracks to advance a pluralistic approach, trying to catch up quickly in the HTML5 space and keep pushing Flash where it enjoys success. But my hopes of a core tech approach have not yet been fulfilled. It appears that everything is so new, and so much growth is by acquisition, that the core tech ambitions have evolved towards a more pluralistic, less integrated vision than was put forth a few years earlier as FXG seemed to bridge the creative suite apps with Flash and Flex. Or maybe I just missed some key session that was obscure… if anyone knows of such a thing, please clue me in.
The MAX conference coincided with the release of version 11 of the Flash Player and AIR 3, which push forward progress in Flash and AIR that has been moving steadily for years. The “Molehill” technology (hardware-accelerated high-performance 2D and 3D graphics), presented at the last MAX, finally came out with Flash 11 as “Stage 3D.” The Flex capability to create applications for mobile and tablet was touted, with the same vision as last year but much more tangible results. There was not a revolutionary advance on the Flash side of things, but the amazing performance of the player moved forward enough to show that Flash is likely to retain viability in the areas it still shows relevance, and can still light the way for HTML5 in being the first technology to make certain things possible on the web.
While the things that Adobe did show about Flash were cool, it was at the same time telling what they did not show… mainly, the killer demo of the past 4 MAX conferences, Thermo/Flash Catalyst, was nowhere to be found in the keynotes, though it did enjoy a session or two – it appears they may have gotten round trip to work, sort of. But the momentum of this product appears to be gone, between the more limited use cases envisioned for Flash now and the slow momentum of the technology itself. I would not be surprised to see Catalyst go away… it appears now more like a utility than an application.
What had been the promise of Flash Catalyst? That designers could create Rich Internet Applications. It now appears that Adobe doesn’t really think of Flash as the primary form of such applications… as is evidenced by comments in the latest Adobe earnings call, Adobe is aware that HTML5 is a more compelling output for an application like Flash Catalyst.
A number of already-announced initiatives for HTML5 were presented at MAX:
Muse seems to have usurped Flash Catalyst as the shiny button for magically generating code without coding. As the output format is so new, it will probably follow a path much like Flash Catalyst, enjoying a honeymoon period when nobody expects things to round trip, eventually reaching a role more as a utility than a true authoring application when the realities of real web publishing and the technical challenges of round trip become apparent.
Beyond the pre-existing HTML5 technologies, the following new initiatives announced/previewed:
I was most impressed with the HTML5 features of the next InDesign, which Kiyo showed in the Sneaks. These are discussed and shown on InDesign Secrets. This makes so much sense… designers are already in InDesign, which is an extremely well-built layout tool – there is already a very common requirement to “repurpose” print content from InDesign to web and tablet. Yet InDesign has had starts and stops in direction regarding output… SVG export came and went, HTML export has taken on several different forms, the Digital Publishing effort started as a clumsy crude hack but did at least start from an InDesign-based workflow.
The hope is that now Adobe has learned from their experiences that InDesign is not some sort of “legacy print app” ready to be put out to pasture, but a powerful design tool for multiple media. We have already been using it as such for many years, but simply by leveraging its wonderful exposure to automation, with CS5.5 and the new planned features, there look to be some directly usable multi-channel capabilities that will require far less work. It would appear that when Flash Catalyst appeared on the scene a few MAX conferences back, the InDesign multi-channel concept went on hold, and has been dusted off now that Flash and Flash Catalyst are looking far less omnipotent.