Push / Pull: Almost unusable

#1

Is it just me, or is Push / Pull Widgets (particularly with animation) almost impossible to use reliably in anything other than the most trivial situations?

It’s true that my prototypes push the capabilities of Axure generally (my work really needs to replicate exactly how the interactions will work), but I also know that users can break prototypes easily and they can fret over it - and broken protos are really not helpful when testing with remote audiences.

In short, the widgets on the page - under heavy use - tend to end up wandering away from where they’re meant to be, and that’s not satisfactory.

As I test, I’ve spent the best part of a day trying to make a bulletproof drag ‘n’ drop component, and I’ve had to put multiple protection flags in place simply to ensure that animated push/pull doesn’t get broken.

It shouldn’t have to be like this - I think a more robust architecture needs to be put in place.

#2

No, it’s not just you. Search for “push pull” in the forum to see all the questions and issues people have posted. When the feature works it’s awesome, when not it is maddening to figure out what’s going on.

Approaches I’ve found that help…

  • If you’re moving things around, resizing, or ever need to deal with locations of widgets, don’t group widgets, but rather put them in dynamic panels. Groups get buggy when anything is moved, or adaptive views change.
  • When using the Push/Pull option, be sure the entire area of widgets to be pushed/pulled do not overlap.
  • Push/Pull seems to be more reliable when all the widgets are the same width–or at least that the widgets to be pushed/pulled are narrower and located within the width boundaries of the widget doing the pushing/pulling. To help with this, create vertical sections in your page with dynamic panels that span the entire width of the page–or at least all have the same width. You can place a “full width” hotspot in the back of each “section” dynamic panel to help with this.
#3

Hi JMW –

I recently started a fairly involved project involving drag ‘n’ drop in Axure 9, and I too was baffled by the random wandering of widgets away from where they were supposed to be despite all debugging attempts.

I ditched Axure 9 even though I was a couple days in and rewrote the whole project in Axure 8, and everything worked like a champ. I then converted the Axure 8 file to Axure 9, and the random wandering came back.

Unless I’m opening an Axure 9 forum file that someone posted, I only use Axure 8.

#4

It is not just you @JMW.

I’ve been struggling with this for a while too. I was at least able to observe when this happens. This is sure to happen every time I use multiple animations on a page that involves pushing and pulling of widgets.

More specifically, whenever a user event (that triggers another animation involving pushing/pulling) occurs by the time the initially triggered animation finishes, you can see widgets getting misplaced.

One ‘imperfect’ workaround I’ve tried to use to introduce a artificial/deliberate ‘wait’ of 0 between show/hide (which involves push/pull) which seems to prevent elements from misplacing themselves but the tradeoff is that the portion of the screen involving the animation will flicker as the elements try to reposition themselves in their ‘correct’ places.

Overall, I agree it is very frustrating and hope they fix this thing asap.

@josephxbrick and @mbc66 - tagging you for this may get you thinking more as you’ve helped me solve many problems.

#5

There’s certainly a great deal to know about this topic. I like all the points you’ve made.

#6

It’s definitely not just you! I’ve had Axure do some downright odd things when I add in the push/pull functions to the “Show” or “Hide” interactions, and it’s usually much more hassle than it’s worth, especially when you start to add in repeaters and nested dynamic panels.

What I’ve found to be a better solution is:

  1. Select the widget that is changing states, being shown/hidden, or moving
  2. In the Interactions pane, select OnClick: (Or whatever you’d like your interaction trigger to be)
  3. Move [The widget you want to push/pull] to [[This.x + 32]], [[Target.y]] if you want to move the widget to the right, or [[Target.x]], [[This.y + 32]] if you want to move the widget down.
    3a. Replace the “+” with a “-” if you want to move it up or left instead or down or right. Replace the “32” above with however far away you want Target widget to move from This widget.
    3b. If you want your Target to move away from another widget that isn’t This, use a local variable to represent that widget. For example, LVAR1 = widget SelectionMenu (the widget you want to move away from). Then use “LVAR1” (or however you label your local variable) where I’ve put Target up above.

Hope that helps!

P.S., any time you need to reference a widget that isn’t This or Target, you’ll use a local variable.

#7

Of course - but that’s not maintainable in many situations.

If you have (e.g.) a form, you might have a dozen or more widgets below the expanding content and you would either have to maintain a list of what needs moving, or dump all the succeeding widgets into a series of ever-more-nested dynamic panels - at which point your architecture is based around a software issue workaround rather than a robust design.

I’m currently using Sam Hepworth’s suggestion of using a separate, transparent “Puller” widget (e.g. an empty rectangle) that uses pull/push under better control of the code.