At the time Adobe InDesign was created, 15 years ago, it was generally impractical to store print-quality assets on web servers. A decade and a half later, however, the maturity of cloud-based file storage and asset management systems is making links from InDesign to assets housed in modern platforms, such as Box, a powerful solution for creative professionals.
Adobe InDesign is the tool of choice for the creation of high-quality print documents. It is nearly ubiquitous among those creating newspapers, magazines, books, catalogs, marketing collateral, or almost anything that prints. InDesign started out as a competitor to QuarkXPress, and given the dominance of Adobe in tangential technology (PostScript, PDF, PhotoShop, Illustrator) along with substantial and well-focused investment in the product, it was inevitable that InDesign would take the place of Quark at the center of high-end publishing workflows.
Incorporating graphical assets into an InDesign document was much the same as it had been with Quark. Assets placed in a document could either be embedded in the document or “linked” to their location on the local file system (or network share). The best, most common practice was to link assets, as it kept down the size of the InDesign file and allowed for independent work on the assets themselves. Collaborating on documents typically required “packaging” the dependent files, then exchanging not only the InDesign file, but the fonts and links that it depended on as well.
As of 1999, when InDesign 1.0 was released, there were some web-based asset management systems, but they primarily targeted assets for the web, not for print. At that time (long before the advent of retina displays) graphic assets for the web had significantly lower resolution (meaning much smaller file sizes) than print assets. The traditions and habits of the print industry, coupled with the infancy of web-based storage, meant that InDesign initially ignored the possibility of linking directly to web-based assets, but was instead designed to operate on a single computer or network. Few if any features of InDesign 1.0 had much to do with the web or http.
Cloud storage has finally come of age due to a combination of factors. Among cloud storage platforms, Box is proving itself as a leader, with a momentum similar to the growth of the internet itself.
As of 1999:
Given these factors, along with the relatively large file size of print assets, it is easy to understand that the InDesign 1.0 concept of graphic “links” referred to graphics on local or network file systems, rather than remote web servers. While the web soon inspired features such as SVG and HTML export, it took some time before Adobe considered basing links on URLs rather than the tried and true file-based mechanisms familiar to Quark and PageMaker users since the 1980s.
As of 2013:
Box is a classic Silicon Valley success story, led by an iconic visionary with impressive insight into real-world problems. Founded in 2006 as a consumer offering for free file sharing, Box pivoted in 2007 to target the enterprise, right at the time that cloud-based storage became economically viable. Beyond the “freemium” model common with Dropbox and others in this space, Box served the enterprise market with a focus on security and compliance with standards such as HIPAA, along with fast-paced innovation supporting mobile and BYOD trends as they evolve. While other storage providers were aiming to replace FTP sites, Box was aiming to replace Microsoft SharePoint.
“Information velocity is going to transform how individuals work and how organizations operate. Over time, it will even revolutionize and modernize entire industries.” — Box CEO Aaron Levie
By extending their cloud storage service into an enterprise platform, Box has achieved astonishing growth. Current valuation of the company is on the order of $1 billion. With over 20 million users and 180,000+ enterprise implementations, Box reflects the global shift to a cloud future. Their vision is expressed in their rich developer ecosystem, and is bolstered by support for rich metadata, usually associated with a traditional DAM. Despite the absence of some features one would normally find in a DAM, the Box platform is rapidly becoming a popular place for corporate design groups to store images.
The continued growth of the web and the evolution of cloud-based storage lead Adobe to re-architect the linking model of InDesign under the hood, in order to support URL-based concepts. In 2008 the release of InDesign CS4 introduced a brand-new linking model. However, this model was not brought to the surface to make it directly accessible to end-users, but instead required significant development effort on the part of Adobe or third-party developers to actually connect to web-based assets. Adobe used this model internally to provide URL-based linking in support of their Buzzword and VersionCue products. Silicon Publishing, a software company specializing in extending Adobe InDesign and InDesign Server, created “Silicon Connector“, a plug-in enabling robust URL-based links to assets on generic web servers and specific DAM/storage platforms, in 2010. In 2013 this was updated specifically for the Box platform, and is known as Silicon Connector for Box.
Linking directly to cloud-based assets is a liberating experience for design shops used to collaborative authoring, especially in cases where designers do not share the same network. It is quite common for agencies and other organizations to work with freelance designers, and typically cumbersome to package all the related assets to an InDesign file. Consider the “before and after” of a workflow with generic InDesign and Box, on the left, vs. the incredible simplicity of a Silicon Connector for Box workflow on the right.
Without Silicon Connector for Box, the following steps are necessary to share an InDesign document between two or more users:
With Silicon Connector for Box, only the following steps are needed:
It should be fairly obvious, even to those non-designers who have never enjoyed hours of packaging, uploading, and re-linking assets, and those non-coders who haven’t written scripts and set up automated processes to re-link, validate that assets are available, etc., that the linked approach to cloud-based assets is the only sensible approach. Demand for Silicon Connector has increased proportionally with the growth of cloud-based asset management among InDesign users, as the availability of a single, secure, central source of assets saves huge amounts of time, while dramatically reducing redundant assets and the consequent risk of error.
Connecting InDesign with Box assets properly requires Silicon Connector for Box, available from Silicon Publishing. With this simple plug-in, users can work with pure and persistent references to their assets in the Box cloud, without moving any of these assets around.
Silicon Connector for Box enables access to Box assets directly from within InDesign. When you drag and drop the asset into the document, a secure http link to the Box repository is established. When you exchange your files with others that have access to the same assets, you can simply exchange InDesign files without packaging assets. You can, alternately, package assets in the old fashioned way, in which case your box assets are downloaded and added to a complete package on the local file system. In most corporate design groups using Box for asset storage, it would be rare to use the older method, yet it can be useful in creating a final archive or exchanging files with those that don’t have access to your Box assets.
Silicon Connector for Box also allows for generic drag and drop from unsecured assets on a web server, for example from wikimedia. Links to http-based or Box assets can also be associated or changed with simple scripts. Using such extensibility, it is possible to easily swap, for example, between high-resolution and low-resolution assets. You can try Silicon Connector for Box for free to see if a cloud-based design workflow makes sense for your organization.
I just attended Aaron Levie’s keynote here at BoxWorks 13. He announced four new offerings from Box:
I was struck how much this overlaps with work in our space, and in the space of Digital Asset Management (DAM) systems and even publishing solutions. Generally, as we’ve gotten to know Box in the past month, as we’ve created our Silicon Connector for Box product, I have been continually surprised how what first looked like a dumb file-storage application is tending to expand in functionality to do things that were traditionally the domain of specialized applications for document proofing, asset management, and content publishing.
We have seen companies grow with partners filling out the edges of functionality. For example, Microsoft used to give away Crystal Reports with their software development tools, enjoying a symbiotic relationship with their partner. In the process of growing, however, at one point Microsoft decided to offer their own reporting tools, and basically replaced their 3rd party offering with their own offering. Might Box do the same thing as they “grow 10X” (a popular phrase at this conference)?
If Box wants to “Grow 10x,” one thing it could do would be target the DAM market. Why not? Box is already providing 80% of the functionality of a DAM, and is adding features that increase this. In fact, we already encountered demand for Connector from Box clients that for better or worse decided it makes a good enough DAM for at least one part of their enterprise.
It is hard to read the plans of Box regarding this: they also do have DAM partners and cherish their 3rd party developers/partnership, and one theme of growth for them is growth by partnership. All I have heard officially is that they intend to continue to work with third parties: still it would almost seem inevitable that whether they market it as a DAM or round out the DAM features much further, the level of usage as a DAM will increase. Their new metadata features would be one great first step. Their predicted greater capability with thumbnails would also be very helpful. It is somewhat awkward, architecturally, for DAM companies to layer their technology on top of Box. It is rarely fun to try to synchronize two systems. There are alot of decisions, and the awkwardness of depending on an API that so far has exhibited a fairly rapid rate of change. However, no doubt it can be done. At least WebDAM and NetXposure have created Box integrations.
One notable thing at the conference was that as Box expands overseas, they face the same resistance to cloud storage that all cloud providers face, especially in the post-Snowden era. Between public perception of USA-based cloud storage and international regulations both for privacy and accountability to government reporting (it was pointed out that every country has the equivalent of a Patriot Act), it is not as trivial for Box to grow 10X internationally as it has been here. The fear of “cloud-only” leaves those DAMs that provide “host it yourself” options ripe for integrations that are less redundant than those attempted by purely SaaS-based DAMs. For a company such as NetXposure or MediaBeacon to integrate with Box, they could create a very intelligent hybrid option: cloud-only DAMs like WebDAM look more redundant as Box’s features round out. It will be interesting to see how Box interacts with partners in the publishing and asset management space, and where they draw the line over time between their product and the extensibility of their product by third parties.
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.
Box has grown to become one of the most popular places for enterprises to share assets on the web. As creatives often use Adobe InDesign, and an increasing number of creatives have their assets in Box, it is natural for those working in InDesign to want to use the assets in Box as referenced assets in InDesign documents.
Adobe InDesign was created before cloud computing was popular, however, and by default InDesign only works with file-based links, to assets available on the local file system or a network share. There is no default support from InDesign for links based on http or https, which would be the direct way to work with assets stored in Box.
In 2011, we at Silicon Publishing created a low-level InDesign plugin that does allow genuine http linking, and we released this as our Silicon Connector product, which we have successfully deployed with several cloud-based DAM systems such as MediaBeacon. We have recently updated this plugin to work with Box.
Consider the benefits of Silicon Connector for Box, by comparing first just the process of accessing Box assets from InDesign.
Consider the left and right sides of this picture:
Note that the default capabilities of InDesign force you to create a second copy of all assets linked to in your InDesign document. With Silicon Connector, each asset exists only in one place. So Silicon Connector improves efficiency: less disk space, no download time, no danger of confusion over asset versioning. This is a significant improvement.
However, the main headache that Silicon Connector eliminates is that of exchanging InDesign files that have referenced assets in the cloud.
Yet the main advantage of Silicon Connector is apparent when you begin to collaborate and wish to share files between designers.
Without Connector, you have the following steps to exchange files:
With Connector, the process is extremely simple. User 1 puts the InDesign file into Box, and User 2 downloads it and works with it. No redundant copies of the assets, no asset downloads, and no relinking. Box retains a single copy of the InDesign file and a single copy of each asset. While there may still be some use in creating a package, and Connector will let you create a snapshot package if you wish, any redundancy of content is something you choose consciously, it is not a limitation of the system.
We believe the Box version of Silicon Connector has great value to those enterprises using Box and Adobe InDesign. Contact us if you want a demonstration or to try it for yourself.
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.
We are putting more focus this year on Silicon Paginator, our product for flowing data and content through templates to print and other channels. This is becoming possible as our Silicon Designer product matures, and in many ways it is returning to the core sort of work that we set out to do when we started Silicon Publishing in the year 2000.
When Adobe InDesign Server was released in 2005, we were in the very first group of resellers, and our humble OEM offering was called the “XML Formatting Engine” – this codified techniques we had used for data-generated composition with InDesign Desktop, which had been our focus for the first 5 years of our existence, as we automated diverse document types including:
The XML Formatting Engine was a collection of modules that served as the starting point for custom automation solutions, flexible for a wide range of data sources and a wide range of document types. Yet we did not “productize” it to the point of a shrink-wrap sort of product, as we did not really see a “one size fits all” approach making sense across the breadth of what we did. We had tactics for output that ranged from the “mail merge” at one extreme, to structured document formatting at the other. One of the coolest things about the XML Formatting Engine was the mapping of XML and XHTML to InDesign styles, which we had kept improving in our automation of InDesign desktop from 2000-2005, when we were begging Adobe for an InDesign Server and building solutions that created wonderful output that then had to run overnight given the constraints of Adobe’s desktop mindset.
While the XML Formatting Engine was our first InDesign Server offering, it did not get the attention we expected and was not the greatest demand we encountered. We were surprised that the majority of those coming to us for InDesign Server solutions wanted… a web front end for online editing. We found ourselves doing this over and over, until a product, Silicon Designer, came into being. Our company grew in size quite a bit, thanks to the popularity of Silicon Designer, while the XML Formatting Engine work continued somewhat quietly. When we created Silicon Designer we re-named the XML Formatting Engine “Silicon Paginator” but did not invest heavily in extending its capabilities. Designer got the initial attention of the fantastic new developers who joined us at that time. It took a huge effort to extend Designer to meet the diverse needs of our clients while supporting the ever-changing web technology it has to work with.
As the InDesign composition side of Designer got more and more robust, however, we started to see real overlap between the products. We had already started from the same core tactic of InDesign output, so there was some basic commonality. In general, much of the tooling and API development of Designer was applicable directly or indirectly to the Paginator product:
We are building Silicon Paginator to support three main classes of document:
By leveraging common techniques and sharing code and object models between the two applications, we are extending Paginator with functionality we could only dream of before. We are able to connect it to our favorite asset management systems (MediaBeacon, Adobe CQ, and other places we take our Connector technology), and we are extending the multi-channel capability with Adobe DPS, ePub and HTML5 output. It is not the path we expected to follow, but we may end up being stronger in the long run from what we have been through to get here.
I am at the HTML5 Developers’ Conference in San Francisco. One of my friends said “it must feel like Christmas for you over there” and it actually does feel that way, not in the sense of “everything is easy now” but more in the sense of “our path forward is clear.” Like Christmas before a year-long war we know we will win.
Paul Irish spoke this morning about the various tools he’s using these days, or as of 10/16/12 (one gets the impression he’ll be adding a new one tomorrow), so certainly things are more mature in terms of the “tool chain” (in the old days we were waiting for “tools” to simply get plural, as text editors reigned supreme). Now we can say there are ToolS for HTML5. Cool.
Even more interesting to me than Paul’s talk was the talk by James Pearce on “Keeping the Dream Alive” – he had the good news and bad news about HTML5, which can be summarized by two parts of a single quote from Mark Zuckerberg…
“When I’m introspective about the last few years, I think the biggest mistake that we made as a company is betting too much on HTML5 as opposed to native. Because it just wasn’t there.”
When Facebook moved from HTML5 to iOS, they had stunning gains almost overnight.
The good (the part that has received less hype):
“It’s not that HTML5 is bad. I’m actually, long-term, really excited about it. One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us…”
Yes it is like Christmas for HTML5 geeks, finally our work is getting somewhere. It will be very interesting to see what happens over the next year. It is not easy to reconcile the formats required of modern devices, yet the range of required approaches is getting more clearly known and the tools keep evolving to make things easier.
Recently we have been working on some very exciting technology with Adobe, bringing together some technologies we’ve been working on for over a decade with one of their most recent technologies, the Digital Publishing Suite. We watched this technology develop over the past few years, and honestly had our reservations about the initial releases and apparent intentions of Adobe at the outset of this offering:
While point 1 remains valid: native apps are not always the ideal way to bring content to devices, it is still true that sometimes a native app is precisely the ideal way to provide content. Native applications may perform better, manage offline content with more power, and access a greater range of device capabilities. Also “app stores” are good and bad: bad in that they make distribution more costly, yet good in that they are often a great way to get users to find and reach your content.
Point 2 is no longer valid: things have changed substantively over the past two years. There have been dramatic improvements in the underpinning technology around DPS, with Adobe investing heavily in every dimension of the DPS solution: the “liquid layout” features of InDesign CS6 were created with DPS specifically in mind, and include technology that makes the content much more efficient than it was with the prototypical wired reader, which one senses had been built in a weekend when Adobe noticed that Flash wasn’t going on the iPad. Adobe has been contributing to CSS specifications and the WebKit project, they have core tech that is unrivaled if they really wish to make text work well on tablet devices, and their power is starting to show as DPS improves over time. As Chris Converse has brilliantly taught and demonstrated, there is now the capability in DPS to add fairly arbitrary HTML5 content. DPS’ value is proven out as devices proliferate and iPad competition looms on the horizon with an even larger distant silhouette each day.
Point 3 is no longer valid, either. While initially Adobe DPS aggressively pursued the magazine market with a fervor that would make Suge Knight proud, after they attained that market they did realize that other markets (particularly the new ones I will mention later) have more partner dependencies and are best built within an ecosystem, and extensibility is essential to the growth of DPS even in the magazine space. There are now fantastic APIs available to developers, which enable publishing workflows never before possible.
We at Silicon Publishing are now building InDesign Server-based DPS solutions of two types, which parallel our main two products:
In the catalog world, so many manufacturers and retailers produce print or print-like (some only distributed as PDF, but retaining the print design paradigm) content with Adobe InDesign Server that rendering a tablet application from the same process makes much sense, and it is easy to do thanks to the automation capability of InDesign (including most interactive features) as well as the packaging and deployment APIs of the Digital Publishing Suite.
In personal publishing, for example creating photobooks online, the process of output is largely identical, yet the possibilities even more stunning. Grandma makes a photobook online, and within an hour, can have iPad and Android versions of the photobook available to her family. Silicon Designer gives us a great platform from which to build out this functionality.
We are looking forward to sharing more about this in the coming months.
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: