How to hack InVision for more authentic popups
InVision is a great prototyping web app for creating screen-based prototypes super fast. You’re probably familiar with it, even if you haven’t tried out their most awesome features such as Inspect or synced your screens directly from Sketch with their Craft plugin.
I‘m quite ok with the inherent limitations of InVision’s screen-based system — it forces me to concentrate on high-level flows and helps me not get lost on the finer details until I’m further in my design process.
Completely screen-based prototyping makes it hard to bring in some commonly used components though. It’s hard to create sidebars, system dialogs, popups, popovers, modals…stuff like this:
However, InVision does have the Screen as Overlay feature to solve this. You can export only the popup contents as a screen of it’s own, and open it on top of any other screen instead of actually navigating to another fullscreen view. InVision allows you to tweak the screen positioning, transition animation, backdrop opacity and other properties quite nicely.
Why? Animated overlays provide a more authentic demo of the end-user experience, and you can use the same popup over any screen while maintaining scroll position. You’re going to save a lot of manual work exporting popup screens.
There’s a bizarre limitation to how these overlays work though: InVision sets the backdrop color for you, you cannot define it manually! As a result, a system dialog in InVision will look like this:
I can’t really understand why on earth InVision would default to a light background, since using a dark backdrop behind a white popup to increase contrast is an incredibly common pattern and used even in Android and iOS system dialogs and panels. Bizarrely, InVision does let you choose the color in desktop projects, but not on mobile 😲.
Setting the right color for your overlay is important. It makes a popover actually usable, and a carefully selected backdrop style can help really drive home the look & feel of your app.
We need to figure this thing out.
Finding a workaround
I started looking into this the same way I start looking into anything: complaining about it on Twitter.
To be fair, InVision did follow up with a prompt response, even if it was just to tell me to file an issue. Fair enough — I filed one, and was happy to get a not-totally-canned response:
Ok, so… let’s look at how this works:
Background color is determined automatically based on the colors found in the bottom corner of the screen. If you use transparency this could essentially be any color in the image since InVision doesn’t really know where to pick the color from.
I kinda get this but… not really. I though it was just a case of a bad default, but it’s not. How is this behavior in any way predictable for a user?
Based on some testing, which I absolutely expect no one else to do, InVision does indeed look at only the bottom right corner to determine the color they want to use. They will choose a hue from your image, and then respect the opacity value you set in the prototype. It’s a weird combination of unintuitive user configuration and badly documented background magic. I’d definitely do this differently.
But this is also good news: there is a mechanism for setting a specific color for your overlay, you just can’t do it directly via their user interface.
Since InVision only looks at one pixel in my image, I can include a reference pixel in all the images I export to InVision and let the app pick the color I want from there. If I simply want a black faded backdrop, I can also make that reference pixel nearly transparent, but if I want a specific color hue, it’s better to leave the pixel fully visible so InVision can guesstimate the hue you really want.
The end result looks like this:
I think the literally one buggy, weird pixel is better than having the entire overlay being messed up. I didn’t use this in a user test yet, but to me it’s barely noticeable in actual usage and the more translucent your backdrop is, the less of an issue you’ll have with this.
As I mentioned, you could also use fullscreen view with the settings view “hardcoded” in the background, but this way you can’t animate the overlay and popup separately, use it over another screen or maintain the scroll position of the background view. I’m gonna stick with the hacky pixel for now.
Summary
Screen as Overlay was pretty much useless to me up until now, so I really hope the guys at InVision fix this small weird aspect of the product soon. But at least I can hack around this and not get blocked using this otherwise great tool — and now you can, too.
Next time I’ll complain about the overlay screens not supporting scroll behavior like all the other screens. Unless they fix it before I feel like writing again - which I’d definitely prefer!
Thanks for the read
You can read more about my work as a product designer and developer on my site at jerryjappinen.com or follow me on Twitter. Thanks for reading! 🖖
