Axure specification templates Deep-Dive – configuration options

In the first part of this post, I went through the process of creating and refining a word template to suit a generated Axure specification. This really only touched on one tab of the specification generation configuration and the idea of this post is to go over the remaining options and explore their usage.

Lets assume you already have a project to work from that will generate a useful specification and press ‘F6’ or the ‘Generate Specification’ on the toolbar.

I want to explore the available options on each tab of the configuration window and show the effect each has on the generated spec.


Pages – a blessing for BA’s working within an iterative project

So the first tab, ‘Pages’ allows you to select which of the pages within your project you wish to include in the generated specification.


Starting with the first options, there is an option to include the pages section and give it a title and directly beneath that an option to specify whether to include a sitemap and change it’s title.


Then the next section allows you to select what pages will be included in the generated spec. This is particularly useful when developing in an iterative approach where the specification is built a functional area or module at a time. This way you can flesh out the annotations / notes for the relevant pages  and leave out those that are not finished.

When generated in the specification, the following section of the spec is effected by the ‘Pages’ configuration options.


Masters: to repeat – or not to repeat?

Masters in Axure are used to define common elements that appear across the system and allow a centralised governance. Make a change for one master and its applied across them all. It’s a concept that is used in traditional manual specifications but is harder to manage – primarily because it relies on manual processes to apply changes to the relevant areas.

In your specification, you have the option to print out all or a select few masters as you did with pages, change section and heading titles.

The interesting set (the other options are essentially the same as document above for ‘Pages’) are around which masters to generate and whether to generate them once or as they used per page.


The first option – ‘Only List Generated Masters’ is useful if there are masters in the project that are not being generated because of one of the other options in this screen (explained below, but useful for the iterative / modular spec approach).

‘Only Generate Masters Used on Generated Pages’ only includes masters that are are used in the selected pages from the ‘Pages’ tab. If ‘All Pages’ is set on that tab by definition all masters will also all be displayed.

‘The ‘Do Not Generate Masters Set as Custom Widgets’ does exactly that, funnily enough. Some masters can be set to behave like custom widgets and this allows them to removed from the master list if necessary. This could be useful if you are using a master in a different, possibly more dynamic way, than standard masters and wanted to differentiate it from the other masters in the list.

The last option allows you to generate the master in each page that it appears, rather than the standard approach of generate once and reference it when it is used elsewhere.

So that translates to the following rendering in the specification.


Un-ticking the ‘Document Masters in Page Sections’ box displays a nice section at the bottom with all of your masters like the above.


… and ‘Ticking’ the box displays the master as it appears within the page as if it was a normal widget on the page.

The above ‘repeat on each relevant page’ approach may prove useful in situations where the generated specification does not include the whole system context and therefore it may not make sense to list them out separately

Notes – adding extra detail to your specifications

The ‘Notes’ tab doesn’t offer too much additional configuration elements other than whether to include page interactions (‘OnPageLoad’ events/conditions) or not.


Similar to the other tabs of, the main configuration options are around whether you generate all or select few, rename the title or change the order of each notes.


The last tickbox for ‘Include Page Interactions’ determines whether ‘OnPageLoad’ events are generated into the specification or not.

image –> image

Screenshot – to power to present pictures

I find the screenshots within the generated specifications to be one of the most useful features of Axure-drive specifications and a primary-driver for using the tool in my projects.


As such, I find the ‘Show footnotes on screenshot’ option the most useful feature behind the annotations tables and always have it selected. There might arise an occasion where a specification was required where just clean screenshots of the interface was required, free from any overlaid footnote references. This would be a perfect time to use this option.


The ‘Put border on screenshot’ surprisingly does just that, adds a solid border around all screenshots – not a favourite of mine and wouldn’t suggest you use it.

‘Do not scale footnotes with screenshot’ option keeps to the footnote markers the same size when scaling out screenshots. A useful feature if you plan to resize the screenshots,

image –>image

You can see the difference in scaling at not-scaling of the footnotes.

The last option, ‘Apply default OnPageLoad cases’ refers to applying the default ‘OnPageLoad’ event to the screenshot. This is useful when generating from a dynamic prototype which has an ‘OnPageLoad’ condition that you want to capture in the specification.

Annotations – the meat of the specification

As I mentioned before, the annotations are the single-biggest feature of the specification generation in Axure and a feature which turns the product from a useful prototyping application to a platform for managing the specification and design life-cycle.


