Creating Responsive Prototypes With Adaptive Views In Axure RP 7

Advertisement

Responsive Web design has vexed people who build prototypes since the techniques came into use several years ago. While responsive design is an extremely elegant way to handle coding for multiple device types when executed with HTML and CSS, the prototyping tools available to UX professionals have not delivered testable or demonstrable experiences of the same quality. That changed recently with the adaptive views feature that is part of the new Axure RP 7.

Axure RP 7’s Adaptive Views

Creating responsive prototypes without writing code is now possible with Axure RP 7’s new adaptive views feature. The feature enables you to create one page in Axure RP with several “views.” The view displayed on a given device is determined by the width of the device’s screen.

The freedom from needing to know or even think about HTML during the prototyping process is a real benefit to UX designers. When you have to take technical aspects into account in the prototyping process, you could easily start filtering your design thinking. At some point, usually pretty early in most projects, technical capabilities and constraints will become a necessary part of the design process. But during the very early prototyping phases, you might benefit from more freedom to think about what interfaces, screen flows and interactions would solve problems best for users, and these exercises can even uncover questions about technical limitations that you might not have considered.

How Adaptive Views Work

Adaptive views are executed by first creating what Axure refers to as the “base view.” This is the view from which other views may, but don’t necessarily have to, derive. In a mobile-first design, your base view would be for a smartphone in portrait orientation. From this starting point, you would create views for progressively wider screens, such as smartphones in landscape orientation, tablets and desktops. I tend to prefer this approach when using adaptive views.

You could also take a desktop-first approach, starting with a wider screen and progressively working your way down to handheld devices. The benefit is that you would know all of the elements available to the largest screens in order to decide whether to remove or redesign them for progressively smaller screens. The approach you take will depend on the project you are working on and on the known or expected device usage patterns.

A Mobile-First Approach

For our sample website, a fictitious bike shop’s, we’ll use the mobile-first approach. When we’re done, we’ll have one home page with individual views for smartphones and tablets in both portrait and landscape orientations.

The first thing to do is create a new Axure RP file with a single page, which we have named “Bike Shop.” For smartphone views, we’ll target the iPhone 5’s screen, but the techniques shown can be applied to any device, regardless of screen size or operating system. I also like to add page guides to mark the boundaries of the screen and add internal margins. The page guides for the screen are placed at 320 pixels on the x axis and 568 on the y axis.

We’ll also add page guides at 10 pixels and 310 pixels on the x axis for margins, so that the page content doesn’t bump up against the left or right edge of the screen (where it would be obscured by some smartphone cases). For iOS Retina displays, the screen widths used in this article will automatically scale to the higher resolutions. The smaller sizes simply make our Axure RP files smaller and are often easier to work with when building a prototype.

Initial page for smartphone view
A single page is created with page guides to mark the edges of the screen and the left and right page margins. (Large preview1)

We are now ready to design the page that will become the base view. The first thing we’ll do is create a simple header, consisting of a colored bar with some text for the bike shop’s name. Once the header is created, right-click it and select “Convert to Master” from the context menu. Once you’ve named and saved the header, it will be added to the Masters panel at the bottom of the left column in the workspace. In Axure RP, a master is a component that is designed in one place but can reused on every page of the prototype.

The Convert to Master dialog
Using the “Convert to Master” dialog, you can name the master and specify the behavior to occur when it is dropped on any page in the project. (Large preview2)

Add some more interface elements to the page and you’ll have designed a basic page for a smartphone in portrait orientation. Now we’ll create the different views that give this feature its power.

The project base view
The base view of our project is now complete. (Large preview3)

Creating A New View

To create views, open the “Adaptive Views” dialog by clicking the button to the left of the tabs for our Axure RP pages (outlined in red in the screenshot below).

The button to open the Adaptive Views dialog
The button to open the Adaptive Views dialog. (Large preview4)

Using adaptive views is fairly straightforward:

  1. Click the green “+” icon in the top left of the dialog (shown below) to add a new view.
  2. Name the view — “Phone Landscape” in this example.
  3. From the two available, select a condition to trigger the new view to be displayed: “is greater than or equals” or “is less than or equals” a set width.
  4. Finally, add the numeric value for the screen width that will trigger the view.

