Axure RP & Adaptive Views: are they worth it?

March 13, 2016

I’ve spent a lot of time in Axure RP recently building a custom widget library to assist a client’s internal UX team during wireframing and prototyping. The library includes over 50 widgets, as per those found in the companies online style guide.

To fit within the teams existing workflow, the client asked for the widgets to be built using Adaptive Views. Despite having used Axure many times before I’ve tended to steer clear of Adaptive Views for several reasons, not least because of the rolled eyes and mixed press it receives from colleagues of mine and the wider user-base online. When experimenting with the setup before, I’ve encountered strange bugs and unexplained behaviours, further reinforcing my beliefs. The following are the top three issues and frustrations I’ve found when working with Adaptive Views (in a .rplib library file) and, where appropriate, any workarounds/’fixes’ I’ve discovered. It’s also worth noting that, judging by the beta release, the following are not resolved in the upcoming Axure 8.

1. Grouping elements to build widgets

Unless a widget is a very simple element (e.g. a button), it will be made of numerous parts. A straightforward text and image widget, like the one illustrated below, is made up of an image placeholder, a h2 and body text.

Widget View (Mobile)

Basic text and image widget (mobile base view)

It just so happened that as part of the widget library I was building, we wanted to include a series of basic ‘text and image lockups’. Each one of these would look slightly different for the various screen sizes. The image below is a rough replica of how one of these widgets adapted across the different views.

Widget across AV's

Widget across Adaptive Views

A widget created and left as these individual parts appears to ‘pull apart’ when placed on the canvas and then moved, as illustrated in the video below.

One would assume the simple solution would be to group the parts of the widget so they stick together in the intended arrangement. However, this does not resolve the issue, as demonstrated in the video below.

The only solution I have found is to put the completed widget into a dynamic panel. Although this is a very straightforward process, it does introduce some minor implications for users of the library. Firstly there is the added time required to edit parts of a widget, such as the body text in our example, because the dynamic panel must be opened to make such an edit. It also means the opening of numerous tabs in Axure which can become very frustrating to work with, and may even start (eventually) to slow the program down.

 

2. ‘Styles’ are incompatible with Adaptive Views

Axure RP has a custom style editor which, in the words of one Axure Developer, is supposed to “give you a lot of the power of CSS without some of the mess”. To an extent this is true. Creating custom styles makes it quicker to make sweeping changes to a number of widgets in one go. Instead of having to go through each individual widget and change the font colour from, for example, black to red, make the amendment in the style editor once and it is applied to all instances of said widgets.

However, certain style properties cannot vary across adaptive views. For example, on the mobile adaptive view I would like my H1 style to have a font size of 29px. On tablet I want this same H1 style to display as 39px and on desktop as 44px. This is not possible with the existing implementation of custom styles in Axure. Instead you would have to create an unwieldy amount of styles to cover the different variants across adaptive views. Take my example above, and assume the same were true of all ‘H’ tags, I would need 18 styles: H1-6 x 3 (mobile, tablet, desktop)!

 

3. Organising layouts across each Adaptive View

This isn’t so much an issue with Axure or Adaptive Views, more an annoying side effect of the feature. Building a page on the mobile base view means all child views inherit the page content. Theoretically this sounds great. In practice the content is typically muddled up and overlapping on the child views. This means time is spent pulling the content apart to reorder it for the larger pages.

In an ideal world, Axure would intelligently recognise the priority of content/widgets on a page and keep this same order on the child views, whilst also adjusting the widget positions on the page to compensate for any dimension changes as the viewport increases or decreases. I’m not suggesting that this would or should mean responsive pages are automatically ‘designed’ by Axure, instead that content is ‘dumped’ on them in a more structured manner, thus making it easier to work with the pages.

One for the future… maybe?