This tab generates the tables based on the annotations for each page element/widget and provide a very powerful and automated way of generating field specifications.

As with the other tabs, select the annotations that you wish to include and the order in which they should appear. When correctly annotated and rendered into the word template, the above selection of annotations look like the following.


Defining the appropriate annotations to use in your project is another matter entirely and beyond the scope of this post, but the above should give an indication of how it can be used effectively.

Widgets – including dynamic options in the specification

There are likely to many cases where a prototype has been built with specific dynamic features built in that the client really liked and wants in the application. Seeing as they have already been built into the prototype, why not re-use what’s been done and expand on it for the functional specification?

The ‘Widgets’ tab provides such options for including the dynamic properties of widgets such as rollover states, drop-list options, and list box options.


Most of the options are fairly self-explanatory, if you use any of dynamic behaviours from above in your prototypes, then tick the option to include it within the specification.

Examples of such options within the spec are below.


Droplist values are vital if creating a complete functional specification.


Rollover states are also very useful within a specification to give context around a how a particular rollover works and what exactly happens.

If you have read my Replicating AJAX-style lightbox within Axure prototypes post, you should recognize the above rollover definitions.

One really useful feature I routinely use in my specifications is the ‘ Include List of Masters’ option. This provides a small heading and list of all masters used on the current page. Very useful if you are not repeating masters on every page which is normally the case.


The master list (although not styled in the above screenshot) adds the reference back to the pre-defined master and avoids you needing to repeat for each page.

Last but not least – 1 column vs. 2-column formats

The last tab is the ‘Word Template’ options which I detailed in my post, Axure specification templates explored and the only option I didn’t cover in there was ‘Generate Two Column Format’.

This feature does exactly what it infers, generates the specification into two side-by-side columns. To me, the obvious application of this if you are wanting to generate simplified specifications on large paper (A3+) where the field specifications and screenshot are displayed on a single page.


The above screenshot was taken of a two-column format specification.


Wow – that was a lot of content and a lot of detail, so I hope that proves useful to you all.

The aim of these posts is to convince people that using Axure as a platform for managing specifications and re-using prototype work is a very smart solution and can reduce a great amount of rework and increase specification accuracy.

I think my next post will target annotations and what to choose to get a specification both developers, testers and the client can all understand and find useful.


Axure specification templates explored

If you have read my other posts on generating specifications from Axure and the benefits of doing so, then you may want to delve into the world of customising spec templates and the various configurations options.

I am a strong believe in letting the application (in this case ‘Axure’) doing the laborious work for you and therefore increasing efficiency / productivity of your time. Creating a clean and professional looking template for Axure to work with goes a long way to removing the frustrations of writing specifications and allows the BA to focus on the analysis tasks at hand, rather than the idiosyncrasies of MS Word (an all too common problem!).

Most organisations have a standard word template or at least documents that have a consistent style that a template can be derived from, so finding one of these should be your first port of call. Once you have located one of these we shall jump right into the customising your template to fit Axure.

Hit ‘F6’ or click the generate specification button on the toolbar image to bring up the specification configuration options.

The bottom tab ‘Word Template’ allows you select a word template to import or edit the current template and should look like the following.


This dialogue contains the standard word heading and table styles which Axure uses in its template. To start with a pre-existing word template as your base template, select ‘Import’ and locate your .dot or .dotx word template mentioned earlier. This will import the styles and allow you to edit them to fit Axure.

Axure also has some nice professional looking templates you can use a base as well by selecting ‘Import Axure Template’. I would suggest you edit these to suit your purpose/client rather than using verbatim to give a more professional fit.


Axure has several clean-looking templates to select from.


The imported Axure templates give some great examples of how word templates can be used to generate great looking specifications, as demonstrated by the table style above.

Editing your base template

Once you have imported your template, either your company template or an imported Axure one, it pays to edit the styles to better fit the needs of your project and/or client.

To do this, select ‘Edit’ from the ‘Word Template’ tab of the specification configuration window shown above. This will open the word template and allow you to edit the relevant styles.

Once the word document is open, create some text to identify all of the Axure styles, apply the styles to each line and update them to how I want them to look. I shall demonstrate with screen shots below.


Here i have typed out Heading 1, 2 etc and them applied the style to the relevant text to see how they look. To display the style window like above in Word 2007 simply click the ‘expand’ button on the bottom right hand corner of the ‘quick style’ panel, as shown below (button highlighted in orange).


