As part of my training for the Axure support desk, I decided to see just how close I could get to responsive design in Axure RP. To do this, I took my Patagonia-inspired adaptive design and figured out how to hack in some responsive-like behaviors in order to capture a touch of that great window-hugging fluidity--check out the link below. I accomplished this using one of the unsung heros of Axure RP’s Page Interactions, OnWindowResize. I wouldn’t exactly recommend this technique, as it introduces a lot of extra work and adds extra overhead to the prototype’s performance, but in small doses it could be used very effectively to add some of that whiz-bang factor that we all know and love.
If you're interested, check out my .rp file at the bottom of this post as you follow along!
To start with, let’s look at the Patagonia breakpoint chain. Between 1025 and 1200 pixels, all of the interface elements are fully revealed. Between 981 and 1024 pixels, the search bar turns into a magnifying glass. Between 768 and 980, the search bar returns but several other items are compressed into a hamburger menu. At 767 and under, the design switches to a mobile-oriented version.
There’s one additional breakpoint, which is everything over 1200. Nothing is added, and certainly nothing is compressed. But the left portion of the header stays to the left, the right portion stays to the right, and the search bar expands to fill the space. I could have put the right-side items in a dynamic panel and pin it to the right, but that’s not all that flexible (for example, a pinned widget won’t scroll without extra work). Instead, I used the OnWindowResize event, which is also triggered when the page first loads, to move them dynamically. Written in plain English, that means I moved the object “RightSideNav” to a coordinate equal to the width of the window minus the width of RightSideNav. Or, in Axure RP-speak:
Move RightSideNav to ([[Window.width - LVAR1.width]]), where LVAR1 is defined as RightSideNav
Now, my right-side navigation items stay pinned to the right side of the window. The moving search bar is a little trickier. In my design, the actual search bar is contained in a larger dynamic panel that fills the gap between the left-side and right-side navigation. To keep that larger dynamic panel sized properly, I set it to the width of the window minus the width of LeftSideNav and minus the width of RightSideNav. Then, I moved the actual search bar to the width of the dynamic panel minus the width of the search bar, all divided by 2. The search bar is 356 pixels wide, so if the dynamic panel is 400 pixels wide it’ll be moved to 22 pixels ((400-356)/2).
Similar math will allow the rest of the interface to fluidly move around as the window is resized, such as keeping the magnifying glass centered in the 981-1024 view. One tricky little thing I’ve done here is to handle the resizing of the search bar. At the time of writing, working in Axure RP 7.0, the only widget that can be resized is the dynamic panel. That means that the border around the search box won’t get resized the way I want in a responsive design. To get around this, I wrapped my search bar and surrounding border in a dynamic panel. When I reduce the horizontal size of that dynamic panel, the right border is cut off but everything else remains intact. To account for this, I made a small shim image to simulate the right border. This shim gets moved to the right edge of the containing dynamic panel whenever it’s resized to give the appearance of an intact box around my search bar—nifty!
Another handy trick that I used, once I got cookin’ with math, is to simply use one breakpoint for all screens under 768 pixels wide, meaning 767 or less. (That means I could have removed the 480 and 320 breakpoints entirely. However, because adaptive views are applied to the whole project and because in this example I wanted to be able to quickly toggle between the designs, I left them intact. Generally speaking, fewer adaptive views means less computing power needed.) The 768 breakpoint will still display on an iPad in portrait mode, but everything smaller will get one, consolidated design. To set this up, I expanded my 480 design out to 767. I needed a bit more trickery to make everything work, though, because this mobile-oriented design is all rectangle widgets with centered text that need to shrink or expand based on the window size. The first row of the interface, for example, has a “Men’s” button and a “Women’s” button. There are 35 pixels of space on either side of the row, and 10 pixels of space between the buttons. That 80 pixels of total space needs to be preserved. To get the buttons to both resize and have their text centered, I actually needed to encapsulate each button in two nested dynamic panels. The top level panel is the one that actually gets resized to the width of the window minus 80, all divided by 2. Then, the bottom level panel is the one that keeps the text centered by moving to the width of the top-level panel minus 335 (the initial width of the button), all divided by 2. This same math is then applied to all of the remaining interface elements.
Check out the responsive version of the prototype in action, and please see the .rp file attached at the bottom of the post.
I’ve built a handy toggle that switches between the adaptive and responsive sides. Notice that the responsive version has a bit of lag as you resize the browser window—the elements need a moment to catch up with the borders. There’s also the issue that if one single calculation is entered incorrectly in Axure RP, multiple components can break. In short, it’s hard to recommend this technique except in small doses. A little bit is pretty cool, but a lot of it can start to cause headaches.
Has anyone implemented anything like this? Have you had success in adding responsiveness to your prototypes? I’d love to hear your thoughts or questions about this!
ADAPTIVE-RESPONSIVE.rp (1.28 MB)