If you have a widget that is referenced in many actions (event handlers) it is very time consuming to swap this widget with another widget. You have to find all the actions where the widget is referenced and replace the reference with a reference to the new widget.

Create a “replace with” function. An example:

• Select a widget or master.
• Activate a new function called “replace with”.
• Select a different widget or master.
• Now all actions that reference to first widget or master is replaced by actions that reference the second widget or master. Finally the first widget is deleted. This would make it much easier to exchange one widget with another.

It it requires a lot of work to create prototypes where you can switch between different languages.

The text on a widgets exist in multiple languages. A global setting defines the current language. The current language can both be changed in the Axure editor and in the HTML prototype.

This makes it very easy to develop at prototype where you can switch between different languages.

It is difficult to make a widget in an adaptive view revert to inherit its properties from the parent adaptive view.

Create a function that revert all properties on a widget to be inherited from the parent adaptive view. Here is how it could work:

• Select a widget.
• Activate a new function called “Inherit all properties form parent adaptive view”
• The widget now inherit all its properties form the parent adaptive view.

In addition to this add a “inherited” indicator to all properties, that can be inherited. Clicking on the indicator will enable “revert to inteited” for that value.

The JavaScript query function of the object is somewhat limited. To my knowledge it can only find widgets with a given name or id. An example:

var query = ('@Hello'); // Finds all widgets named 'Hello'
var query = ('#Hello'); // Finds widget with id 'Hello'

I order to make my JavaScript code more robust I often want to use more complex query selectors such as “owner is”, “child of”, “descendant of”, “partial match” and “owner is”.

Allow more complex selectors in the query function. Examples:

('@Prefix*'); // Finds all widgets with a name that starts with 'Prefix'
('@*Suffix'); // Finds all widgets with a name that ends with 'Suffix'
('@Parent > @Child'); // Finds all widgets named 'Child' with an immediate parent called 'Parent'
('@Parent > @*'); // Finds all widgets with an immediate parent called 'Parent'
('@Ancestor @Descendant'); // Finds all widgets named 'Descendant' with an ancestor called 'Ancestor '
('@Ancestor @*'); // Finds all widgets with an ancestor called 'Ancestor '
('@Page >> @Widget'); // Finds all widgets named 'Widget' with an owner (the page or master a widget is placed on) called 'Page'.
('@Page >> @*'); // Finds all widgets with an owner (the page or master a widget is placed on) called 'Page'.

It should be possible to define interaction styles such as MouseDown, MouseOver in custom widget styles.

Make it so that interaction styles can be selected in custom widget styles. A widget that is assigned a custom widget style where interaction styles are specified use these interaction styles.

=== Problem == =

It should be possible to define panel state styles in custom widget styles.

When a custom widget style include panel state formatting, is assigned to a widget, this formatting then applies to all panel states of the widget.

When a master or dynamic panel is edited it is not possible to see the context it is used in.

Show the context in which a master or dynamic panel is used as a “background” image, when a master or dynamic panel is edited. A master can be used in multiple contexts, so the master must be opened from the context that should be showed in the background.

If a repeater uses a master and the OnItemLoad event on the repeater change widgets in the master. It is not rendered correctly in Axure. Currently it only works when viewed in a browser.

Fix the bug.

Group widgets into folders/layers. Pages/masters with many widgets are more easy to overview.

• Folder 1
  • Widget A
  • Widget B
• Folder 2
  • Widget C
  • Widget D

Enable transitions between adaptive views. As a starter enable “swing” transitions of positions.

In order to support “single page” applications support for “page states” would be an efficient solution.

• Page 1
  • State A
  • State B
• Page 2
  • State A
  • State B

Page states are accessible form the site navigation panel. Page states do not reload the page in the browser, but they affect browser history. States are handled similar to responsive layouts, where position of elements are stage dependent. The state of dynamic panels is also state dependent.

Improved annotation of prototypes hosted on axshare. Drawing and writing directly on top of the prototype.

• Left: Widget position is relative to left side of parent. (This is the current implementation)
• Right: Widget position is relative to right side of parent. The distance from the widget to the right side of the parent is always the same.
• Both: Widget position is relative to both the left and right side of the parent. The width of the widget is adjusted when the size of the parent changes.

• Top: Same as left but vertically.
• Bottom: Same as right but vertically.
• Both: Widget height is adjusted when parent is resized.

It would be nice if a widget could be set not to capture mouse/touch events, so that the widget behind it receive the mouse/touch events.

Apply the principle from repeats to masters. A master have named properties that can be read in a “OnPropertyChange” event. This can be used to make masters more genetic.

Page:
  Set "Property A" on Master

Master:
  OnPropertyChange

A master can fire custom events.

Current workaround:

Widget A:
  OnMove

Widget B:
  move Widget A

This would be much nice:

Widget A:
  OnDoSomething

Widget B:
  invoke OnDoSomething on widget A.

This requires a “Add event” function on widgets. And an extension of the “raise event” functionality.

To test different ideas it would be great to be able to disable specific actions assigned to an event.

Widget A:
  OnClick:
    [x] hide "Widget A". (Action is enabled)
    [ ] move "Widget A". (Action is disbaled)

The values of global variables are “lost” when the user go back in browser history. It would be great to have persistent variables. These could be stored in local storage, in cookies or on a server.

// Create a session (stored in global variable "Session")
javascript:.create();

// Save global variables to session.
javascript:.save("VariableName", "VariableName", "VariableName", ...);

// Load global variables from session.
javascript:.load("VariableName", "VariableName", "VariableName", ...);

Currently when a repeater dataset is modified all repeater items are “reloaded”. In some situations it relevant to “just” update the dataset and not “reload” the repeater items.

Currently variables are stored in the URL. If variables and datasets where stored in browser local storage, the URL would not get so big, and the information would not depend on browser history.

Datasets for repeaters shared between different repeaters.