Now all the styles are visible, we can apply changes and them save them back into the styles for the template, which is read by Axure.

How do we do this? Lets see!

Lets take ‘AxureHeading’ for an example. I want to make this more prominent by giving it a horizontal line underneath and making it much larger.

Select the text for ‘Heading 1’ and click ‘Manage Styles’, a small button on the bottom of the ‘Styles’ panel, shown below.


Then ensuring ‘AxureHeading1’ is selected again, choose the ‘Modify’ option on the style panel, as shown below.


Now all the available options for that style are shown and here you can change whichever formatting option of the heading that is required. For the horizontal line under the heading, select ‘Format’ –> ‘Border’


and make sure the bottom border is applied to the paragraph, as shown below.


Now once the heading style is saved and applied the ‘Heading 1’ text on our template, it should look something like the following (or should apply whatever other formatting you applied to the template).


This process should be repeated for each Axure style and once you are happy with all your styles, save the template and return to ‘Axure’ to generated a spec and see how your new template looks.

Quick pointer: Make sure you delete the ‘Heading 1, 2 etc’ text that we put in the template above before you save. If you forget to do this the text will end up in all of your specifications and look out of place!

Table styles – the sometimes-tricky part!

If you have ever worked with Word table styles before you will know how fiddly they can be sometimes and other times it just seems to work as it should. I’m by no means an expert on the subject but I can at least run through updating a table style with some standard formatting for use in your Axure specifications.

As before, edit the specification by selecting ‘Edit’ from the ‘Word Template’ tab of the specification configuration options.

Create a small table to see your table style in action.


Now in Word 2007, there is a dedicated table ‘design’ ribbon which I’ll be basing it off, but if I have time ill go back and document how it looks in 2003.

Select the table and the ‘Design;’ ribbon should appear at the end of the ribbon.


The currently used table style is selected in the table style pane; right click it and choose ‘Modify Table Style’. This will bring up a similar window the style editor in the previous step, but with some formatting options relevant to tables (no surprises there!).


Have a play around with various formatting options in the style editor and be sure to apply different styles to the different parts of a table using the ‘Apply Formatting To’ dropdown. This allows styles to be applied to headers, alternate rows and columns and can make your tables look very smart.


I normally give the table header a coloured shade, bold/centred text and then give the ‘even banded rows’ a grey-ish fill to make them a bit more readable.

Play around with these until you have the look your after and then save the template again. Generate a new specification to see how it looks with your content and repeat as necessary.

Headers, Footers and Common Elements

Adding automated information to the headers and footers is another good way of adding professionalism and useful context to your specifications. Using Word features like Fields and Quick parks can add dynamic content right into the document without any editing.

Without going into too much detail about use of fields in Word and what not, I’ll just quickly go through some things I add to my documentation templates.

Start by editing the header/footer by double clicking where the header/footer lies. This opens up the header/footer editing pane.


In the above screen I have page number and total page number fields, the document title field and the date field. Ill quickly go over how to add the page number / total page number into the footer as an example.

Type the word ‘Page’ into the footer control and then select ‘Insert Quick Parts –> Fields’


From the fields window, select the ‘Page’ field and choose the number formatting.


That should input the current page number into the footer. Then type the word ‘of’ after it so nit looks like the following.


Then click the ‘Insert Quick Parts –> Fields’ option and select the ‘NumPages’ field and number formatting again.


and it should look like this.


That explains the process of adding page numbers, and its beyond the scope of this post to detail all the useful word tricks and fields, but I might follow up with a more advanced / detailed post on the matter.

Refine and Perfect!

I’ve shown you to how to customise and refine your Axure template to your needs, the next step is to refine and customise the template to your needs as many times as is required.

Once you have a solid base template to work from, it wont take you much to modify it to suit project per project or client per client.

Updated – AJAX-style autocomplete v2 .rplib available for download

I’ve had lots of positive feedback around the outcompete field for Axure RP and as promised I have packaged up into a master .rplib file for easily dropping on to your prototypes.

The updated version has a nicer transition and rollover effect and uses the name ‘Davidson’ as a base for completing the name (i.e. type ‘da’ and watch the suggestions menu drop down).

Download the following link and load into Axure:

AJAX-style auto complete file .rplib

