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.