Creating a prototype with swipr

First of all, a very happy and succesful 2007 to all of you!

I've had a number of questions about how to create an actual prototype with swipr. The normal output is a clickable version of the sitemap or screenflow, with popups for all the wireframes. Within the popup window it is possible to jump from wireframe to wireframe, but people would like to show the prototype in a normal browser window, instead of in the popup. Of course, this is possible, and I'll show you how to do this here.

In the 'normal' export of swipr, a popup window is launched everytime the user clicks on one of the screen elements in the swipr screenflow/sitemap. This window opens the file fd_popup.htm with the screennumber as its argument.

To have a prototype that does not work in popup screens, you will need a new copy of the fd_popup.htm. This is a very stripped-down version of the original, without any of the tabs to show additional information. The only thing this new version does is load the correct wireframe image, plus it's related imagemap, based on the screennumber argument. This means yu will always need to start your prototype with a call to this new fd_popup and a valid screen number as its argument.

The way I normally do this is by creating a new 'prototype' directory on the same level as the wireframes and comments directories. You place the new and stripped-down version of fd_popup.htm. Then, you edit the title page for the swipr screenflow. This page normally contains a link to page 00 (or whatever is the first page in your sitemap/screenflow). You can add a new link to open the first page of your prototype. (see image below).


This will open the first page in the same browser window, and WILL NOT have any of the tabs that a 'normal' swipr wireframe has. An example can be found on the swipr website.

I hope this will help you in creating a proper prototype using swipr.

Hyperlink locations are off

I have received a number of reports of mis-aligned hyperlinks within the swipr-generated output. (BTW, I need a good name for this output, anybody got any ideas?). The problems can be traced back to two seperate causes.

Cause 1: Text objects are extending beyond the exported image.
If you select all objects in the page, you will notice pink outlines for all objects. See if you can determine the left and top edges of the exported image (compare it to the wireframe image), and then check if there are objects extending to the left and/or top of those edges. If any of the objects extending these edges are NOT on the 'no_export' layer, you have found your problem. This is normally caused by text objects that have a non-text part of the object extending above or to the left of the image. make sure all borders of text objects fall within the visible edges of the epxorted image.

A quick insight into how swipr creates the imagemap file that sets the hyperlinks:

1. Determine the upper left corner of exportable objects - For the current page, and all of its background pages, determine the upper left-most object. For text objects, this is the left top corner of the object, which is not necessarily the left top corner of the text itself;
   
2. Find hyperlink objects - cycle through the objects on the current page and all background pages to find objects on the prototype layer and the comment icon layer
   
3. Calculate location of hyperlinks - do some complicated calculations to convert internal Visio-based (bottom-left) locations to pixel-based (top-left) locations and dimensions;
   
4. Write imagemap file - write this information to a javascript file to include in the wireframe popup.
   

In the first step, you see the left top location is calculated on the basis of a text object's location and size. However, when Visio exports images, it will only export the visible portion of a Visio page. This means that there is a differnece between the calculated left top corner and the actual exported left top corner of the image, when a text object stretches beyond the visible left or top border.



So, make sure all text objects are within the visible borders of the exported image, either by moving them, or by extending the exported image to include the full text object.

Cause 2: A non-standard DPI setting of the computer's display
A new problem that came to my attention this week is when the computer display's DPI setting (the resolution) is set to a nonstandard amount (120 dpi instead of the standard 96 dpi, for instance). Swipr does not react nicely to this. The screenflow part of the export is fine, it has taken the dpi setting into account, but the wireframe output does not take that into account.

For now, the only work-around is to do the swipr output generation on a machine with standard dpi settings.

I hope this solves some of your problems!