Load into Axure via the ‘Widgets’ pane and selecting ‘Load Library’ from the drop down


Locate your file and then you should see the widget available in your Widget pane.


Drop that on to your prototype and away you go.


Replicating AJAX-style lightbox within Axure prototypes

In a post the other day I detailed how to replicate the always popular AJAX-style autocomplete functionality within Axure. In a similar vain, I wanted to replicate another popular AJAX-enabled function, the ‘lightbox’. Lightboxes are becoming increasingly popular on the web and by doing the legwork up front, you can easily drop a lightbox widget into your prototype to quickly demonstrate an idea to a client.

For those who aren’t familiar with the term lightbox concept, it is based around magnifying a thumbnail image to a larger, viewing-friendly size, while also hiding the background content from view. An example can be seen below.


The image has been enlarged and displayed within a dark frame to bring out the contrast of the bright image.

Modern web lightboxes also have gallery-style navigation controls built into the image to allow scrolling through a series of images with a ‘forward’ or a ‘back’ arrow. This way you can stay within the enlarged lightbox view and navigate through an entire album of images.

All of these functions are incorporated into my Axure widget, including the all important ‘close’ button and done in a user-friendly way that replicates modern design standards.

Let us begin

Now that I have set the scene, let us delve into how to build the widget in Axure.

First we need a placeholder page to store the thumbnail images and I like to add a few other page elements to make the demo look a bit nicer. My demo page looks like this:


See nothing too flashy; just a set of three thumbnails, a title and introduction.

Next we need to drop on a dynamic panel which will hold our lightbox and fill our viewing window. This needs to overlap the whole page and be brought right to the front (right click panel –> Order –> Bring to Front ).

This panel will be blank by default (i.e. not shown) and then a state for each image you require. In my example above, we require 4 states ( default + 3 image states).


Leave the default blank and open up the second state which I’ve named ‘display image 1’.

This state should have the same image as the thumbnail in the centre of the screen, at a size almost filling the screen (from top to bottom). Then use a rectangle shape with a fill colour of a dark grey or something similar all around the edges of the image. It should look like my example below.


You cant see it in the above screen but I have another dark rectangle shape below the image as well, in the same proportion as the top border.

Repeat this for the other two panel states, but changing the image to the relevant thumbnail image.

The flash part – navigating through a lightbox gallery

While the above may be sufficient for your needs displaying a single image at a time, most lightboxes out there in the real world have controls overlayed over the images to navigate.

To replicate this in Axure I have used a few tricks to capture the rollover action and display a button only on rollover – just like you’d find on the web.

First, if your using Axure 5.6 like me, your able to use a brand new feature of this build called ‘Slice Image’. Now you can slice an image within Axure without having to resort to cutting up your image in a photo editing tool like Photoshop or Paint.NET.

To do this, right click the image within the first lightbox state and select ‘Edit Image –> Slice Image’. You should be presented with a crosshair style cursor which to use to carve up your image into sections. For our purpose, we want to split it right down the middle, leaving a little section at the top (the reason for which will be revealed shortly).


I also split the top right ‘section’ of the image in half vertically again, but that isn’t required at this stage (or easily done at the end).

Now what we have is essentially four separate images, where we can assign different behaviours to each.

What we want to do now is give each section a different rollover image that is the same image + an icon overlayed. That icon will either be a ‘forwards’ arrow, ‘backwards’ arrow or a ‘close’ symbol depending on the section of the image. The fourth section can just be left blank or assigned to another action I haven’t thought of!

Making the rollovers

At this stage you might be worried that making these rollovers is a bit tricky? Not at all!

My process for adding an icon and setting it as they rollover is easy. All you need is the ‘Axure Icon Library’ available from the resources section of the Axure site and an image editing tool like Photoshop or the freely available Paint.NET (I use the later for licensing reasons!)

Now I drop the icon on to the relevant part of my image and copy both the icon and the base image to the clipboard and paste them both into Paint.NET (or your preferred tool – MS Paint works fine). Your ‘paste’ should look like the following.


If you look closely, you can see the blue arrow to the left of the image. Save the image as a .JPEG and return to Axure.

In Axure, setting a rollover image is easy, and seeing as we have made it already, we just need to point to it and its done.

Right click the relevant section of the image and click ‘Edit Image –> Edit Rollover Image’

Select ‘Import’ and choose the image you saved from the previous step.


Using the ‘preview’ option is a good way to make sure everything lines up correctly.

