How To Create Mobile Prototype In Axure

The most useful tips and tricks to prototype mobile interfaces using Axure RP Pro.

Please note: this article was created in September 2013. The information is still valid for the most, but the new Online Axure Training course contains more detailed and up-to-date information. In this training course, I explain what are the rules to make mobile prototypes fit any devices, without creating a different version for each device. This was missing in the original article.

====

Because of the flexibility it offers compared to other tools, Axure RP Pro is still a top winner when it comes to mobile prototyping. Nevertheless, no matter how good you are at using Axure for prototypes that are supposed to run on desktop, projects for mobile devices require a rather different setup.

After spending many hours of testing on my own projects, I created a list of the most important aspects to take into consideration. As a reference, you can look at this rough demo project that I created to sum up my approach:

HTML prototype – desktop (Chrome recommended)

and here is the original .rp file that you can open in Axure:

Source file (Axure 6.5)

Source file (Axure 7)

The file contains explanations that are available as page notes, and have been also copied into the landing screen.If you want to view the prototype from your mobile device, after exporting to HTML, you must access the fileMobile_.html (the second page in the sitemap).

These are my recommendations, in a very condensed way.

Select 'Include viewport tag' option

Under the 'Generate prototype' settings in the 'mobile/device' section, there's an option to include the viewport tag in the header of the html pages that will be generated. This isessential to view the prototype correctly on your device, otherwise it will be scaled out of proportion and will not adapt to the viewport correctly.

The options available are quite intuitive to understand and you normally won't need to change any of them. You might want to set the value in pixels of the width and height of the viewport in the device that you are using, but I never noticed a meaningful difference when leaving the default 'device-width' value.

Customising the mobile prototyping options in the Export settings

You will have to design all screens using the actual pixel size of the viewport. For example,all screens in a prototype for the iPhone should be 320 pixels wide, unless you want to test it on iPhone 5 with retina display (is it worth?!), then you can create a prototype where screens are 640 pixels wide. In this last scenario, you will have to set theinitial scale to 0.5 (and can still view it on an iPhone which does not have retina display). Make ituser scalable if you want to allow pinch in and out to magnify content. The options tohide the address bar and browser nav are useful if you want to open the prototype from the home screen of your device, as a native app.

Keep "Prevent vertical page scrolling" option selected

Another option you can set before you generate the prototype is the one that allows to blocks elastic scrolling.This is to avoid the bouncing back and forth effect that you get when when holding and swiping fingers over the device screen. When this option is selected, the only way to include scrollable content is to place it inside adynamic panel with scroll bars enabled.

Don't assign a new page to each screen

If you want to simulate an app properly, your prototype must be responsive, especially if a usability testing session is planned. Because page refresh causes some delay, it'sbetter to use dynamic panels with multiple states, in order to switch from one screen to the other, at least when navigating through the main screens. If you get to a point where there's too many screens to manage them all on one page, ahybrid approach is possible where multiple pages are used but can contain several screens each.

In the files attached, you can see two different approaches being used for version 1 and version 2 of the 'Simple animation' and 'Sliding transition' sample screens.The better approach is in general to try to minimise the amount of dynamic panels, and using the same dynamic panel with multiple states for all those screens that have the same layout and behave in the same way. For example, you might have a dynamic panel for all screens with a docked header and scrollable content and another dynamic panel for overlays and alerts where content is not supposed to scroll.

Do not nest dynamic panels unless you really need to

Some people suggest using thewindowing technique (placing a dynamic panel inside another 'wrapper' dynamic panel) and applying drag animations to make the content scroll. This method increases the amount of dynamic panels needed, and it also requires workarounds to set drag boundaries at the top and bottom of the screen.Better to avoid it, unless you need to recreate specific effects such as horizontal scrolling/swiping within a vertically scrolling page (such as in the case of a carousel).

If you really need to use the windowing technique and you encounter problems with elements within the nested panel not being interactive any more (e.g. form elements), you can have a look at this post: Why can't I click my form fields on my fancy drag-to-scroll mobile interface?

Where docked panels can help

