Swap Widgets

Problem

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.

Solution

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.

Translation

Problem

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

Solution

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.

Revert to parent settings in adaptive views

Problem

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

Solution

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.

Extend axQuery

Problem

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”.

Solution

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'.

Interaction styles in custom widget styles

Problem

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

Solution

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.

Panel state styles defined in custom widget styles

=== Problem == =

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

Solution

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.

See masters and dynamic panels in context when editing

Problem

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

Solution

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.

Masters in repeaters

Problem

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.

Solution

Fix the bug.

Folders/Layers

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

Adaptive view transitions

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

Page States

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 Review Functions

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

Anchors

  • 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.

Click Through Widgets

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.

Components

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

Invoke event handlers

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.

Disable actions

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)

Persistent Variables

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", ...);

Allow repeater datasets to be updated without reloading

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.

Store variables and datasets in browser local storage

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.

Shared repeater datasets

Datasets for repeaters shared between different repeaters.