• Axure Blog RSS Feed

    by Published on 12-22-2016


    Click the snow globe to give it a shake!

    Here's a little something we made for y'all to commemorate the 2016 holiday season. Download the .rp file to make it your own!

    Have a great rest of your year. We'll be back in 2017 with exciting updates to the blog and to Axure RP.

    Warm wishes,
    The Axure Software team

    - - -

    Instructions for editing:

    1. Update both the page's background color and the fill color for the "scene mask" shape to change the color of the background.



    2. Add your own image in front of the "scene" widget to customize your snow globe!

    by Published on 11-16-2016
    1. Categories:
    2. Inside Axure



    (This article is adapted from a talk I gave in September 2016 at UC San Diego, organized by San Diego Experience Design. I shared another portion of the talk last month.)

    Does Axure practice Agile software development? The short answer: yes and no. For the long answer, read on.

    We definitely wouldn't qualify as a strict Scrum Agile shop. And we aren't Lean, in the formal sense of that term. (Though we do feel pretty lean, to me, in the informal sense.) We don't do stand-up meetings; our formal development meetings are once per two weeks, not daily. We don't do formal pair programming. We don't do formal sprints.

    So what do we do that's Agile? Lots and lots of face-to-face conversations among and between the development and product teams. There's a lot of trust between teams, and we actively foster that. Trust is the best thing we've found for positively impacting motivation. And motivation, in turn, is the parameter of our work environment which we've found correlates best with productivity and quality of output. So we invest however we can in maintaining ourselves as a highly motivated group of people.

    We very much welcome changing requirements. We're always on the lookout to make sure the solutions we're coming up with are solving the problems they're intended to solve—and if they aren't, we adjust. Even late in the cycle, during our (quite lengthy) beta periods, we're careful to maintain enough flexibility to evaluate changes.

    We practice continuous delivery (ready to release a current version of the software at any time), though not continuous deployment (releasing every day via an automated system). We do deploy incremental builds sometimes, within our larger framework of major releases. We do a lot more of that toward the front end of a release and less as the release matures. And we've actually been working to reduce the number of incremental releases per cycle, for a number of reasons.

    To elaborate: over time we've gone from shorter betas, earlier releases, rapid updating and bug fixing, to longer betas, later general releases, and fewer but more substantive post-release updates. We've also begun to release our higher-risk builds via a release candidates channel. So the RC is now for the people who want to be on the latest and greatest with every bug fix, and the general release builds are the super-stable ones that big companies can be sure will be safe to install and standardize on.

    When the dev team deploys, there's a certain amount of overhead to each new build. So there are benefits internally and externally from releasing better builds less often. With fewer builds going live, we can now dedicate less time to the overhead of managing releases. We've decided that this leads to us releasing higher-quality software overall.

    So: are we Agile? Yes and no. And that's okay.

    Agile frameworks are like off-the-rack suit jackets: they fit some of us quite well and many of us fairly well, but a bit of tailoring—or an entirely bespoke alternative—will almost always cut a better figure.

    Agility is context-dependent. By contrast, the various prescribed Agile and Agile-like frameworks—just as with any set of best-fit guidelines—are context-independent.

    Scrum
    Lean
    Kanban
    XP (Extreme Programming)
    DSDM (Dynamic System Development Model)
    Crystal Methods
    SAFe (Scaled Agile Framework)
    DAD (Disciplined Agile Development)
    Spiral

    And by context-independent, I mean that each of these frameworks was devised to apply broadly to a wide range of software projects. They're like off-the-rack suit jackets: they fit some of us quite well and many of us fairly well, but a bit of tailoring—or an entirely bespoke alternative—will almost always cut a better figure.

    Of course these frameworks do have value, even to those of us who aren't strict adherents: they're sets of good ideas, from which successful teams pick and choose.

    And yes, the way we do it at Axure, there are some waterfall model practices mixed in there as well. I know that may be heresy to say out loud in 2016, but stay with me.

    We talk to customers all the time about this. Axure RP is used by lots of teams who describe themselves as Agile to some degree, but the Axure RP work may not actually happen in the sprints; it happens in the pre-sprints. Pre-sprint planning, or pre-project planning. Sprint Zero. Sprint Ahead. Or they'll call it "backlog grooming", but in the end it's quite a lot like the traditional waterfall practices of product requirements planning and design.

    And these customers generally aren't doing two-week sprints or cycles. Much more typical for our customers are six-week or even six-month cycles. Some of the customers we speak to are anxious about Agile. They're perpetually trying to transition to a "pure" Agile approach, but never getting there. Other teams are comfortable with, and prefer, their six-month cycles. They're accomplishing good work, the team's spirits are good, and two-week sprints just sound like needless strife and chaos to them. And at least it's not the two-year cycles they used to have. It's relatively agile.

    At Axure, we build software, but we're different from many of our customers in that our software is used to build other software. So we've got two perspectives on process management methodology: from running our own process, and also from talking to customers about how we fit into their processes.

    When it comes to our own process, we don't speak in Agile terminology much at the office. You'll only overhear someone at Axure HQ speaking in terms of "sprints" if they're on the phone with a customer who practices Agile. Each team develops a process that's best for them. In our case, we've been building Axure RP since 2002, so we've learned a lot over the years about what works best for us.

    The principles of the Agile Manifesto boil down to communication and accountability. Everything else follows.

    You could call what we do "loose agile". It's highly iterative. There are regular check-ins, though they generally aren't scheduled. We rely on the esprit de corps and motivation of the team, the idea that everybody on the team wants the work done. So we try to keep team spirit as high as we can, and we open up communication among and between teams as much as we can, and then allow the process to happen as organically as possible within that framework.

    You could summarize by saying that it's a culture of mutual respect. If the dev team says they need time to re-architect something, the product team believes them. And vice versa if the product team needs time to rethink, to change a requirement.

    Now, this may sound like a dodge. What does mutual respect have to do with choosing Scrum vs. Lean? Here's the connection: if you look at the principles of the Agile Manifesto, they essentially boil down to communication and accountability. Everything else follows.

    Simplicity, for example. If the team is communicating freely and everyone feels accountable for the end product, there's a minimum of wasted effort. You don't have people accidentally working on the wrong thing, or intentionally not producing because they aren't motivated, or not sure what to work on because they're scared to ask.

    Continuous delivery is about keeping your sights on project goals and staying on track and keeping motivation up. Two-year software projects are inherently depressing—or emotionally challenging, at the very least. Sustainability is explicitly also about motivation. And motivation, we've found, is primarily affected by communication and accountability. So it seems to all come back to these.

    CULTURE OF RESPECT ⇒ COMMUNICATION AND ACCOUNTABILITY ⇒ AGILITY

    And for us, the culture of respect gives us both of these. It's what allows us to effectively communicate amongst and between teams. Respect is also what leads to each team member feeling accountable for the end product. And respect leads to trust, with all of the benefits I mentioned earlier. And so mutual respect amongst our team members is what allows us to be agile, in the original spirit of the Agile manifesto. (In one author's humble opinion!)

    The prescribed Agile frameworks are designed to be more flexible than the prevailing software development practices that came before them. What we're doing is arguably even more flexible. Lighter and looser. I say this while also acknowledging that our teams are fairly small as compared to a lot of organizations. The average tenure of an Axure employee is quite long, turnover is very low, and managers of teams have generally personally hired all of their reports. And we have about one product manager for every three developers. So we have lots of advantages that allow us to get away with being loose and informal.

    We're well aware of the perils of growing our headcount; we've seen many different scenarios play out on our customers' teams. So some day it may be different, and then we'll have to adapt. But the culture of respect will continue to be a constant, as best as we can manage it. ◼
    Published on 11-02-2016
    1. Categories:
    2. Tips and Tricks

    Axure RP offers a lot of power and versatility when it comes to building animated mobile app transitions. To demonstrate this point, I recently got together with our head product designer, Robert Gourley, to build out a tidy little example file showcasing a pretty cool mobile screen transition. (The prototype is part of a task flow for scheduling an appointment with our fictional healthcare provider, Classy Harbor Health.) Here's a gif of the transition we built:



    The animation in the gif is a little jumpy due to the frame rate, but the real prototype is much smoother. To check it out for yourself, download the .rp file.

    The transition is all contained within a single case. Let's take a detailed look at what the various actions in the case are doing.



    Move general practice tag by (-400,0) ease in cubic 450ms
    Wait 80 ms
    Move nutrition tag by (-400,0) ease in cubic 450ms
    Wait 80 ms
    Move holistic tag by (-400,0) ease in cubic 450ms
    Wait 80 ms
    Move more tags icon by (-400,0) ease in cubic 450ms


    These first seven actions move the little category tags leftward and off the mobile screen. ("Move" actions in Axure RP are defined using (X, Y) coordinates, so a negative "X" move action will move the targeted widget to the left.) The "move" actions do the actual moving for each tag, and the "wait" actions give the staggered effect. Try adjusting the durations of these actions to change the feel of this part of the transition animation.

    Move practice general info by (0,80) ease in out cubic 500ms,
    see details button by (0,80) ease in out cubic 500ms
    Set Size of profile photo frame to 375 x 562 anchor top left ease in out cubic 500ms
    Wait 500 ms


    These next three actions constitute the down-moving portion of the animation. The third one—"set size"—enlarges the dynamic panel containing the profile photo so that more of the bottom of the image can be seen.

    Move practice general info by (0,-216) ease in out cubic 650ms,
    scheduling details by (0,-216) ease in out cubic 650ms
    Set Size of profile photo frame to 375 x 354 anchor top left ease in out cubic 650ms
    Set Size of rose to 410 x 471 anchor top left ease in out cubic 650ms
    Move rose by (97,4) ease in out cubic 650ms


    This last section of the case comprises the upward-moving actions you see toward the end of the transition. The last two of these—which target the "rose" image directly, as opposed to its containing dynamic panel—are responsible for making the image smaller and then repositioning it so that it's centered in its frame by the end of the transition animation.

    - - -

    As always, I built this case in Axure RP using the point-and-click controls in the Case Editor dialog. The markup you see in the screenshot is the result of my pointing and clicking, not anything I had to type out.

    Try modifying the animation and see what you can come up with. If you get something good, feel free to share it in the comments section. Thanks! ◼
    Published on 10-26-2016



    Axure RP's core flowcharting capabilities have been a part of the tool for a long time, but we added some additional flow features in version 8.

    Lots more widget types can now be used as flow objects: shapes, images, and even the new-in-8 snapshot widget.

    1. Connector points can be added, moved, and deleted. This means you can have as many connector points as you want, wherever you want them. We've added a new "Connector Points" tool to facilitate all this. (It's normally available via the "More" button in the tool corral on the Main Toolbar, but in my video I brought it out onto the main UI for sake of simplicity.) Once you're in "connect points" mode, click anywhere on a selected widget to add a point, click and drag a point to move it, or right-click to delete.

    2. We added a bunch of new connector line ends. Many of the new ones are helpful for putting together entity-relationship model (ERD) and BPMN diagrams. You've now got a total of 29 line ends to choose from, up from just a handful in version 7. Another improvement over version 7 is that your starting and finishing line ends can now be chosen independently of one another. Access line ends via the Format Bar's "Arrow Style" picker. Here's a screenshot of the full set:



    3. Connector lines can now be straight, curved, or routed at right angles, in addition to the traditional "rounded turns" routing scheme. Look for these options in the Inspector pane when you've got a connector line selected. ◼
    by Published on 10-05-2016
    1. Categories:
    2. Inside Axure



    I figured that the recent visual and UX design update to the Axure customer portal would be a good opportunity to take you behind the scenes at Axure to look at the life cycle of a similar project: our previous portal update, which went live this past April and coincided with the Axure RP 8 release. This particular update focused on adding tools for purchasing, renewing, canceling, and assigning subscription licenses of Axure RP.

    We've been refining how we build software here at Axure since 2002, and by this point the process is pretty streamlined. But we don't adhere to any particular espoused philosophy of process management; we aren't a strict Scrum Agile shop, and we don't make use of a Kanban board. Our approach is informal by design, which makes it hard to encapsulate in a pithy five-point list or what have you. But what I can do instead is describe it by example.

    (This article is adapted from a portion of a talk I gave in September 2016 at UC San Diego, organized by the extremely nice people over at San Diego Experience Design. I'll be sharing more from the talk, which was about Axure's software design and development methodology, here on the blog over the next couple of months.)


    A high-visual-fidelity, low-interactive-fidelity wireframe of the portal's "change edition" dialog, with some change notes for the developer.

    Rachel, one of our product managers, ran the subscription update project, and she worked with Kevin, one of our developers. Victor—our CEO and our head of product management—was also involved because he was responsible for the change from the business side. The idea was to make subscription licenses, which were new to Axure RP 8, manageable via the existing license management portal. We needed this change for its own sake, but we also needed it a little ahead of the Axure RP 8 release so that we could test activating Axure RP with subscription licenses.

    The scope was limited for this update; we knew what we wanted to accomplish, and we also had a set of things we wanted to avoid. At the time, we were planning for a comprehensive visual refresh of both Axure Share and the customer portal. The plan was (and still is) to unify those two properties so that they shared the same design language. We didn't have the new design patterns in April, so Rachel was instead prototyping using the then-current Axure Share assets so that we could begin to bring the two properties together in anticipation of the later visual and UX refresh.

    We tend to start the process of developing a new feature pretty informally. The first prototype won't be very "deep"—just two or three screens. Victor will give feedback and clarify. Rachel will find some conflicts as she's incorporating the requirements and will present some possible resolutions, and Victor will weigh in. There wasn't much competitive analysis on this particular project, but in this case there was a fair amount of comparative analysis, where we looked at how other software products of all kinds have implemented subscription mechanisms.


    Changes needed to the cart page are mocked up and then called out using sticky note widgets.

    Development can begin as early as when the main scenarios have been addressed in the spec (i.e., the prototype). If the prototype gets to that point and the developer is still wrapping up another project, Rachel will continue to flesh out the spec, and it'll be more complete by the time development starts. Either way is fine.

    In the case of this particular project, once Kevin had wrapped up his previous development work and had come on board, communication was a lot of chat, via Slack, and a lot of face-to-face. Kevin had the RP file to work from and would generally ask questions via Slack first, some detailed, intended to stay on chat, and some short, followed by: "hey, can I come over?" (Rachel's desk happens to be next to mine, so I can confirm that Kevin was coming over a lot for a couple of weeks there. Which was nice for me, because I like Kevin.)

    Because they built it, Rachel and Kevin are now the resident experts on the set of features included in this portal update—which at Axure means they're the point people for any bugs that come up. They'll switch back to the portal project and prioritize it when a bug needs fixing. This can put them behind on current projects, which isn't ideal, but it's a concession that we make in order to preserve our culture of work and ultimately boost the quality of our final product.

    If we were doing strict Scrum Agile development, the Scrum Master might get concerned about the distraction of a portal bug fix and potentially push for Kevin to return to his current project. And poor Kevin would have to stand up the next day and admit that he didn't get anything done on the current project because he was fixing the portal.

    In situations where a strict process management framework is called for, to avoid implementing one is to doom your team to inefficiency. But to impose one for its own sake, absent a compelling reason, is just as misguided.

    Kevin takes deadlines very seriously, which is great. But if he were made to stand up and account for time spent on live fixes every day, it could be a recipe for anxiety and sleepless nights. Now, you might argue that that's a personal issue on Kevin's part, but we've found that happy, relaxed developers write better code, and so we prioritize that over sticking to a daily or weekly schedule.

    The imposition of Scrum Agile on a team is, let's face it, a drastic measure. It's a step to be taken when your team has demonstrated a clear, compelling need for it. The subject of what constitutes a good reason for implementing Scrum Agile is beyond the scope of this article, but for now we're happy to concede that good reasons do exist.

    In situations where a strict process management framework is called for, to avoid implementing one is to doom your team to inefficiency. But to impose one for its own sake, absent a compelling reason, is just as misguided. Ultimately, we've decided that a formal Scrum Agile approach—or any other formal approach to managing our software development life cycle—is unnecessary for the way we work today. ◼
    Published on 10-04-2016


    Our visual and UX design refresh of the Axure customer portal is now live!

    We recently released a fairly comprehensive redesign of the Axure Customer Portal. Many of our customers—even regular users of Axure RP—may not frequently get into the portal; in the past it's been mostly just a place to periodically update your credit card info or maybe assign a license if you're the manager of a team of Axure users. The recent redesign makes portal a more pleasant place to do all the stuff you could before, but we've also added a dedicated profile page where you can update your account details and add a profile image.

    The profile image is only being shown in about three places right now—all of them inside the portal—but over the next few weeks and months we'll be rolling out some changes to Axure Share and Axure RP that will incorporate it. So if you're a profile-photo type of person, head over to and upload that pretty-good shot of you on a hike from last spring. Or maybe the one of your cat sitting on your laptop keyboard while you're trying to work in Axure RP—that's a funny one. ◼
    by Published on 09-28-2016

    The Format Painter is a tool in Axure RP that allows you to quickly copy and paste style properties from one widget to another. It's a "modeless" window (the opposite of "modal"), meaning you can have it open while simultaneously working on the canvas. It's super useful and has been part of Axure RP since forever, but it's one of those features that can kind of stay under the radar if you don't know to go looking for it.

    As of Axure RP 8, you can access the Format Painter via the "More" dropdown in the Tools section of the main toolbar. (In previous versions it was available via a small icon in the Style toolbar.) Here it is in action:



    You'll notice that the Format Painter dialog has a line item for each style property available in Axure RP, and each one can be checked or unchecked to include or exclude it when painting to your target widget. If you scroll down to the end of the list of style props, you'll find that you can even use the Format Painter to copy interaction styles (e.g., MouseOver, Selected) between widgets. Convenient! ◼

    Page 1 of 10 1 2 3 4 5 6 7

Search Engine Friendly URLs by vBSEO 3.6.0 PL2