You need to repeat this for each image, so that each lightbox image has three rollovers – forward arrow, back arrow and close. I use the following icons from the Axure Icon Library.


Once all of the rollovers have been added, its time to add some actions to them so they become useful.

Adding actions to the rollovers

We have the lightbox, we have the rollover images and finally we need to make those buttons we added actually DO something.

Achieving this is not as simple as I had hoped but wasn’t long before I figured out a way.

The complexity comes because  the button is only on the rollover image and as its not in a dynamic panel, there isn’t a way of assigning it an action. We also want to only perform the action on the ‘click’ action not the mouse rollover, so I needed a way of mashing the two together

Luckily Axure provides us a workaround in the form of variable.

I created a variable called ‘RollOver’ and the idea is that when the Rollover action is fired, the variable is set to ‘true’, and when ‘false’ when it isn’t.

Then on the click action, create an event to change the panel state to the desired action (either return to hidden, show image 1, 2 or 3) BUT with the condition of RollOver=’true’.


Lets walk through it.

On the image section your working with first, assign the following action of the ‘OnMouse’

Set the variable RollOver to ‘true’ (a condition is not required for this action)


Now that the rollover status can be captured, we can assign an event to specifically the rollover image with the button.

Create an ‘OnClick’ action for the same image section as before, but this time give it a condition and an action. The condition will check to see if rollover is ‘true’ then change panel states to the relevant state.

Mine looks like this.

The condition.


and the action.


The above action is for the ‘next’ button of image 2, so the logical action is to display the panel state for image 2. The close button should always return to the default (hidden) state, and the previous and next buttons should move logically to the correct image in the order.

Ultimately you will end up with three rollover images per image, each assigned an appropriate action. Repeat the above step for assigning an action to the rollover for each of the 3 sections, for each of the images (or lightbox states).

My screen flow looks like following.

image image

Start with the thumbnails                  –> Show lightbox with first image and next rollover

image image

Clicking next icon displays image 2        –> Clicking next again displays image 3.


Notice the ‘close’ symbol in image 3, it closes the lightbox.

There is one other action you should add for the sake of completeness and that is setting the rollover value to ‘false’ again for the ‘OnMouseOut’ action. This will be disable the click event when the rollover is not shown. I won’t detail how this is done – if you’ve made it this far it should be fairly intuitive as to how to do this – if not ask me to add it in!

All finished!

There we go, all finished! As with my other AJAX-replicating widget, all the work is done up front and only needs to be modified with different images / rollover images in order to customize this to your prototype.

I have this widget as part of my custom library and just drop it on to a project as necessary. I have even found it useful when in interactive sessions where I drop it on to a page to illustrate a discussion point or design concept.

Hope you found the above useful and as with my other AJAX-autocomplete, I have not uploaded the .rp or .rplib files but can do if anyone requests.

I’m working on a Axure AJAX-toolkit for various widgets so will bundle them together and offer soon!

From prototype presentation to functional specification

Building a prototype for a presentation is a great way for clients to ‘visualize’ your design concepts and impress on that first meet and greet. Mocking up a quick design prototype in Axure from RFP or tender requirements is quick and easy, and most importantly, reusable!

Traditionally creating such a prototype has limited reuse and then only if built with reuse in mind. The advantage of using Axure is that the prototype can then be reused to generate a fully fledged functional specification.


Using Axure’s amazing specification generator and the user interface built for the prototype as a base, the additional detail required for a detailed functional specification can be quickly added.

Defining the specification fields

Every project  is different, each specification is different and consequently most functional specification templates will be different. My usual practise of finding out what is required from a functional specification is to come up with what I think is an appropriate template and sit down with the technical lead project and find out what he and his team need.

There should always be enough specific detail captured in the fields you define that the development team can build the application to specification (not a reality in a lot of organisations but certainly a good mark to aim for).

The ‘base set’ I tend to use are shown below.


Then depending on what technology the project is working with and the requirements of the development team, additional fields will be added to further refine the specification.

Defining what annotations are available, select the ‘Customize’ option on the Annotations pane to bring up the ‘Customize fields and views’ screen.


So how does the above information look in a generated spec? Lets see!


The detail is formatted within a data table with a number reference back to the annotated interface above it.

This table can be changed, or a supplementary table added beneath it, by changing the ‘Word 2007 Specification’ options


Non-user interface components? No problem!