Docked panels are very handy when it comes to prototyping navigation bars and toolbars that are supposed to remain docked to the top/bottom of the screen, while the rest content is scrollable. It's not the only approach but so far I found it the most clean and flexible, albeit it adds an extra layer of complexity due to the presence of additional dynamic panels.Also note that in some cases you will have to disable the "Keep in front" option, for the transitions between screens to work properly.

Make sure screens are docked on top when they load

Using the dynamic panel-based approach to load new screens, when the user is scrolling the content down the fold and taps to load a new screen, the new screen is likely to be loaded with truncated content, due to the scrolled-down position. In order to avoid that, you can either: 1) make the dynamic panels dock to the top of the screen; 2)include a small text box on top of the screen, make it invisible by toggling the border, and then set the focus to it whenever a new screen opens; 3) place an image map on top of the page and scroll to it when a new screen opens (this is the approach that I used in the file attached, but I found it later that for some reason, it does not always work when the image map is external to the dynamic panel, therefore I would recommend option 2 instead).

Screen transitions with sliding animation

When viewed on a device browser, horizontal scrollbars are likely to appear if the dynamic panel is larger than the device viewport, even when the horizontal scrollbar is disabled (tested on iPhone 4 running on iOS6). You might also experience an unwanted bouncing of the screen content on accidental drag, revealing content of the adjacent screen. In order to avoid all that,do not juxtapose two screens side by side on the same dynamic panel, when you want to simulate a screen transition from left to right or viceversa.Use multiple overlapping dynamic panels instead, or even better, different states of the same panel, set to have the same width as the device viewport (e.g. 320 pixels on an iPhone). Here is a simple two minutes tutorial: Navigating your app with screen transitions

Use an inline frame to view the prototype from a desktop browser

You can create a prototype that can be either opened from a desktop browser or from a device. Just add a page containing the device body and a frame embedded in it.Remember toenable scrollbars in order to make pages scrollable within the frame. The dynamic panels should not be larger than the frame, otherwise horizontal scrollbars will appear even when not desired. Again, you should not juxtapose two screens on the same dynamic panel.Even when the dynamic panel is as large as the viewport,the horizontal scrollbar will unfortunately show up unless the width of the dynamic panel is further reduced in size. The good news is it's enough to reduce the panel width of one pixel (319 px in the case of the iPhone) for the scrollbar to disappear when viewed on Chrome or Safari (on a Mac, at least). Different story with Firefox (see below).Note: one more reason why you need to use a frame is that if you are usingdocked panels, theywill adapt to the frame borders same as they would to the device viewport.

Avoid Firefox to view from desktop

When tested on a Mac running OS X Lion,horizontal scrollbars do appear unless the dynamic panel is reduced to 302 pixels, 18 pixels less than the 320 px of the viewport! This is clearly too much compared to the 'one less pixel' approach on Chrome and Safari. In addition to that,scrollbars in Firefox are quite bulky and they do not disappear when not in use. For all these reasons, Firefox is not the ideal browser if you want to view a mobile prototype from a desktop browser. This is a shame as Firefox has been, so far, the best browser to support Axure prototypes, at least when it comes to re-exporting a single page and get an updated version of it.

How to see your updated prototypes from your device

Prototypes generated in Axure can be always accessed from a service like AxShare but that makes them load slower. There's several methods to load prototypes locally on your device in order to achieve more responsiveness and most of them are mentioned in these discussions:

Any ideas for viewing prototype offline on iPad?

Viewing prototype locally on the iPhone

A method that I prefer when it comes to showing the prototype internally to other stakeholders, is toset my computer as a web server and use the local network to share it with other computers/devices. This way, every time you update any page in your prototype, you just need to do it on your local machine and the device will access the latest version. It's pretty straightforward and even though you'd need to use Terminal if you are working on a Mac, you don't have to be knowledgable about shell scripting. I just followed this tutorial to do it on my Macbook Pro, running inn Mac OS X Lion, and it worked very well:

How to enable Web Sharing in OS X Mountain Lion