Adaptive views dialog
The completed Adaptive Views dialog for the first child view. (Large preview5)

With that done, a second view, named “Phone Landscape,” will be triggered to appear anytime the screen is greater than or equal to 321 pixels. Because we are targeting the iPhone 5 for our handheld views, this view will appear if the person tilts their phone to landscape orientation. Otherwise, the base view will appear (and the base view will appear on Retina iPhones in portrait orientation, even though the actual width of the device’s screen is 640 pixels). Our new view also will appear for tablets and desktops until we add views specifically for them.

By default, any new view inherits from the previous view — in this case, from the base view (the only other one available). As we add more views to a page, we can have them inherit from any other view that we want to use as a starting point.

The screenshot below shows our two views, base and 321. Axure RP automatically sets the name of the view according to the width that you specified when creating it. The 321 tab is blue because it is the active view. The purple guide on the right is at 321 pixels on the x axis to indicate the breakpoint.

A new view has been created
The content and layout of the new view are the same as their parent at first. This will change as the project progresses. (Large preview6)

Inheritance

The concept of inheritance is key to understanding how to effectively use adaptive views. Here are some key concepts to know:

  • A new view is an exact copy of its parent. This frees us from having to recreate widgets to appear in more than one view.
  • If we were to change the text in the main headline in the base view, it would be updated on any direct or indirect child screens all the way down the inheritance chain.
  • Inheritance passes only from parent to child, not the other way. So, changes made in a child view are not passed back up to parent views.
  • Widgets in adaptive views inherit location, size and style from the location, size and style of the parent view. If we increased the size of text in a child view, it would not affect the parent view. But if we go back to the base view after making this change and make the text size of the main headline smaller, that wouldn’t affect the changed child view because the new text size in the child view would already be overriding it.

Before you modify the design for phones in landscape orientation, place new page guides for the edges of the screen. The page guides for the phone landscape view are at 568 pixels on the x axis and 320 on the y axis.

Adaptive Masters

We’ll start designing for phones in landscape orientation by updating the header master for the wider screen. Masters in Axure RP 7 are adaptive, just like pages, and they automatically inherit the breakpoints from regular pages.

In the screenshot below, you can see that we’ve added a page guide and extended the length of the header background to 568 pixels.

Adaptive masters inherit breakpoints from other pages
Masters inherit the same breakpoints for different views from regular Axure pages. (Large preview7)

Now, we can update the design of the phone landscape view. In the screenshot below, we’ve moved a set of standard list items from where they were at the bottom of the page in portrait orientation up to the right of the page’s hero image. The promotional headline has been made larger, and the text beneath it has been run across the full width of the screen. More of the page’s content will now appear on the screen (depending on whether the page is viewed in full-screen mode or with the browser chrome and iPhone status bar showing).

The view redesigned for smartphones in landscape orientation
The page has been redesigned to make better use of the phone’s screen in landscape orientation. (Large preview8)

Tablet Views

Now that the views for the two phone orientations are complete, let’s start on the tablet views. We’ll use the iPad for these views, but again, the techniques may be used for any screen width or operating system. The mechanics of creating the tablet views are the same as for the phone landscape view.

We’ll start with the tablet in portrait orientation because that is the next widest screen. We’ve set up this view to appear when the screen is 569 pixels or wider. This leaves our phone landscape view constrained to screens between 321 and 568 pixels wide, with this third view handling the wider tablets. As you can see in the screenshot below, we may choose to have the tablet portrait view inherit from phone landscape view. Because of the way that inheritance works, any changes made to the base view or the phone landscape view will be inherited by the tablet portrait view.

Adaptive views dialog for creating a tablet view
The Adaptive Views dialog for creating a tablet view in portrait orientation. (Large preview9)

And just as with the phone landscape view, the tablet portrait view starts as an exact copy of the view it inherits. In the screenshot below, I’ve added a page guide at 768 pixels on the x axis and 1024 on the y axis, which is the size of non-Retina iPads in portrait orientation. The tab for it is labeled “569” to reflect the breakpoint that triggers this view.

