Setting up Adaptive Views



Setting up Adaptive Views

Adaptive Views define the breakpoints where you want your pages to switch to a different layout or style.

To create your views, click on the Adaptive Views icon at the very left of the tabs above the wireframe pane, or select Project > Adaptive Views.

In the Adaptive Views dialog, you can set up your adaptive views using presets (i.e. Landscape Phone, Desktop, etc.) or enter your own values.

Presets: typical views with preconfigured device widths

Name: a label for the view

Condition: whether the view will be shown if the browser width is less than or greater than a specified width and/or height

Width: browser width (blank means the browser can be any width for this view)

Height: browser height (blank means the browser can be an height for this view)

Inherit from: specifies the ‘parent’ of this view (more on this below)

What does Inherit do?
The location, size, style, and interaction styles of a widget can vary across adaptive views. Properties like text, interactions, disabled by default are not adaptive and are the same for a widget across all views.

A widget in an adaptive view inherits its location, size, and style from its location, size, and style in the parent view. If you make a rectangle blue in the parent view, it will be blue in the child view. If you make it blue in the child view, it will not affect the parent view. If you make it red in the child view, and then blue in the parent view, the child will stay red because you’ve already “overridden” it in that view.

The views in the adaptive toolbar are ordered by inheritance.

In this screenshot, 320 inherits from 768, and 768 inherits from the base.

What is Base?
The Base view is the default view for your project. Every other view will be a child, grandchild, etc. of the Base view. Generally, you will start designing your project in the Base view and then adjust the widgets as needed in the child views.

In the example above, the 768 view was defined to be shown when the browser width is less than or equal to 768. That means that the Base view will be shown any time the browser width is greater than 768.

So if you’re starting Desktop first…
You’re likely to create views that inherit from each other as they get smaller. (As seen in example attached below)

If you’re starting Mobile first…
Your Base view would be designed for the phone and the views would inherit from each other as they got bigger.

If you are starting from somewhere in the middle, like a tablet view, you can create two inheritance chains. One chain that goes up, and another goes down. Each time you create a view that inherits from the Base view, it will create a new inheritance chain.

Preview Example

Next: Editing your Adaptive Views
adaptive-example.rp (50.8 KB)

MobileFirst.rp (49.4 KB)


Hi! Do you have an example of this in action yet? Would love to see how it’s “supposed” to work.


I’ve attached an example on the original post of Desktop as the base, with tablet and phone as child views.


Hi Paul,

Is there a way to ‘reset’ the location, size, style, and interaction styles of a widget on one breakpoint, or even reset for all breakpoints? That would be helpful :slight_smile:



The adaptive features are cool, but Im trying to set something up that works similarly to Bootstrap/CSS media queries and it isnt quite working.

It would be good if you could set multiple triggers for a breakpoint, rather than just one. (ie bigger than 768 but smaller than 980)

In the attached rp file from the OP, you can resize a window so its smaller than the available content, as the breakpoint wont trigger until a specific width is reached, rather than a range.

It makes it a little finicky, as you have to get the window width exactly right to trigger a breakpoint without truncating anything.


Ive managed to emulate Bootstrap behaviour, sort of

adaptive-example_v2.rp (49.2 KB)

The only issue is Ive had to change the trigger values - tablet now kicks in below 979 px, and mobile kicks in below 767px. Because the adaptive views are named according to pixel values, it makes it a tad confusing. The other minor issue is it puts guidelines at the specified pixel value and cant be changed.


Nice work on the v2 of the adaptive example - this is exactly how I would want it to work. Showing this to my colleagues now!



In my workflow, I am using the ‘Print All Pages’ function regularly*.
Now using Adaptive Views (testing with Axure’s example file) I found:
(a) only one view goes to the print (file);
(b) and it looks quite coincidentally which page goes to the print - as I tested with Axure’s example file, I found the current (-ly visual) file in the print, and that makes me even more curious what will happen when I have more pages to print.
I had a quick look in the “Generate Specification…”-route and it looked (first glance) if this issue also exists here.

My questions now:
(1) Do I oversee something?
(2) If not, are you (Axure guys) aware of this issue?
(3) And if so, can we expect a solution soon?

Please let me know.



  • I don’t produce my specs documentation not via the “Generate Specification…”-route but via ‘Print All Pages’, where I create a PDF document. Annotations are made on every Axure page - which I can easily hide on screen when I demo.


Thanks for the example Paul. When I re-size the browser the content is cut, as shown in the attached capture (the grey rectangle is cut). Paj shared a version where that behavior has been “curated”. Is that a bug o a Views settings issue?

Thanks again. I’m sure all the UX community is glad Axure is adding responsive design to its already amazing product.


Hi Clau - If you resize down to 320, it will resize, but only if you have the sitemap open. I ran into what you’re seeing, I think it’s a browser issue. I will look into it further, I’m not really sure if there’s anything we can do with regards to it.


Hey Paul,
thanks for this new great feature. I can’t download this adaptive-example. There is an error occured. Can you help me please?


Wondering about the jumping around that I see when you slide the browser corner from the larger width to a tablet width. On the larger width there is a scroll bar but in the tablet width no scroll bar is needed. When the browser crosses over the break point there is a lot of jumping back and forth between the views. Check out this responsive proto I did: Untitled Document


@ davidevans - would you be willing to share your .rp file from your responsive prototype? -> Untitled Document

I’m curious, did you start with mobile view as the Base? Also curious how you did the slide-in nav menu. Very cool!

unlisted #13