Recently Axure Co Founder and Product Manager Victor Hsu, posted in the forums that version 7 is going to be delayed so that they can spend more time with new features for responsive prototyping. Unless the application is going to be a complete rewrite of ode and concepts I can’t see how this will ever work. I like many people driven by employers and clients to use Axure for create ‘wireframes’ have on several occasions made mobile and desktop versions of a prototype in Axure with limited degrees of success. The overal problem with a tool like Axure when it is put into the modern (although not that modern if you enjoy the rants of Jeremy Keith this week who reminded us that many people have always worked with fluid layouts, is that Axure is fixed width at its core.

When I first used Axure back in 2007, it gave my team and I an opportunity to reduce the time wasted writing detailed functional specifications and designing detailed screens for an application that already had a defined layout. It gave us the ability to focus on features and not to concern ourselves with the application chrome.

For us; a development team consisting of database/system admins, php developers, front-end developers and systems testers, it saved us huge amounts of time.

Providing we wrote detailed notes on widgets and pages, worked with variables and state changes with panels we were able to maintain a virtual copy of the live application in Axure that could be validated with the product owner, give the dev team the necessary information to write and build the new branch of the app and meant that our tester didn’t have to write as much for her test scripts because there was something to validate against.

And this is where I would like to leave Axure. It is a fantastic tool for prototyping applications. Semantics aside we all know there is a clear difference between what the general public may call a website, and an application. Websites are the things we lose hours on looking at cats and reading drivvel, applications are the things that you put something in and you get something out.

I don’t know what is going to be in Axure 7, but they have some competition on the horizon from the big boys namely Adobe.

This week I got to see the preview for Adobe Edge Reflow. Although Reflow is being promoted as a responsive web design tool, I see some major opportunities here for creating prototypes by the audience that Axure is aimed at – people are are not able to write code.

During the demonstration, Piotr Walczyszyn walked through creating a simple site layout; header, footer content blocks, using the graphical interface that allows you to drag divs across a column grid system which you can set up specifying number of grids, gutter size and what the total width wil be in percentages.

The interesting part of Reflow is when you start to look at what happens when you resize the canvas. Using some drag controls you can expand/contract the canvas until something starts to look rubbish and then add a breakpoint. From here you can adjust the elements on your layout repeating ad infinitum.

Just from the demo it is clear that you can visually put together acceptable site concepts. I do however have some gripes with Reflow.

During the demo, Piotr regularly switched between using pixels to set maximum sizes and percentages. For example, when setting a breakpoint for a background image after a certain width he set the max-width of the image using pixels, this was after the introduction explaining about flexible images as described ages ago by Richard Rutter.

Classic Adobe code bloat. Edge Reflow uses HTML5 Boilerplate at its foundation for your creations. A good start yes, but as with the majority of these starting frameworks it is known for having a lot of shit in it you’re unlikely to ever use. The example html file created during the demo saw all the tell tale signs of html generated by an Adobe product. Every single div on the page had a derogatory id tag. box1,box2,box3,box4,img1,img2,img3,img and so on and so on. if that wasn’t bad enough, every image was given the class image. Stating the bloody obvious?

All your CSS is added to a reflow.css file and is normalised with boilerplate – not that it can be making an huge wins because as with the html the reflow.css is huge and contains a great deal of repetition (it has to when #box1,#box2, #box99999999999 are most likely going to be identical.

Finally, and I am sure this is just going to be in beta…… the generated code only works in Chrome. in fact, they have even gone to the lengths of putting a disclaimer into your page code for you so that on body load if the browser is not Chrome, it will instead show an annoying text block:

Preview HTML generated by Reflow is meant to be viewed in Google Chrome and may not display correctly in other browsers.

Now I wonder why they’ve done that?

Even with all of this said, I don’t think you should discredit the possibilities for Adobe Edge Reflow which is now in the preview on Cloud and you can download it now. It could become a great tool for responsive site prototyping and quickly learning where issues in the layout are going to arise without the need for knowing the code behind it.