In order to view the prototype from the device, type in the browser URL:<your local host>/~<your short user name>to which you can obviously add any custom path to the file you want to be opened firstYour local host would be the IP address of your machine, that you can find under Settings > Network, if you are on a Mac. Ideally you should get a static IP so the URL will remain always the same.

Problems with cache

When exporting to my iPhone 4 and opening the prototype from the home screen, I occasionally run into a cache problem, so the prototype did not update any more on the device, even if it did before. There's no easy way to reset the cache of your iPhone home screen (and resetting Safari's cache does not solve the problem), so in these situations, the best thing to do is to rename the page in the prototype that is giving problems, so it will be exported as a brand new html file.

Include a nice QR shortcut

Let people open the prototype on your device by providing the URL as an easy-to-grab QR code that you can add wherever you want (including the desktop version of the prototype). You can easily find QR code generators by searching on Google.

Mobile usability testing: which tools to use

The best tool for usability testing on iOS (Android version to come at the date of writing) is Magitest. It's a 1 in 1 solution that uses the device camera, with no need to jailbreak it. You only need to install the app to record a session on the device browser, but they also provide an SDK so you can test a native app. A pro license costs $50, here is a review of the tool: Magitest – Screen recording App for iPhone. As an alternative, you can also consider UX recorder. I would not recommend other tools that make use of an external camera, such as Mr Tappy. This solution is intrusive for the users, and they look obsolete compared to Magitest and UX Recorder.

Libraries

There's plenty of Axure libraries out there, but my advice is toavoid those based on graphic images: create your own controls using the standard Axure widgets, if you can. This allows you to apply styles and update them globally across your prototype, as styles in Axure can (and should!) apply to custom widget libraries. This is very handy if, let's say you need to update the prototype from iOS6 to iOS7, or you start a new project with a different client and want to reuse the assets in your iOS library, and just apply a different look and feel.

Axure and community widget libraries: https://www.axure.com/download-widget-libraries

Detect device orientation changes

This can be achieved in Axure 6.5 using workarounds that are similar to those used for creating responsive designs. Here is a post from the Axure forum: Mobile Portrait/Landscape view

This will probably be easier to achieve in Axure 7, but in both cases, you will have to create a double version of any screen, one for portrait mode and one for landscape.My take on this is that unless you orientation change is the main focus of your prototype, you should rather prototype for just one orientation, so your working file won't turn into an impenetrable mess!

Fonts

Fonts have always been a problem since they would be displayed in the HTML prototype unless they were installed locally on the machine. In Axure7, this is going to change. You can use service like Google Fonts to download the fonts that you need and install them locally, but also include the webfont URL in your prototype so the font is always accessible to the viewer's browser. This short tutorial illustrates how to use web fonts: Web fonts and font mapping (as far as I know, the team at Axure is working hard to make it even easier, so by the time a stable release 7 is out, check out the forum).

If you are prototyping anAndroid app, you will need Roboto. ForiOS apps, Arial can be used as an alternative to Helvetica Neue (iOS system font, not available on Google Fonts). Or you can use explore other fonts, such as Arimo, that look similar. But be aware that until these issues are not completely resolved, the font might not be displayed correctly.If you are planning to create asketchy prototype using the font called Axure handwriting, you can use this URL: http://share.axure.com/fontCss?family=Axure%20Handwriting:r,b,bi,i

Don't forget you can also usefont icons!

Bug preventing scrolling on iOS6 (and iOS7?)

Dynamic panels positioned on top of active content and set to hidden should in theory not interfere with it, but because of a bug in iOS6 (not sure if it's going to be resolved soon with iOS7), it can happen that scrolling is prevented by a hidden dynamic panel sitting on top. This problem is OS wide and seems to affect all browsers, therefore the only solution right now is to send all hidden dynamic panels to back and make sure the active content lays on front.

Useful links

Axure for mobile, by Lennart Hennigs.Very good source of up-to-date articles, tips and recommendations. The author also wrote a book that can be very helpful if you need to learn how to use Axure on mobile from the basics and then gain professional knowledge, and contains several interesting hacks and workarounds. His work is very accurate and I'd recommend it.