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!

Axure RP and Source Control with Subversion

If anyone out there is using or has thought about using Axure RP Pro for a project and stumbled at the source control hurdle, or decided against it for lack of source control support, I challenge you to read this post and still disagree. Axure RP is a great application that when used well can create great prototypes to ‘wow’ the client and then with a single click  generate annotated specifications.

The common question I hear is what about source control and scalability to more than a single person team?   For a project I worked on last year I had to come up with a process for managing Axure content with a 5 person BA team and retain and backup all version history. A quick google and flick through the help didnt prove all that useful so I dove in and have compiled a few steps from what I learnt.

Creating / Configuring the Subversion (SVN) Server

First step is to configure (or create if your organisation does not already have a managed SVN service) your source control server, which for ease of use I generally use Visual SVN Server and keep it on a stable server that isn’t handling much load already. Install Visual SVN Server from http://www.visualsvn.com/server/download/ and configure as per normal.

Only option to change from default is to use integrated windows authentication – this saves you have from having to manage users, but if security is an issue, then it may be desirable to have user management within SVN.

Creating the Repository

Once Visual SVN is installed you should be presented with the Visual SVN Server Management Interface, as shown below.

The screen above already has a a repository created but let’s run through the process of setting one up.

From the ‘Repositories’ menu, right click and select ‘Create New Repository’.

Enter in the desired name ensuring not to include any spaces. I generally go for the ‘underscore’ format, e.g. Example_Axure_Proj_03

Once created there should a new repository in the overview window and on the left hand pane, as below. This will be the repository for all Axure content.

Right click on the newly created repository and select ‘Copy URL to clipboard’ as show below.

Now we have our repository setup and we have the URL to it, we can jump into Axure and create a new Shared Project!

Creating a Shared Project in Axure

Creating a shared project in Axure is reasonably easy process, much like that of creating a standard new project with an additional step.

From the Axure file menu, select ‘File -> New Shared project’

The ‘new shared project’ wizard will open and ask for a shared project name. This can be anything and is only used locally.

The next wizard screen asks for the location of the ‘Shared Directory’ so paste in the URL from the above step (if it does not come through, go back and repeat the step to copy the URL to the clipboard). Note: You can use a normal shared directory location for this, but using a SVN is more secure and gives you more control, particularly if you already have a managed SVN Server!

Axure will the confirm the repository is ok and everything is in order and then prompt the user for a local working directory, choose whatever you like for this. It will also prompt for credentials and depending on whether you used integrated authentication in your SVN setup or not, enter the relevant credentials.

Checking in / out and version history

Now that versioning is enabled and you are working from a ‘shared project’ the source control concepts of checking in / out now apply. Now items can be edited until they are first checked out the user and now item can be checked out to more than one user. These concepts should be very famailair to anyone who has used a source control or document management system before.

When checking back in items the a summary prompt will be displayed indicating all items that are being checked back into the source control and subsequently visible to all other authors.

All done!

Well that covers the basics of source control with Subversion (SVN) and Axure RP and with this combination you will be able to scale out Axure projects to multiple authors working of the same source and lock down editing permissions.

One other thing I usually do is write a simple batch file to do a daily backup of the repository store on the C:\ drive to a network share or document management system to give more redundancy and peace of mind. This way you can always create a new repository with data from a particular day and recover data from any day within the project lifecycle.

Prototyping and spec generation with Axure RP

Axure RP and making life easier

As a business analyst in the web arena, a large part of my job is building and spec’ing interfaces for web applications. While this can be done with the standard office suite (Word and Visio), I always like to use gadgets and tools that can make my life easier. Axure is a prototyping, wireframing and specification application that can make designing web applications faster and also more enjoyable.

Axure RP provides a WYSIWYG, drag-and-drop interface by allowing the user to drop widgets onto the workspace and assign them proeprties. See the standard user interface below (with branding removed):

Interfaces can be built page by page, using these easy and familiar style. Concepts such as master pages can be used for reusable content such as headers, footers and navigation menus.

Building wireframes is only part of the functionality though, with the real weight coming in the form of field/widget properties and dynamic actions for prototypes.

Let’s start with field/widget properties and how they can greatly speed up specification generation.

Widget Properties and Spec Generation

A simple  scenario would involve the wireframes and specification developed independently in Visio and Word respectively. This leaves a lot of room for inaccuracies and inconsistencies across the two work products and requires greater effort in QA and governance to keep them aligned.

With Axure the two products are generated from the same source, within the same application and as a result will always match each other. Every element on the Axure canvas has a set of user-defined properties which are used to populate the specification when it is generated.

Each of the above properties can be defined by the user to meet the application needs (I have included a few staples above). Defining properties using select lists and number formats can increase the consistency of the generated specification. Below is a shot of the interface for defining widget properties.

Once you have your property list and have assigned values to all the elements, generating a specification complete with these properties is as easy as hitting ‘F6’. An example of a generated spec can be seen below.

The template that the specification is generated from can easily be edited to change values that are displayed in the spec, as well as heading and font styles.

Axure has a number of other useful features, which i haven’t covered in this article. Next I hope to cover dynamic panels and interaction’s for prototyping and source control using subversion and my backup process.