30 Mar 2018 - Axure Tips
TL;DR: download the handy library I made for tall lightboxes 👍
Can we have a lightbox?
Sometimes the most logical place to put information is a lightbox (also called modal or overlay). Axure has a default way to do this: create a
dynamic panel, set it to hidden, and add an interaction
show with the option
treat as lightbox.
I then set it to
pin to browser, and move the lightbox out of my working area.
This works quite nicely, except when the lightbox is taller than the screenheight…
Why use pin to browser?
Lightboxes are usually placed in the middle of the screen. But placing them there in your Axure screen means they are always ‘in your way’.
- create dynamic panel (
dyn_lightbox, see my post on naming)
- set to hidden
- move to the right
- set ‘pin to browser’ to
top on the
always on top
This way you can keep prototyping your page without this lightbox interfering.
The problem arises when using a tall lightbox on a small screen. For instance a lightbox that contains a preview of a document. Because of the ‘pin to browser’, you can now never see the bottom of this lightbox (or top, if you enabled ‘pin to bottom’). You can see the problem in action here
I’ve made three solutions to the problem:
- move the lightbox: instead of relying on ‘pin to browser’, we move it ourself. The benefit is that you have full control. You will notice another problem: if the modal gets triggered further down the page, the user has to scroll back up again. This I fixed in iteration 2.
- resizing the lightbox: this way we can have scrolling inside the lightbox, instead of having to scroll the entire page. Downside: you can scroll inside and outside the lightbox. That’s a bit messy. As a bonus, I’ve managed to disable scrolling 🤓. However it does not work smoothly on OSX/iOS due to bouncy scroll 😒.
- rolling our own Of course you can always build your own lightbox! Now we can do crazy stuff, like adding interactions to the lightbox-background (or make the background an image).
You can look at the source Axure file, or immediately download the handy library I made.
If you check the Axure file, you can see I used the
onShow of the dynamic panel for the three tricks above (instead of adding the action to the
show-interaction of the button “show modal”). This means I can trigger the lightbox easily with different buttons.
This is part 3 in a series, you can read part 1 here and part 2 here.
24 Mar 2018 - Axure Tips
This is part 2 in a series, you can read part 1 here.
Document what you’re doing
With Axure you can do crazy things with interactions. Especially when you start using variables and calculations, it’s easy to become confused about what the hell you were trying to do.
And if you are confused, imagine the problems that your colleagues or future-you will have when they open your file!
So help yourself and others, and document what you’re trying to do!
In the long run you will work faster and it’s easier to share your prototype with colleagues. Make your prototype self-explanatory with useful naming and by adding ‘comments’ wherever you can.
Naming and shaming
When you name your elements, they are easier to find in the search bar or in the case-editor (where you add your interactions). Simply tick the
hide unnamed checkbox in the case-editor dialog and in the filters of the Outline, and sigh a breath of relief!
To make my life in Axure easier I have a naming convention. I start each element by indicating what it is:
l_ for labels
dyn_ for dynamic panels
img_ for images
i_ for input-fields
b_ for buttons
r_ for simple rectangles / paragraphs
calc_ for control elements (more about that in another post!)
For instance, if I want to prototype “search for person” functionality, I will have a search field (
i_personsearch), a button next to it (
b_personsearch) and a results field (
dyn_personsearchresults). When a user presses
b_personsearch, I’ll change the state on
Only label the things you need labeled! Don’t waste your time labeling everything!
Document your interactions
When you make awesome prototypes all the crazy stuff happens in your interactions (
onresize, etc.). That’s why you really want documentation there! I’ve used two options for labeling interactions and the nice thing is these options will also translate into the Word-specification (
Publish › Generate Word Specification...).
Two ways to document:
1. Abuse the ‘case-name’
I abuse the case-name to describe what the purpose is of interactions. By adding multiple cases you can describe what each part does (note that you will need to toggle
2. Use the notes panel
The notes panel is the place where you ‘officially’ add documentation of what you’re doing. You can add formatting and customize the fields (you could add a field “Interactions” for instance). It has two downsides:
- easy to overlook: it’s in a separate tab from the interactions
- by default it adds ugly blue ‘notes’ icon in your interactive prototype (turn this off in the generator options, “Widget Notes”, “Include Widget Notes Footnotes”).
Don’t use the interaction ‘miscellaneous / other’
Another trick I thought was great was add a
miscellaneous › other-interaction in front of every interaction is not self-explanatory. The sad thing is that this sometimes triggers an
alert, so I no longer use it 😒
That’s it for now, more tips will follow!
This is part 2 in a series, you can read part 1 here.
14 Mar 2018 - stronk
A small annoyance of mine is fixed: it’s now possible to filter the recommendations part of this site.
13 Mar 2018 - stronk
This blog was always “© all rights reserved”.
But most stuff I use is opensource and it’s time to give something back! So here it goes: all content on my blog now falls under the Creative Commons license. Have fun with it!
No commercial use?
For now I’ve decided not to allow commercial use. This means the site is not truly ‘Free Culture’, but it somehow doesn’t ‘feel right’ to me to allow commercial use. I’ll think about it and maybe update the license in the future anyway 😊
I’m very proud to have this icon on my blog now:
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
12 Mar 2018 - games
This is number three in my series of ‘home-made’ games (part 1, part 2). I developed these games for scouting for a big group to get to know eachother (“ice-breakers”).
That’s not my secret!
materials: pens and small pieces of paper
The group is split into two equal groups and everybody writes down two secrets (“I love Justin Bieber”, “I sucked my thumb until I was twelve”, “I love death metal”, “I was once in jail”, etc.) on two separate pieces of paper. Write clearly, because someone else has to read them! Everybody keeps one secret and hands the other to someone else within their group. No peeking 😊
The two groups then face eachother in two lines and now the game begins!
Based on a coin toss one group starts. One person from the group reads his two notes with secrets (one from himself and one from a team-mate) in a random order, it is now for the opposing team to figure out which of the secrets belongs to this person. They may ask one question and then have to decide.
The person reveals if they were correct and to whom the other secret belonged. The team gets a point for guessing correctly, and the other team then gets the turn.
I took a finger to the knee
materials: a pen and small pieces of paper
Write down the names of everybody on small pieces of paper. Hand one paper to everyone in the group. Now everybody has a random ‘name’. The goal of the game is to touch the knee of this person. If you succeed, you get the piece of paper of this person and you continue. The person with the most pieces of paper at the end of the game has won.
There are two variants:
- the quick-version: start with a whistle and time it for 10 minutes
- the slow-version: the game lasts an entire weekend