When I started to develop for the web in the mid-nineties there were virtually no web designers. Instead it was left to developers to both design and build websites. Many of my first projects were designed using a collection of basic free tools courtesy of net Magazine and coded using SimpleText. When I took my first full time position at one of the early London web agencies I got my hands on Photoshop. Looking back it’s curious that I learned to use Photoshop before I did Visual Studio.

As the internet took off more professional designers began to start working on websites. In those early days designers knew nothing about the web. They had often never even used it. And so began the transition from tiled backgrounds and animated horizontal rules to homepages consisting of a single intro animation. The world of traditional print design grappled with the new world of the internet. From a design perspective we’ve come a long way.

The perilous path from PSD to HTML

Creatives and geeks were never ideal bedfellows and there was friction from the beginning. Many times a website would be designed that simply could not be delivered due to the limitations in HTML. There was no Cascading Style Sheets (CSS) back then and limited support for JavaScript. Developers would curse their design counterparts for ludicrous creative solutions (no way was that layout going to fit into tables!) while they in turn berated us for the ridiculous limitations we placed on their creativity.

The biggest challenge of all was how a design would get from Photoshop to the web browser. The most common workflow was that designers supplied the Photoshop file (PSD) which developers then had to open up in Photoshop and extract sliced images, colours and so on. The result was very often (let’s be honest, always) not what was originally designed. The inevitable brawl would ensue. Never has open plan work places been such a bad idea.

As the years passed I was fortunate to work with a few designers who understood how web pages were coded. Some began providing designs in working HTML/CSS and even JavaScript. My job was then to do what I knew best: to wire-up backend code that dealt with the “databasey” bit. I was lucky. For the overwhelming majority of developers they must still crack open Photoshop and start slicing and dicing amongst the million unorganised layers of the design’s evolution. The initial output is still not what is originally intended and the frostiness between the two camps remains.

Vendors have tried and failed with the designer developer workflow

Different vendors have tried to resolve this problem. A few years ago Adobe and Microsoft fought a tooling war over this very issue. Microsoft gave designers the Expression suite, which worked well with their developer tool Visual Studio. Meanwhile Adobe created Flash Catalyst for designers and Flash Builder for developers. Each company offered tools for both sides that could share a common design/codebase. Both failed dismally. Primarily because they expected one side or the other to adopt a new tool rather than use the one they wanted.

Expression was very good, even some anti-Microsoft designers would admit it. But it only worked on Windows and designers have pledged their eternal souls to Apple. Adobe’s solution only worked for applications based on the Flash platform. While they could have grabbed a sizeable chunk of the non-Microsoft dev community off the back of RIA, Flash was already waning. Very soon after Catalyst was scrapped and Adobe decided to go “all in” on HTML5.

And that’s where we are today, with HTML5 as the common technology spanning desktop, tablet and phone. Proprietary frameworks like Flash and Silverlight have also gone in favour of open standards in HTML, CSS and JavaScript. At the same time Adobe has been moving its product catalogue to the cloud. A couple of years ago they launched Creative Cloud, a subscription model by which customers would access tools like Photoshop, Illustrator and InDesign.

At the 2014 Adobe Max conference, Creative Cloud moved farther beyond being a software distribution mechanism to a platform in its own right with a number of new services. One of those new services is Creative Cloud Extract.

A bridge between two worlds

Extract is a browser based service that allows a developer to view a Photoshop file without having Photoshop (or any Adobe software) installed. More than that Extract allows the developer to access images that are already cut and optimised for use. They can even simply cut and paste blocks of CSS code that provides all of the styling, positioning and other info that they need. No more awkward use of the rulers to figure out how far one image is from another. Extract will even provide CSS that includes fonts referenced from cloud foundries. An enormous amount of the pain of migrating a design in Photoshop to working code is now gone. Good to see is that the organisation and naming of layers in the PSD file is not as critical as it was with Flash Catalyst.

And it gets better. With the release of the very first version of Brackets, Adobe’s new lightweight code editor, users get Extract built in (something they have also done with Dreamweaver, Adobe’s well known web development tool). Developers do not even have to go to a separate online service. Imagine if this capability were integrated into other popular development tools such as Visual Studio or Eclipse? Instead of being a replacement tool, Extract can be a service that bridges the tools that designers and developers each prefer to use.

We can dare to dream with Extract

Extract is not yet perfect and there are challenges ahead. The current version is quirky and the user experience differs between the browser, Dreamweaver and Brackets implementations with the browser offering the most features. There is support for some CSS pre-processors which is interesting to see. However, a lot of people are starting to use specific frameworks such as Bootstrap or Foundation and Adobe should look to support these in both the design and code ends of the workflow.

While HTML5 is the technology du jour a lot of development is happening in the native mobile environments. Perhaps Extract could provide style data that can be used for Android or iOS development? Then there is application lifecycle management. Development is not a onetime process: applications evolve and designs change. That means developers need to reflect those design changes in their code. Extract needs to support the iterative over time process.

There is also more to the relationship between design and development than just a PSD file and code. In an era of Agile and DevOps there is constant user feedback which needs to merge new design with a growing functional backlog. This needs to be managed within a process that involves numerous stakeholders. Adobe could look to new design collaboration platform tools such as InVision (they are apparently a customer) for inspiration. Design is not flat but there is interactivity such as through transitions and animations that must be expressed to developers and enabled through code.

Even so, for many designers and developers working in digital agencies and other environments Extract will be manna from heaven. I know that if my day job still involved booting up Photoshop and delving into the mysteries of a PSD file, Extract would be a thing of dreams. The biggest challenge Adobe faces now is making sure that people know about Extract, even amongst their own customer base. But then this is a problem that’s never been easy to solve.