Parts of your system will not have a user interface and the assumption is an Axure-generated specification will omit them entirely. Not true!

With a bit of forward planning such sections such as permission-ing, back-end systems and integration points, can be dealt with in Axure without the need of a user interface.

Rather than building your interface first and annotating field specifications from that, ignore the field elements on use the ‘Page notes’ or create additional annotation fields specifically for  non-interface sections. When generating the specification, Axure has the option to ignore fields that are blank thus removing it from all the other pages.

To add more ‘page notes’ to your project, select ‘manage notes’ from either the ‘Wireframe’ menu at the top, or the arrow on the page notes & interactions pane at the bottom.


From this interface you can add as many ‘note’ fields as necessary. I tend to add one per section as if i was creating word document manually.

Then to ensure they are generated in the specification, check the newly added notes are included in the ‘Notes’ section of the specification configuration, as shown below.

Ensure ‘Show Note Names’ to pull the headings through


And once the specification is generated into a word document, it looks like this (ignore the styling – we can jazz up the boring default word styles anytime!)


Annotated screen and user flows

I have also used this approach to providing context to screen flows within a specification by providing business and validation rules alongside the process flow.


Advantages of generating the specification

So why generate a functional specification you ask? What advantage is there over writing one from your favourite template?

  1. Consistency across screens – Consistency of business rules, field specifications and even naming conventions across multiple user interfaces can be quite an overhead when working manually with a large specification of 50 pages or more. Axure provides ‘masters’ for defining reusable content, select lists of predefined options for maintaining consistency and automatic numbering of all annotations.
  2. Save time, copy-and-paste! – Many fields tend to be repeated across screens with slight differences that can be defined once initially and then copied onto the required screens. This action retains the details defined for the field when copied cutting the work down to only the changes required.
  3. Automatic field numbering – Axure handily numbers all annotated fields automatically as you define them providing with an unchanging number reference for each user interface. (They can renumbered again later but they will never be updated by Axure). Axure also prints these field ‘numbers’  on the screen generated in the specification to give a quick reference to where it appears in context.
  4. Select lists! – although strictly speaking another measure of consistency, defining field annotations as select lists allows further governance on allowed types and reduces the amount of rework required when working across a distributed project team. It also has the benefit of being much easier and quicker to use – further enhancing time efficiency!

    Tracking changes across generated specs

    A handy pointer I’ve come to learn when dealing with generated specifications.

    If you rely on Word’s track changes functionality like I do for reviewing documents, then generating specs will not allow you to ‘track’ the changes as a completely new document is created each time.
    To get around this, I use another powerful Word function, ‘Compare’. Ensure you save the new and existing copies of the specification separately, and from within the ‘Review’ ribbon of Word 2007, select ‘Compare (not Combine!)’. Select the old and new document and compare away!


    This has helped identify deltas (changes) in generated documentation in other software as well, not just Axure.

Hope the above was useful – it is a wee bit more detailed than my posts to date, so hope it wasn’t too much to take in.

Creating AJAX-style auto complete functionality within Axure prototypes

I am currently building a prototype for a client which early on requires a demo to users of the system, and I really wanted to put the time into building a prototype that was as realistic as possible. With that in mind, I wanted to build an Ajax-style auto complete field that demonstrated the functionality and potential use of the field in the system.

The idea was to just build a simple text field for ‘first names’ with a dynamic panel that would refine the options based on the input – standard auto complete functionality.

So drop on a text field and a label, name them to distinguish what field is what, then put a dynamic panel underneath the text field, as shown in the screen shot.

Building the groundwork


Now the action we want to capture is the entering of data into the text field, and for this purpose, Axure provides the ‘OnKey’ action. Typically auto complete fields are shown after a few characters are entered, so I setup mine to display after two characters, then display a drop down of 5 results.

So in your dynamic panel, line up a table displaying 5 results that will sit just below the text field. As a useful extra, I bold the first two letters to give more context to what’s happening.


Handy Note!

To help line it up underneath your text field, go back to the ‘page’ view when only have one state for your panel, and you will see the list in context and allow you to place it.

Now we need to add some more panels for each extra character typed. For my example I have five in total, each with a slightly refined ‘results’ list.

For every panel state, the list gets refined a little further, an extra letter gets bolded, and there should be an extra panel or two for ‘selecting’ an option.


Creating the logic & displaying the panel states

