We are very excited today to announce our Cloud Designer product, something we hadn’t thought of back when we announced Silicon Designer at the Print 09 conference. We are now at the Print 13 conference, and quite a bit has happened in the past four years. More than we ever expected, actually…
What have been the challenges in selling Silicon Designer? There have been many:
This has not been a huge problem for us, we have had a steady flow of clients such as Shutterfly that just want the best solution, they are happy to have the best possible design tool customized to their unique requirements, and we see the high-end market for custom solutions continuing forever.
However, we have had to turn away the majority of inquiries for Silicon Designer. Prospects, especially small- or mid-sized printers, have frequently wanted an inexpensive tool with a shopping cart and a library of templates.
Today, with Cloud Designer, we are able to say:
The beauty of how this came about is that it did not involve a huge change in our development process at all: we were very fortunate that one of our longstanding partners, Grafenia, brought their considerable expertise/experience (over a decade of development on the back-end technology, for example, with deep experience running software in print shops around the world) to the shopping cart and back-end software, as well as their hosting experience. It is convenient, too, that they work in Europe and have focused on things like localization.
While we have continued to extend and expand the functionality of online editing, and that remains our focus, we expect to be more involved in the other dimensions of the product over time.
We believe this opens up a whole new market for Silicon Designer. While there are numerous half-baked attempts at SaaS design tools, and there has been a decade-long string of failures at canned web-to-print software (the plug-and-play shopping cart is not something that even huge companies like EFI and Xerox could ever come close to making barely functional), the quality of our Cloud Designer offering is something the print industry has never seen before. It is already being used by several major companies with success, and we believe it is a great opportunity for entrepreneurs and printers who have wanted Silicon Designer technology the past four years.
I have been writing for three weeks now on Medium.com, my most recent effort being the voluminous “The Greatest Software of All Time: a Developer’s Appreciation of Adobe InDesign” which is actually content I would normally put here. Why did I put it on medium.com? Probably because the UI is so fun to write in and the collaboration features are awesome.
I started simply to try it out but now I plan to keep writing there (mainly about non-technology -related things). I was initially just curious about the editing interface as that is one thing we are constantly building here at Silicon Publishing with our Silicon Designer product.
In most cases we are not the ones coming up with the designs, yet we do occasionally get asked our views, and we have learned from having implemented designs from top-caliber clients such as Adobe, Google, Shutterfly, Old Navy, Disney, and many others. I have written some notes on the design of editing interfaces here previously.
What makes medium.com’s editor so great? I have noticed the following seven cool things:
1. A minimalist but effective set of available styles
The stylesheet is very clean, and there are few formatting options: bold, italic, H1, H2, two types of quote, one form of bulleted list and one form of numbered list. There are no tables, no alignment, no option to create your own styles. It is true that every post will have a similar look to it, but it is a very nice look. They have done a great job of tailoring the rendition to the range of screens: captions, for example, will fly out to the side of the text flow if you have a large screen but will be under the image if you are reading on an iPhone. In general there are few options, but very little to think about in terms of formatting or style, which lets you focus on writing.
2. A very non-intrusive styling UI
The interface is almost completely WYSIWYG: as you type you are mainly working in the exact context of the rendered output. When you do need to format some text, you do so from a simple pop-up above the text you’ve selected.
The combination of very few choices coupled with easy access and a tool there only when you need it is refreshing, compared to say the WordPress text editor I am writing this in at the moment. Again, it lets the writer focus on the writing rather than the formatting.
3. Styling without tooling
Seeing no bulleted or numbered list on the toolbar, I first thought there were no bulleted or numbered lists available. Wow, now that would be very minimalist, indeed. Well, lists are actually there, but they come about by simply starting a paragraph with a number or a bullet, and the formatting just appears. Now that is non-intrusive indeed.
4. Collaboration that doesn’t get in the way
Medium is about collaboration and I have been impressed how great it is in that respect, both in terms of the user interface of the application and the community around Medium. In terms of the UI, comments are neatly out to the side: you won’t see them until you click on the little call-outs, then you will see what your collaborators have said, to the side of the text flow.
You can easily discard them, and decide who can see them: you can also directly respond to the clients. Comments are associated with the paragraph, which is natural: compare Adobe Acrobat, where you have to decide where to put a comment. That might be of benefit for annotating a graphic, but it makes for a mess in the much more common case of collaborating on textual content.
5. Intelligent auto-save
The auto-save is of course very nice. I believe you can also “cancel” the editing session if you desire, though I have not tried it. Again, this is just one more thing that lets the writer focus on writing.
6. Thought-free image and caption management
I am extremely impressed with how it manages images. With the current wordpress template I’m using, I have to spend time re-sizing images and enter information about how to place the image. With Medium, you simply upload at a fairly high resolution and it takes care of the rest. You have some limited options for dragging an image around text, but it is accomplished by dragging, not setting parameters in a screen.
7. A distraction-free, WYSIWYG experience
The totality of the UI features lead to an experience of writing in the context of the rendition itself, with absolutely minimal distraction about formatting. The writer has available just enough formatting, in an easy-to-access, non-intrusive environment.
Medium.com truly is a wonderful example of a WYSIWYG editing experience for online, flowing content. It gives writers a place to write with about as little to worry about in terms of formatting as they are likely to encounter in any online editing system.
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.
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 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.
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.
We are today issuing a press release about Silicon Designer, two years after the first announcement. It has been a busy two years since we announced this as a product, yet it really has a much deeper history. Today’s release touts our recent success with multi-channel output, yet it is not that multi-channel is new to us at all, it is that we are finally doing it the right way from a single system. Let us go back to some of the early work that led to the organic productization of Silicon Designer in 2009 and the recent work that has brought us success with multi-channel, most notably email and tablet output from the same editor used for editing print documents. Finally, we’ll consider the two ways HTML5 is central to the future of Silicon Designer.
1998 was a great year. Back then, the Silicon Publishing founders were working at Bertelsmann Industry Services (now known as Arvato, a group of the Bertelsmann publishing conglomerate), in a San Francisco-based automated typesetting division (formerly Delta Electronic Publishing) that had been acquired by Bertelsmann earlier in the 90s, which had a rich 20-year history and codebase.
We were continuing the legacy work of automated typesetting, for example churning out hundreds of directories or catalogs from databases in a single pass using tools such as Xyvision. More exciting, we were leveraging the same data-generated-markup tactics that had been used for 20 years in typesetting, now to feed dynamic content to the web. We were also creating online composition applications. So the same clients that 10 years ago had hired BIS to automate the typesetting of healthcare provider directories for print could now have us build dynamic web applications from the same data (“find the Spanish-speaking OB/GYNs within 10 miles from your home”). When the list came back, we could dynamically create PDF output (“generate a personalized directory from your search results”).
We were good at dynamic web output very soon after the web came out. The reality was (and still is) that the fundamental coding central to dynamic typography is identical to the coding of web output. While there are unique characteristics to the web vs. print paradigms from a design perspective, yet the coding has more similarity than difference, and those of us with robust toolsets for dynamic markup in the mid-90s were able to do things on the web with more sophistication and flexibility than many who were new to the game. Our SGML background from working in the tech doc space didn’t hurt, either. After all, HTML was an SGML dialect.
Even back then, we were building online design tools, they were just crude, limited by the capabilities of browsers and rendition engines. Users would typically control content from HTML forms, from which they could either enter the content for a single document, or map data sources and define business rules to generate multiple documents, or single data-generated documents, from a web interface.
In 2000, we founded Silicon Publishing. The success with BIS had been too extreme, and at the peak of the dot com era things got just a bit crazy when our division was spun into a dot com unrelated to what it had been doing the previous 20 years.
We founded Silicon Publishing with no greater ambition than to continue to do what we had done at BIS… the most exciting part of which was online document generation.
Silicon Publishing was initially less capable at web-to-print than we had been at Bertelsmann. We could compose with PDF libraries, but we didn’t have a composition engine with real typography on the server such as Xyvision. We found that automating InDesign (even version 1.5) could produce stunning results offline, but it was not licensed for server. So our first years we did very separate web development from print automation in most cases. This was in some ways a step back, yet it let us focus on web and print in separate streams, as 95% of organizations still tend to do today.
We were passionate about SVG and hoped to use that as something of a web-to-print engine, yet it was an uphill battle to get either browser support for SVG from then-dominant Microsoft, or good print support from the SVG spec itself, from open source projects such as Batik and FOP, or from commercial vendors such as Adobe. In those days, Adobe was still squarely focused on the desktop. Still we prototyped online editing tools in SVG.
Our InDesign automation kept going, and we begged Adobe for an InDesign Server for years. They finally released InDesign Server in 2005 along with CS2. We were in the first group of InDesign Server resellers and we were able to take the batch composition work we’d done with desktop indesign and port it over to server.
From then on, Silicon Designer was inevitable. We got requests to build Flash or HTML front ends to InDesign Server, and we started building them one by one. By then we had totally mastered automating InDesign in terms of batch composition, yet there was some work to reconcile the graphic models of InDesign to either Flash or HTML, especially when it came to text.
BIS had instilled in us a religious belief in services. The charismatic leader of BIS in the 1990s had been a young guy named Ralf Bierfischer, and he would passionately declare that we did services, not products. I think this was instilled in my subconscious, I never considered productization until it became really obvious. “Hey, we have built the same exact application 15 times now, maybe we should consider building it as a product?”
By 2009 we had built many forms of web front end to InDesign Server, and with the Flex 4/Flash 10 text capabilities, we were really round-tripping Flash and InDesign extremely well. At this point we began building a product based on our years of experience with custom solutions. We were able to hire some amazing talent to do this, in part thanks to Adobe layoffs.
At that same time, a new form of back-end composition entered our lives: Scene7 Web to Print. While InDesign Server had the ultimate composition power one could ever dream of, it had not been built as a true server, and scaling it was (and remains) a fine art. It can be done; with enough instances/servers you can attain any level of throughput, yet the response time is not what one would write home about, even with optimization (by 2009 we mitigated this by letting all edits occur on the client and only using the server for back-end rendition for print). Scene7 was different: it started out as a very true, server-based product.
We started building Scene7 solutions and helping Adobe with the Scene7 product. We decided to have a second form of Silicon Designer, with a common front end but using Scene7 Web to Print instead of InDesign Server (or in some cases combining) on the back end. Scene7 had certain advantages over IDS in some cases: the updates to vector art were very quick, the cross-sell/up-sell capability great (because of the speed of preview); in general it is more server-like, but less finished in terms of pagination and typographic detail. I have explained the differences in fairly excruciating detail.
Still, this did not stop our work with InDesign Server at all. As I’ve explained, there are still tradeoffs, and our Silicon Designer product makes the one big Achilles heal of InDesign Server (rendition time) a non-issue, as we render everything in the client. We have gotten better and better at working with InDesign Server, and our Silicon Designer implementations are now about 50% Scene7, 50% InDesign Server. Hard to tell whether that will change over time.
We already had an XML model for documents that supported round-tripping InDesign and Flash, now we extended this same model to accommodate Scene7. 2010 was interesting, just when we had gotten Scene7 figured out, it became clear that the HTML/SVG work of our past was going to come back into relevance, thanks to the lack of momentum of Flash on mobile devices. HTML5 is still behind Flash in many ways, yet it has reached a level of maturity as a spec and support from WebKit, that we are adding it to the set of rendition translations from our core XML model.
If that were not enough work, we have recently been extending Silicon Designer into an email editor, and it really works well, far better than the direct HTML editor approach (along the lines of HTMLArea, FCKEdit, TinyMCE) that we used to take for such things. With HTML email, constraints are essential, and keeping the details of the HTML out of the hands of editors can make such a system bulletproof. It helps to work from a core model of rendition that is independent of the UI and the final output.
The future of Silicon Designer is HTML5-based in two ways… it is fast becoming an HTML5 editor, i.e. an editor that produces HTML5 as one form of output, while we are also building a version of Silicon Designer that itself is coded in HTML5. We don’t see Flash going away, it is pretty much a philosophy of “Flash where Flash goes, HTML5 where HTML5 goes” with common models for document rendition and other things that keep the document setup process and print rendition the same with the different UIs. Our core XML model for rendition is the reason for our success, and we have benefited from having to render diverse outputs over the years. It is a fun time for this technology.
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.