Initial tablet view before redesigning for larger screens
The tablet portrait view starts as an exact copy of the view of its immediate parent. (Large preview10)

With a large canvas to work with, we can completely change the layout and add new content elements.

The view for tablets in portrait orientation
The view for tablets in portrait orientation allows for much more content than the smartphone views. (Large preview11)

The final view we’ll create is for tablets in landscape orientation. Because this view will be set to appear when the screen is 769 pixels or wider, it will also appear for desktops and laptops unless more views are added. Because this new view will be for tablets, let’s have it inherit from the tablet portrait view to include the content added for those devices.

Adaptive views dialog for tablets in landscape orientation
This view will be used for tablets in landscape orientation, as well as for desktops unless additional views are created. (Large preview12)

With this final view, we have space for more design elements on the right side of the screen.

The view for tablets in landscape orientation
For the tablet landscape view, we could simply add elements onto the portrait orientation view or completely rethink the design, depending on the needs of the project and the content available. (Large preview13)

With this final addition, the project now has different views for phones and tablets in portrait and landscape orientation. If you have an iPhone or iPad, you can see the two views created for each device by opening your browser, navigating to our example prototype14 (hosted by AxShare), and rotating your device.

Limitations

Adaptive views have some limitations. First, the code generated by Axure RP is not usable as a starting point for development. But unless you write the HTML and CSS using the templates or framework that you use on the production website, then this is probably true of your current prototyping tool.

Because of this limitation, adaptive views cannot be used to create proof of concepts for front-end coding solutions. But that’s not the purpose of Axure RP or of the UX prototyping process, so it’s not so much a limitation as it is just something to be aware of.

One other limitation affects teams working with Axure RP’s shared projects feature. Because all views are designed for one page in a project, when someone is working on one page in a shared project, other designers may not edit any of the views. This differs from previous versions of Axure RP, in which mobile and desktop prototypes would be created from separate pages, meaning that one designer could work on the desktop version while another worked on the smartphone version. This would only be a limitation if different people are working on the mobile and desktop designs, rather than one individual executing everything.

Conclusion

If you’re building a prototype to demonstrate or test the usability of a website that will be accessed on a smartphone or tablet, then you’ll want it to be responsive. To get this kind of prototype in the past, we’ve had to use HTML and CSS with media queries and breakpoints.

Now, Axure RP 7’s adaptive views get UX designers who don’t code much further along the path of prototyping and testing responsive designs than a lot of other tools have in the past. With this new feature, a UX designer can create a multi-device prototype in a few hours. As we all get further along in designing for our multi-device world, Axure RP’s adaptive views are a great tool to have in your arsenal.

(da, al, il)

Footnotes

  1. 1 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-1.png
  2. 2 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-2.png
  3. 3 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-3.png
  4. 4 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-4.png
  5. 5 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-5.png
  6. 6 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-6.png
  7. 7 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-7.png
  8. 8 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-8.png
  9. 9 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-9.png
  10. 10 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-10.png
  11. 11 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-11.png
  12. 12 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-12.png
  13. 13 http://www.smashingmagazine.com/wp-content/uploads/2014/02/adaptive-large-13.png
  14. 14 http://916148.axshare.com/bike_shop.html

↑ Back to topShare on Twitter

Will Hacker is the author of Mobile Prototyping With Axure 7. He’s used Axure for several years as part of his iterative design and prototyping process. Will spent two and a half years working exclusively on mobile design, prototyping, and usability testing, and Axure was one of the main tools in his arsenal. He also has written about prototyping and user experience design for Smashing Magazine and UX Booth, and is a frequent speaker at design events in Chicago. Will is a Lead Interaction Designer at GE Capital, where he works on multi-device designs for commercial lending software. You can follow his tweets at @willhacker or visit his website at willhacker.net.

