Could Adobe Reflow be the future of design apps?

We all know that Photoshop and Fireworks are far from perfect for designing responsive websites, but what is the alternative?

A little over a week ago I asked the question on my blog “has responsive design killed Photoshop for web designers?

I suggested that graphical packages that require you to set a canvas size before you could start designing, were far from ideal in the world of responsive design.

The post caused a phenomenal response with 56 comments and a lot of attention from the likes of Smashing Magazine.

Photoshop: the best of bad options?

The overwhelming response in the comments was that although tools like Photoshop and Fireworks weren’t ideal, they were the best that we had.

Although designing in a browser has its place, the feeling was that we couldn’t do away entirely with graphics packages.

Obviously, we will still need graphics packages for producing imagery for our site. However, I cannot help feeling static comps are not what we should be presenting clients. That said, I do understand the concerns surrounding dropping graphics packages as our primary design tool.

Fortunately, it would appear that Adobe is aware of the shortcomings of its software and is working hard to offer us an alternative. This alternative is called Reflow.

Introducing Adobe Reflow

Adobe Reflow seems to be a hybrid of traditional graphics package and designing in the browser. Although its tools have a lot in common with Photoshop, the whole thing is rendered using CSS. The result is that when you create a box with rounded corners and drop shadows, this is actually being rendered as CSS in the background.

Screenshot of Reflow

Because the whole application is built on CSS, Reflow also supports the fluid nature of the web. You can even set breakpoints allowing you to change the layout for responsive sites.

The other advantage of Reflow is that you can select an element and look at the code associated with it. This makes it easy when it comes to coding your design. No doubt its code will be far from perfect. However, for things like colours, sizes and styling it will be really useful.

This ability to look at the code also offers another potential advantage, the chance for pure designers to learn code.

An educational tool too

I have just returned from HOW interactive in Washington DC. This conference is primarily aimed at print designers who are moving across to the web.

The one thing that shocked me was how reluctant many of these designers were to learn code. I am aware this can be a controversial area, but it strikes me as insane that a designer shouldn’t at least understand how websites are coded, even if they don’t produce final code.

Reflow code view

Reflow offers an opportunity for these designers to pick up some of the basics of coding. By allowing them to look at the code associated with their stylings, my hope is that they will see that coding CSS really isn’t that difficult.

Unfortunately, it could also lead to Dreamweaver style WYSIWYG code and that is dangerous.

My concerns

The only element of Reflow that does concern me is that it offers the ability to export code. This puts Reflow in the same league as Dreamweaver.

Although Dreamweaver is actually an excellent coding environment, its WYSIWYG editor has encouraged poor quality code and so tarnished its reputation.

The danger is that if Reflow produces less than perfect code (which lets face it any automated tool will do), this will have consequences:

  • It will lead to numerous poorly coded websites.
  • Many web designers will learn bad coding habits.
  • Skilled coders will reject the tool entirely, despite its many good points.

Of course I can understand Adobe’s decision to allow exporting of code. It allows them to reach a much greater audience. There are a lot of designers out there who want a WYSIWYG style tool. I just hope it doesn’t leave Reflow with the same kind of reputation Dreamweaver has in certain circles.

From my perspective Adobe Reflow is a useful looking tool and I cannot wait to get my hands on it and give it a proper test drive. For now we will have to be content with Adobe’s sneak peak and this presentation:

  • Exciting! I think this looks perfect at least for producing low/hi fidelity design prototypes. Precisely where you need code to show everything working in the browser, breakpoints and layout switches but not having the time or client commitment for production quality coding. Can’t wait to see this develop and get my hands on it.

    • That’s exactly what I’m hoping for out of this tool. I can’t wait! I’d still use Axure for my regular prototyping, testing, & documentation, but this’d be kick ass for determining breakpoints and seeing responsive behavior before committing to details.

  • I agree with the “any automated tool can produce less than desireable code” point but I think this can instead be used as a tool for quickly prototyping a responsive design, then once the client approves, it can be moved to a developer who can clean it up.

    I could see this tool being used for responsive wireframing as well. Just throw some boxes onto the canvas and go stretchy-town with it.

  • Thanks for the article. I’m a web designer that knows how to code HTML/CSS but not to the point where I could decipher between GOOD and BAD code (which probably means my code is BAD code). So Paul, let me ask you a question. How BAD is the code that Dreamweaver creates? Bad to the point where things don’t work? Or don’t work as well as they could? Is there any suspicion here that those moaning about the quality of the code are just trying to validate their own profession?

    • Dreamweaver doesn’t really output code that won’t work it just doesn’t know how to make the right decisions. It will create more tags than a front-end developer would create to obtain the same effect. It will use positioning instead of a natural flow to layout elements because, at the end of the day, it doesn’t know the intentions of the site and it’s only purpose is to create code that will look exactly like what was created in the WYSIWYG. Much of the code it outputs tends to be superfluous.

    • Debic

      I use DW all the time… I’m curious about the “bad” code issue too..

  • I think this could be a brilliant tool and will really encourage good responsive designs. Hopefully we can build a consensus that using this as an actual website building tool is a bad idea and a misuse of the software, if so I can see designers and developers swapping Reflow docs instead of PSD’s on a day to day basis.

  • Joel

    I’m actually quite excited about the ability to export code because although I’d never use this for a production site, it would be great to be able to export prototypes that clients can load or we could use for user testing, etc…

  • I think Google Chrome will end up developing a similar approach inside Inspector: you resize the browser window, mark a breakpoint, fix the CSS, and then Inspector gives you the media queries based on the CSS changes made in each breakpoint (if I know how to create Chrome extensions I would have created a tool for that already).
    It’s kinda obvious to me that Paul Irish or someone else will develop this, we need it.
    BUT, Reflow is different from this in one aspect: reflow give us the possibility of importing designs from apps like Fireworks. I don’t know what workflow would be that exactly. It’s all about the workflow.
    And it should be considered that the front end design workflow should be different whether we are making a marketing web site (which is about graphic design, and so it must start on graphic design thinking drag and drop apps, it’s kind of a virtual billboard) or whether we are making front and to a web/mobile app, which is all about function. It has been proven being more efficient starting right on code, right on functionality.
    I’m still struggling to figure out the perfect workflow for web design for marketing websites and front-end design for apps. Out software should be chosen (and created) around this ideal workflow. Otherwise, we will always be fighting against our software, instead of thinking about the design itself, the interface/graphic design problem we need to solve.

  • Arcat Vonguru

    We use a content management system named Centralpoint by
    Oxcyon. It has a module build in to design sites. Centralpoint separates design
    rules (or CSS style sheets) from the content itself to allow us to build a
    project that can be easily redesigned the next time around — without hindering
    the information inside. Not only can we easily manage your site’s designs
    (stress the plural version of design), but we also can equip you with the tools
    to easily manage your many pages within it.