Table of Contents
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.