Axure/Ubiquity

I find myself doing what I think might be an unhealthy amount of thinking about the tools I use to do stuff, and regular readers of this blog will know that one of my ambitions is to discover – or better still help to make – an Information Architecture IDE. So one of the things I’ve been meaning to blog about is the latest release of what was called Ubiquity RP, now Axure RP, by a company called Axure. Peter van Dijck published an interview on his blog with the creator, Victor Hsu, when the first version went golden. I had a look at that and corresponded with the creators about a few things. My verdict at that point was that it wasn’t ready for industrial use, and sure enough, the IA world hasn’t exactly buzzing about it. But version 3.0 shipped a couple of months ago – so is it a quantum leap or an incremental change?


In case you’ve not read my musings on this “perfect tool” business before, very broadly-speaking there are four areas of work that have to be done to design a site: the underlying IA (the big picture: personas, navigation, taxonomy, etc.); interaction design/page layout; content integration, and documentation. There are of course numerous other things that take place during a project but they break down in to roughly those four areas. And the really annoying thing about those areas is that they are all linked at various conceptual levels, and need to have ways of cross-referencing each other, but somehow never get linked in the way that they need to be. They therefore fragment, become outdated, or become too much work to maintain over time.

The fact that web development is so new also means that is there are still many ways to achieve the same ends and there are no generally accepted tools of the trade. In terms of tools for the job, there are some things (like Visio) that seem to get a look-in on most projects, but that’s about it. Contrast this to other industries like print publishing or television, where tools are not only much more mature but so are the environments they get used in. The occasional tectonic shift and passing fad stir things up from time to time, but they’re pretty stable otherwise.

Enter Axure, which the creators are positioning it as a prototyping tool. This means it lets you swiftly create HTML prototypes of your designs by using a nice template n’ modules system. You create what it calls “references” (but which I’ll call “modules” because that’s what I’m used to) which can be built out of “widgets” (what I call “elements” – links, checkboxes, form fields, etc.) and then applied to templates, which you can then apply to pages. You can also apply modules and elements directly to pages as well. Once you’ve done all that, you can get it to create an HTML prototype out of that and amaze your friends.

Big wow. I can name about 10 tools that do that. But wait…

Axure lets you annotate your references and pages. Not only that, it can spit out a Word document with those annotations neatly arranged below images of your pages and modules. You can get it to use a Word template to format this, and can choose your attributes for annotation. This is the germ of something really interesting and raises Axure above the general throng of RAD-style tools for the web. This interest is elevated further still when one considers that if you can create modules and pages underpinned by structured documentation, then it would be a small step to producing that as XML, and thence to data structures that could be used for providing an answer to the Second Great Problem: how to tie content to design. I have alluded somewhat vaguely in the past to this issue, and ways in which we have been approaching it, but it seems that if the makers of Axure realise that perhaps by accident they are sitting on the discovery I think they are, then they could easily beef up the tool for this purpose.

But it seems for the time being they are concentrating mostly on the prototyping aspect of things. This is fine to an extent, but they’ll get nowhere while they hide their structured metadata capabilities under the table. If we look at what they’ve got right now, there are several things for the next version that would be good to have:

  • Modules cannot be annotated at page level or have things inside them that work only at page level. This means you can’t create a “related links” module and show it with different links on page X and page Y (well, not that I could work out – maybe putting an element over the module?) Perhaps the introduction of the concept of a “dynamic” of “page level” layer on modules would be good.
  • The interface doesn’t scale very well for some things. For instance, modules need to be groupable – it’s common on some of our projects to have perhaps 50 or more modules. Managing them in one big list isn’t very easy.
  • Need to be able to annotate the component parts of modules separately. This is pretty important – the bits that make up a module need to be annotated, probably using an independent set of annotation fields from the module itself. Perhaps the introduction of a special “label element” would do this. It would be a numbered arrow that you could point to the relevant part and then fill out the desired annotations for.
  • Would be good to have some simple painting/drawing tools to use (lines, boxes, etc.)
  • Need the ability to create custom widgets (e.g. dividing lines, arrows, icons, etc.)
  • I wish “references” were called “modules” instead :-)

The next release promises group working capabilities and the ability to share modules between Axure project files. If that means that we can have centrally-maintained module libraries and more than one person working on the same project file than then things will really be hotting up.

I’ll be keeping an eye on Axure, and I think others should too.