Once all the panel states are complete, the interactions are created on the page, using the ‘OnKeyUp’ event on the ‘First Name’ text field.

Add an ‘OnKeyUp’ interaction with two conditions:

Length of widget value – set this to ‘2’.

Text on widget – set this to the fist two characters of your results set.


and set the action for this to be the panel state created first, which shows the 5 results.


The panel for selecting an option should both highlight the option being selected and put the selected word in the text field.


The above screen shows the selected option highlighted, and the ‘OnClick’ action for the selected option uses the ‘Set text on widget’ action to set the text field to the selected option.


This needs to be repeated for the other panels, but changing the length and value conditions.

The overall interactions window should look something like the following.


The finished product!

The final rendered version should look like the following and work flawlessly!


This process can be repeated for other results sets / inputs to give more than one scenario, but generally no than two scenarios are required for a prototype.

If anyone wishes to get a copy of the .rp project or the .rplib for the master, I can put this up as well.

Happy prototyping!

Using raised events for mixing up your masters

I’ve been playing around with making my current prototype more usable and dynamic in the last few days and have come across a cool but not well documented feature of  ‘raised events’. Essentially it allows you to add flexibility to your master’s in able to change page by page, and allow you to capture events fired inside a master (im sure there are more/better uses of raised events!)

I want to quick run through my scenario to demonstrate how you can capture an event within a master and apply it at the page level.

First up I have a ‘Logged in user’ style master consisting of two stages of dropdowns for  logged in user and ‘company’. Ultimately what I want to demonstrate is when I select a new option from the dropdown list (held inside a master)

Without this notion of ‘raised events’ there is no way of capturing the ‘OnChange’ action for the dropdown within the master, on the page you want to update.

Let me demonstrate with pictures below:

The user select’s his company from the following dropdown (which is contained within a master

Choosing an option for this drop down changes the text label with the selected option – pretty basic web application behaviour.

So changing the drop down changes the value of the bold company name in the text label above.

All of this seems relatively easy so far, but because the drop down is stored in a master within axure, there is no way of accessing the ‘OnChange’ variable from within the page (and therefore no way of telling when the user changes their selection in the dropdown.

The way of getting around this to use a ‘Raised Event’ within the master, which creates an action that can be captured on each instance of the page.

Let me demonstrate. First let’s show the page in the axure workspace.

The pink (red-ish?) section indicates the dropdown part is contained within a master; the rest of the page is directly editable.

So because we want to capture the action of user selecting a different option in the dropdown, the only we can do this is within the master itself, NOT the page.

Now we cant access the text label on the previous page within the master (and we may wont do different things on different pages), so we need to create a ‘raised event’ to capture the value of selected option and store it in a variable.

Add a variable (I call mine ‘selectedEmployer’) from the ‘Manager Variables’ option on the ‘Wireframe’ menu.

Now we have a variable, we can store the value of the selected dropdown option when the ‘OnChange’ action fires.. and also fire the special ‘Raised Event’ action so we can call it from our pages.

Alot to take in? Lets walk through it.

For the ‘OnChange’ action of the drop down list (within the master),  add an interaction case, and switch to advanced view (can do in basic view, but screens reflect advanced view)

For the action we want to do two things: captured the value of the selected dropdown value and store it in our variable AND fire a ‘Raised Event. The two actions in Azure you need to do this are:

‘Set value of variable and widget value(s) equal to value‘ AND

‘Raise Event’

First, set the variable to the selected dropdown value.

The logic should be fairly straight forward but is shown above for reference.

Next we need to create and fire a ‘Raised Event’

All we are doing here is creating an event that can be captured when the ‘OnChange’ fires, as we have no way of capturing the ‘OnChange’ action when we leave the master. Confused why we need this? All will be revealed when we try to access the action next.

Head back to the page we are working on and select the dropdown master within the page.

We can see the name of the ‘raised event’ we create and fired in the previous step (mine’s called changeEmployerName)

Now all we have to do is get the value stored within our drop down and do what we want with it on the page.

So within the ”changeEmployerName’ event, we want to create an action with the following condition:

‘if selected option of Log on Bar/Employer dropdown equals “[Value]”‘ – obviously changing [Value] to the appropriate value for your context

What you do once you have the value is up to you, I normally set the state of a dynamic panel show the result on the page, but there are many more applications.

Hope this helps when trying to make your prototypes more dynamic and like-like!