Advertising
  1. 1

    I’m vary skeptical about these wireframing tools. I don’t understand how could be faster and more useful than prototyping in html (expecially using a library like bootstrap).

    If I need to get a low/mid prototype for testing, bootstrap and other libraries allow me to create a website and test it on real devices, not a representation of it.
    If I need to find a solution with the maximum freedom to think, there are pencils and rubbers.

    The only value I can see here seems to be the GUI – supposing this could be considered a sensible value.

    There is something that I do not consider?

    -3
    • 2

      I absolutely agree with this. Without having a Proof Of Concept at the end of it, I consider these wire framing tools useless. For anybody looking for a quick front-end tool for coding responsive websites with live testing functionality on multiple sites at once, I would recommend Brackets.io or Adobe’s Edge Code.

      -1
      • 3
        • 4

          Great come back.

          I doubt he could.

          I find Axure comes into its own when collaborating. I’m currently working on an enterprise level online baking website, there are 10 UXers in two different cities all in different work streams using the same Axure doc.

          Our job is to think about interactions/architecture/problem solving etc and getting bogged down with HTML or visual design is counter productive.

          Also, something not mentioned here is the ability to annotate and generate a functional spec from Axure. This is especially useful when using offshore developers.

          In a nutshell everything has its place whether its HTML prototypes, paper based prototypes, photoshop mockups etc etc. Its all about using the right tool for the job. If you’re super efficient in HTML or design in browser then use that method and on the contrary if you’re quicker in PS/Axure then use that.

          I get sick of these debates were fanboys claim that their software/method is better than somebody else’s.

          4
    • 5

      I agree paper prototypes are the best options while initial brainstorming and conceptualization. But at later stage where we need to keep on iterating these mock-ups then wire framing tools are the best. Digitized formats are always quick and easy to fix and update…compare to paper sketches where we need to redraw again and again.

      Axure RP7 supporting adaptive views… Awesome feature… this is what i was waiting for a long time.

      1
  2. 7

    @Pierre and @Matt explained the value of tools like Axure very well. Not every experience designer has coding skills because many come from backgrounds in visual design, anthropology, and psychology, among many others. I agree with @Matteo that code-based solutions can give you a real working proof of concept at the end, and can be faster to work with if you are experienced with them. I’ve had positive experiences using that approach. But people’s lack of coding skills or easy and quick access to a developer create a need for tools like Axure. As for the question of complexity, usability testing of complex flows is why you need JavaScript-like functionality. Prototypes are not just for sharing with clients. Experience designers can simulate, test, and improve these experiences without consuming development resources.

    5
  3. 8

    I have used Axure for many years from simple websites to complex ipad apps. The thing with any prototyping tool should be to get your mind on the UX. You dont want your cognitive resources being used up on html/css/javascript when it could be being creative about UX.

    All prototypes need to be easily discarded. Thats why papaer prototypes actually work so well – however paper prototypes fall down as soon as you need to iterate or share to someone on the other side of the planet, or in the next building.

    Bootstrap and other front end frameworks can be fast if you stick with prebuilt components but when you need to ‘sketch’ ideas you mind is taken up with achieving a layout in code. Even though I’m good with html/css it’s not what I need to be thinking about at that point. Sure you ned to understand how something will be built in the front end, but you dont need to achieve that at prototyping stage.

    Axure helps sketching out ideas roughly, then linking elemements together with interaction and iterating and building infunctionality as you go. As Axures output is html, there are a still a few things it still needs to get right – like flowing text/content. When that’s right responsive prototypes will feel better.

    If its quicker to test, discard and iterate ideas in a prototype tool, thats what I’ll use. I dont want a frameworks precreated elements or grid system limiting UX creativity. I use prototypes to prove the UX of functionality. It doesnt mean there isn’t room for visual design at a later stage or to change even the layout, so I wouldn’t want to be locked into front end code I’d hacked together to play with ideas.

    But, when we need high fidelity and have UX concepts, functionality and layout worked out. Sometimes it’s quicker to go from there in a front end environment. A lot of decisions about which tools to use obviously depend on your workflow and team process – or even if there IS a team or if you do it all yourself.

    But I would like to reemphasise this one point. A prototype MUST be easy to discard. You probably dont want to discard your html/css/js if you have invested cognitive resource in reasonable code. Therefore you are less likely to discard a bad idea much less a just mediocre one, and start over or iterate. And that is the point of prototyping.

    3
  4. 9

    Thanks for the article. I would like to give it a try! :)

    0
  5. 10

    @Matteo

    I’ve used both methods, and while I’m not a code ninja, Bootstrap was pretty much mandatory whenever you wanted to make a responsive prototype. Also, for simple responsive layouts with little functionality, then using Bootstrap can in some cases be quicker.

    However, the real value of Axure (and even more so in version 7) lies in its ability to set up complex, Javascript-like functionality relatively quickly.

    Things like searching/filtering a list of items, performing calculations, and setting up different outcomes based on previous steps (such as entering in incorrect username) are generally easier to set up in Axure, as opposed to writing and debugging a load of Javascript (which, personally, was never my strong suit anyway).

    This makes it easy to test complex user flows, and very quick to iterate. It’s certainly not as powerful as libraries like jquery and does have it quirks, but it has become far more powerful in version 7.

    For those who are already highly proficient in frontend code, and can develop rich, testable prototypes that can then be carried through to production, then Axure may not be ideal. But for everyone else (myself included) it saves huge amounts of time.

    0
    • 11

      But why would you be building complex js functionality in a prototype in the first place? It’s usually important to limit functionality, because clients can get confused as to whether or not you’re showing a demo or showing work-in-progress.

      0
      • 12

        I work on a large team that involves User Experience Architects, Designers/Front-End Developers, and Back-End Software Engineers. We build complex applications that have many integrated pieces that need to work within other systems.

        It is usually the UEA’s role to work with customers and stakeholders to define the site’s requirements and work out an experience that both hits those marks and easy to use.

        They do not code and do not work on the visual design. That is my job. A tool like Axure allows them to focus on functionality and layout quickly and efficiently. They can then take that to said stakeholders/customers and fine tune the experience.

        This gives me the time to focus on branding, visual language, possibly a starting framework, etc., until the wireframes are ready for me to start building out the pages and/or templates.

        For a team like mine, where responsibilities are distributed, tools like Axure become really valuable.

        On the flipside, when I do freelance, I’m usually taking care of most if not all tasks. In those cases, I agree. It is much easier for me to start with some basic html as a wireframe, get some sign off, and then begin to apply a design and then flesh out more functionality.

        0
  6. 13

    I’ve used Axure effectively before the adaptive functionality was available.
    Whilst it enabled me to rapidly create complex wireframes, the amount of work required to ‘emulate’ functionality was quite considerable in contrast to how rapidly layouts could be created and modified.

    As a coder, I switched to Bootstrap which I find is more time consuming for layouts, but far less for interactive functionality. The added bonus, is the code can be used in production.

    Axure is useful if your coders are busy or if you have no access to coders during a prototype phase of a project, but if you do have coder time readily available or are a coder yourself, there’s simply no substitute for prototyping with HTML & a CSS framework.

    As I mentioned, the bonus is having working code as a result.

    That working code, regardless of design, can be handed over to programmers to have a ready made framework to use whilst other parts of the project are being developed by front-end developers – the agile approach.

    The issue with tools like Axure, the way I see it, is how rapidly the roles of developers , designers and project managers are changing. Designers are becoming front-end coders and whilst a wireframe can bring you some way to understanding how the content of a website could be laid out and how ‘widgets’ may work, there’s just not enough flexibility.

    It seems to be a concept that’s mired in the past – where workflows were quite different to the way they’ve rapidly developed over the last few years.

    The ‘old school’ method centered around wireframe / design / code, as almost separate entities of a project. Modern methods involve a great deal of team collaboration, with multiple parts of projects being worked on simultaneously by designers/developers, programmers and project managers.

    Effectively, the *entire* process of website creation is adaptive, by all disciplines in the team. That necessitates the need to actually code prototypes and in fact design them as the project develops.

    As anyone who has worked on a large web project with a large team knows, the end result rarely reflects the wireframe and in some cases, complex wireframes can hinder the creative process and very often, confuse the hell out of clients!

    0
  7. 14

    I am very skeptical about using Axure for responsive layout, part of it deals with the fact that font size and spacing would remain the same; but there’s so many valid points to use Axure (or Justinmind) as a prototyping tool. Some of these points have been already covered here:
    - more flexibility on layout, and very easy to add/edit graphic assets and apply styles that can be used to make global changes quickly;
    - can set complex interaction patters without too much effort;
    - can focus on design.
    - no need to code, but possible to use variables, conditions, and IF statements;
    - possibility to add contextual documentation for developers;
    - very easy way to handle masters and reoccurring elements.
    None of this can be achieved by HTML frameworks. The only way to write production-ready code is to know exactly what you are doing, otherwise you are going to waste a lot of time, but then it’s not design any more. Designing a front end and developing it are two very different processes! And unless you are a professional front-end developer (which takes years of practice), that code is unlikely to be handed over to a developer who takes his work seriously.
    I’ve covered these points more in detail on my post about prototyping tools:
    http://www.humaneinterface.net/best-prototyping-tools/

    3
  8. 16

    What would be the benefit of using Axure over Fireworks? It seems like they can both do the same things.

    -1
  9. 17

    Real web made by real designers and developers doesn’t need expensive tools for things like this anymore. I think that’s not the right direction.

    0
    • 18

      And that is why so many sites are poor, and why so many startups fail!

      You don’t start at design and move to development. Ideation, requirements, proto-personas, interviews, personas, IA, sketching, paper prototyping, wireframing, testing, prototyping, testing… are just a sample route that should happen before you write a line of code.

      If you are a UX Designer who is happy to code, then by all means do so, but you have to be a really good front-end developer on top of having the skills that come way before coding…. these mythical unicorns don’t exist. http://unicorninstitute.com/

      So yeah, Axure is a great tool, along with many others, and it is a tool that is valuable for anybody who is interested in the user of a product.

      6
  10. 20

    I think Mark Boulton’s recent post sums up the argument in the comments pretty well.

    “The right tool at the right time I’ve spoken about designing in the browser, or designing in Photoshop, or on pencil, or whatever. Frankly, we try to use the most appropriate tool at the right time. Sometimes that’s a browser, but a client may respond dreadfully to that because they’re are used to seeing work presented to them in a completely different way. Then, we change tack and do something else. My feeling is the best design tool you can use is the one that requires the least amount of work to use: be it a pencil, Photoshop or HTML.” Link here http://markboulton.co.uk/journal/how-we-work

    It’s about the users and the audience.

    0
    • 21

      Great point. I’ve worked in environments where we went straight from sketching to HTML because we were organized into small, lean teams. I’ve been in other environments where you needed to test out your concepts with actual customers using tools like Axure before you could get approval to enlist more-expensive development resources. It really is about understanding the full set of tools available, and when it is appropriate to use each one.

      0
  11. 22

    Christopher Cenkner

    February 27, 2014 10:04 am

    This was really helpful. Been meaning to try this new feature out. Thanks for putting this together!

    0
  12. 23

    I’ve been using Axure for ages, and find it to be most useful when conducting usability testing prior to moving into design & development. I can see instances where this could still be the case for the adaptive views feature. But the adaptive view feature alone doesn’t make a responsive prototype. There are a few key features dealing with font scaling, image scaling, and fluid grids that aren’t available yet.

    That said; I agree with the people in this thread that suggest Axure shouldn’t be the tool that’s used to create a responsive prototype. I only buy into the idea of responsive websites if there’s some sort of efficiency gained from it. If we’re creating (essentially) an interactive set of wireframes to represent how each templates layout changes from breakpoint to breakpoint – I don’t see any efficiency in creating a responsive site at all. We might as well make separate sites for device groupings. I normally only create wires, or an Axure prototype, for the max breakpoint + navigation designs for all break points – and only consult with the developer as he starts making decisions about how content responds to thinner screen widths.

    There are a few new tools, like Macaw, that will do what Axure does; but will result in usable HTML code. My feeling is that these tools will eventually make Axure obsolete, unless they invest a little more into their co-design & collaboration features.

    0
  13. 24

    Good article… I use various tools to wireframe and prototype, Axure being my favorite these days. I’ll give this technique a try. Thanks!

    0
  14. 25

    Great article and interesting discussion!

    There is so much irony in this purist idea that UXers need to start wireframing in code. We spend all day creating tools to make others’ tasks and workflow more visual, streamline and humane. We are always trying to bring the user-action and the system-reaction closer together – do this, see this change.

    But now many of us are insisting that our own taskflow should not be gussied up by any new-fangled fancy tools!

    I personally want be able to move an element by DRAGGING THAT ELEMENT. Not pushing it around in lines of code. I would not put that on any of my users – why put it on ourselves?
    Some people might enjoy geeking out in code, but to me, a highly visual thinker, it make me want to cry! And when I am trying to devise a holistic design system for a client, not an easy task, I want a tool designed specifically for my needs. My job is hard enough. Give me the best tools!

    My main reason for using Axure is not the Apaptive views (yet). My favorite features of Axure are Masters, Dynamic panels and Styles.

    MASTERS gives me the ability to easily create repeatable modules and nested elements. When I am creating a modular system, I want the ability to create a low fi place holder for “product”, place it everywhere I know I will need it, the go back and add fidelity and interaction in ONE place. My module library also lives in Axure, so this document is updated as well.

    DYNAMIC PANELS lets me easily create various states of a module. I will always need this.

    STYLES lets me do about 90% of my visual design in Axure, as opposed to Photoshop. I can apply a design language, and if I need to change the color and hover state of all my buttons, that update takes 2 seconds fro the entire document.

    1
  15. 26

    What I didn’t get from the start is why you’re targeting 320 x 568 for Iphone 5′s, if it’s actual resolution is 1136 x 640?

    0
    • 27

      Great question. It’s easier to work at one-half the size of the actual device because it’s more manageable when working in the Axure workspace. The viewport tag will ensure your prototype scales up to full retina device width. As you point out, you can also work at full device screen size.

      0
  16. 28

    This is a very interesting article and as ever in cases like this, there is an underlying niggle between the coders, designers, UX and everybody in between.

    From my point of view, Axure is awesome. I’m more than happy to fire up notepad and write a bucket of code, but as has been said by others “I want to use my brain to solve other problems”. If I really wanted to, I could hand code SVG / FXG files – but why make your own life more difficult.

    Clients are only interested in how good UX can make their life easier or better, they don’t care if you hand-coded the prototype in notepad. Using a tool like Axure (or Balsamiq), enables me to focus on solving problems and finding solutions – which from a UX point of view is far more important.

    2
  17. 29

    Great tutorial, Will, thanks! And I definitely appreciate the tension between using Axure as a tool and using code itself – how much effort should one invest in becoming an expert in a tool that functions as an abstraction of code instead of just… becoming an expert in code? If learning Axure is way, way faster, I can see the value, but if it’s kind of a wash, might as well become a code dude (is my opinion).

    Either way, I’m a little confused about the setting of breakpoints in this article – wouldn’t I only want “Phone (Portrait)” to switch to “Phone (Landscape)” when the width is 481 or higher, rather than switching at 321 or higher? That way, the prototype only expands to Phone (Landscape) when it’s wide enough to display the entirety of Phone (Landscape), and stays in Phone (Portrait) until that point (and on that note, wouldn’t the Phone (Landscape) layout itself be 480px wide instead of 568?

    Another side note: I wonder why Axure doesn’t allow breakpoints to be identified by “between X pixels and Y pixels” instead of only supporting greater than/less than language? Probably a question for Axure though, not you!

    0
    • 30

      Oh yeah – and on this note, does that mean you’d want to inherit from LARGER templates down, instead of smaller templates up? And would this kind of compromise the whole mobile-first technique?

      0
  18. 31

    Speed and flexibility (quick changes/iterations) is probably the biggest argument for (still) using those prototyping tools. I did the Facebook Paper Landing page in one hour: http://wearebridge.co/ux-tools/Axure-Flat-UI-Kit-Preview/start.html#p=facebook_paper__landing_

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top