Sitting around a table in Hamburg with three German Axure trainers from Ax-Stream, our three-day mission was to design a new Axure training course focusing on Responsive Web Design (RWD) using Axure 7’s adaptive features. Our goal was to produce an initial course design that we could pilot test with our other Axure trainers across Europe. More on that later!
We were working with an early beta version of Axure 7. Axure had asked us to review their new adaptive features and provide feedback regarding necessary improvements for its final release. In my prior discussions with Axure CEO, Victor Hsu, he had briefed me that Axure 7 would better address adaptive Web design than full RWD. For example, in keeping with earlier versions of Axure, there would be no support for liquid layouts, specifying positions and dimensions of Axure’s widgets—what some might call screen objects or components—using percentage values, or dynamic reflowing of text within widgets as the parent window gets resized.
However, despite these limitations and the fact that we working with an early beta version of Axure 7, our first and universal response upon trying the new adaptive features was amazement at how powerful and comprehensive they were.
Axure’s basic construct has always been pages within a site map. Masters are another fundamental feature of Axure. These are components that you can reuse both within and across pages, making it easy to make global changes and maintain consistency in your interface designs. For example, if you have the same header on all of your pages, you can update all of them at once—and that’s just scratching the surface of this powerful, yet very easy to use feature of Axure. Now, in Axure 7, both pages and masters can be adaptive.
There are two key and interrelated aspects of Axure 7’s adaptive features: breakpoints and the inheritance hierarchy, in common parlance. In Axure, these are just elements of the Adaptive Views manager, which is shown in Figure 1.
You can create a different version of each page and master for each breakpoint, or adaptive view. As Figure 1 shows, you can map particular views to different viewport sizes by setting breakpoints within the Adaptive Views manager. You can specify either or both the width and height of an adaptive view.
Figures 2 and 3 show two different adaptive views of the same page. The view, or breakpoint, shown in Figure 3 is for a viewport with a width of 1024 pixels or greater.
While the parent window would typically be a browser window, it could also be an iFrame into which the page loads. We often use this technique at Ax-Stream to simulate the way pages would appear on different devices—for example, tablets or smartphones—when viewing them within a PC browser.
The Inheritance Hierarchy
Once you start working with adaptive views, Axure automatically designates the current versions of your pages and masters as belonging to the Base view, which you can neither delete nor rename. Indeed, the Base view does not even appear in the list of views in the Adaptive Views manager. However, for the next view that you create, you can specify its name and one or more breakpoints that should trigger the display of that view. Your new view is a child of the Base view, so inherits from it. For example, Figure 4 shows the relationship of my new GalaxyS4/5(L) view to the Base view.
In your new view, you can move, resize, reformat, or delete any widgets that it has inherited from the Base view. Of course, you can also add completely new ones.
You can then create a third view that you can specify as inheriting either directly from the Base view or any other existing view, as shown in Figure 5.
In creating more new views, you can continue the process of setting up an inheritance hierarchy of parent-child relationships for your design. This hierarchy is visible in two ways:
Within the Adaptive View manager, as shown in Figures 1–3 and 5
On a ribbon that appears above Axure’s page-design area whenever the adaptive features are in use, as shown in Figure 6
The inheritance hierarchy is a very powerful feature of Axure’s adaptive views because any changes that you make to a view automatically propagate to all of its children and other descendants in the inheritance hierarchy. For example, Figures 7 and 8 show how a change to the formatting of the navbar in the Base view automatically updates the formatting in a 1024-pixel-wide view. Axure allows you to easily—perhaps too easily!—make changes that affect every view in the hierarchy.
Axure’s Adaptive Features
In general, Axure’s implementation of these adaptive features is well conceived. In the right hands, they’re a powerful addition to this excellent tool. However, there are some issues.
Notes Are Not Adaptive
Prior to version 7, Axure already had a pretty good notes feature for documenting both individual widgets and whole pages, including masters. However, notes are not adaptive. The same documentation applies whatever view of a page you’re displaying. Some users may consider this a limitation, but there are some workarounds for this issue.
Performance Suffers for Complex Pages with Many Breakpoints
When page designs have become reasonably complex—for example, when you’re modeling lots of interactivity—Axure’s performance slows once you get to four or five adaptive views. However, as Axure continues optimizing their product, we can hope that performance may improve. (We have already seen significant improvements over the beta version.) In my experience, four or five adaptive views would be enough for many, if not most, projects—particularly because Axure can globally scale views to a viewport’s width or height. Thus, a single view can suffice for devices that have similar sizes and the same aspect ratio.
The Ribbon Is Challenging for Some Users
The ribbon, shown in Figure 5, communicates three key piece of information:
The entire inheritance hierarchy
The view that is currently selected
The views that any edits you’re making will affect
When we ran the pilot course for our other Axure trainers, there was initially significant confusion relating to the use of the ribbon—and people consequently made quite a few mistakes. I’m sure this was partly because the whole concept of managing an inheritance hierarchy would be challenging for many, perhaps most UX professionals—in contrast to architects and coders of modern object-oriented systems, who live and breathe inheritance. But I think there’s room for some improvement in the user interface here. If you agree, I suggest that you provide feedback on the Axure forum.)
Axure 7 Provides Layers of Complexity
Any good UX professional is familiar with Ben Shneiderman’s observation that, as the flexibility and comprehensiveness of a software product increases, this necessitates increased complexity in the product’s user interface and results in a consequent reduction in its usability. Of course, Axure has not escaped this completely, but as with many other new features of Axure 7, the adaptive features are cleverly layered onto the existing functionality in such a way that many users may not even be aware that they exist. Thus, users who are not creating adaptive or responsive Web designs can carry on using the software in pretty much the same way they used Axure 6.
In implementing these adaptive features, Axure has certainly done no harm. As to any benefits, there are a number of issues to consider. Of course, these features are beneficial only when you’re modeling adaptive and responsive user interfaces, which is often not a requirement. However, it seems that adaptive and responsive Web design will be important for the foreseeable future, so these features add significant value for UX designers.
As I mentioned earlier, Axure 7 cannot model all of the features of fully responsive user interfaces—for example, dynamic scaling and text reflowing—so it’s certainly better suited to adaptive user interface design. This is clearly a limitation, but you can generally address the responsive features that Axure cannot model through documentation, using its notes feature.
To a certain extent, there are some competing features within Axure 7 for addressing adaptive and responsive Web design. It is possible to model an adaptive user interface design without using Axure’s Adaptive View manager by producing a completely separate page for each breakpoint. If necessary, you can then model adaptive behaviors using Axure 7’s new window events. In this case, you can use masters to advantage in modeling elements that are common to multiple breakpoints.
A benefit of this multi-page approach is that it overcomes a limitation of Adaptive Views that I mentioned earlier: it allows you to create documentation that is specific to each version of a page, using notes. Plus, this approach lets users avoid having to deal with the inheritance hierarchy.
More primitive variations of this approach to modeling adaptive and responsive Web designs have been in wide use for previous versions of Axure, making this approach attractive to many existing Axure users. The argument for this approach strengthens when there are great differences in the page designs for the different breakpoints, as is often the case. (For example, think about the differences between the smartphone and desktop versions of Google.)
Nevertheless, having an integrated way of managing breakpoints from a single location in Axure 7 provides a very elegant solution for modeling adaptive and responsive Web designs.
So, was adding these adaptive features to Axure 7 worthwhile? I think the jury is still out on this, but the answer is likely yes. During the numerous courses on RWD that Ax-Stream has conducted since that pilot, we have discovered a couple of key things: First, users benefit greatly from receiving coaching on how Axure’s adaptive features work—in particular, the inheritance hierarchy. Second, once they’ve grasped these concepts, many have a Eureka moment. They see the power of these features and immediately start to imagine their many applications. A common example is the ability to quickly show how adaptive or responsive Web designs work during an initial pitch or a demonstration of a scenario in a Lean UX context.
Want to Learn More?
Ax-stream is making the following approved Axure training courses available to the public:
Oslo, February 13: A Master Class in Axure
London, UK, February 23: Axure Essentials
London, UK, February 24: Axure Advanced
London, UK, February 25: Axure for Mobile Apps and Responsive Web Design (RWD)
Ritch has worked in UX design since 1995. He has a BA with Honours in Creative Design, an MSc with Distinction in IT-Computing, and a PhD in Human-Computer Interaction (HCI) from Loughborough University’s HUSAT (HUman Sciences and Advanced Technology) Institute. Ritch has lectured at the Masters level in five countries—on user-centered design, UX design, usability engineering, IT strategy, business analysis, and IT development methodology. He also has numerous internationally recognized qualifications in IT-related training and education. He has published many HCI articles and was on the editorial team for the Encyclopedia of HCI (2007). Ritch has led major UX design and user-centered design projects at Bank of America, Vodafone, Thomson-Reuters, and Dell Computers. His international experience spans 15 countries. Ritch presently heads Ax-Stream, an approved Axure training partner. His work currently encompasses Axure training, advanced Axure prototyping, usability and acceptability testing of early conceptual prototypes, coaching and mentoring of senior UX designers, and strategic UX work—integrating UX design and user-centered design into agile development methods and moving organizations from second and third generation to fourth generation prototyping methods. Read More