The microwave at my old apartment had a voice memo feature. Microwaves are the classic example of an interface that is more complicated than it needs to be. Microwaves have so many buttons, and most of them are never used. On better-designed microwaves, there’s a button “Add 30 Seconds” which will immediately start the microwave and set the timer to 30 seconds. Pressing it again adds another 30 seconds. On microwaves that have this feature, that’s literally the only button I ever press!
My ideal microwave design would be one that I could jab with my hand, and it would activate. I should be able to poke in the general direction of the microwave and have it start. There’s only one function I ever want, that button should cover a large portion of the front of the device.
I find the same is true in my car. Sometimes I need to use the light on the ceiling, and usually it’s dark when I find myself in that situation. When I look up at the area where the light is, I’m presented with a range of knobs, switches and vents. A nice big button I can punch would be the ideal interface.
The worst offender of all is payment systems. The entire experience of paying for things is usually really bad. If you go to a store, you’ll wait in a line. Then you’ll be asked a series of questions like “Do you want to sign up for our rewards program?” before swiping your credit card, only to be told you need to insert your your card into a slot instead. Then you’ll sign a paper receipt. It’s another situation where the ideal experience would be one where I throw a handful of money in the general direction of the register as I walk out. If you want my money, make it a low-friction process!
These situations illustrate a principle I try to keep in mind when designing software. When appropriate, go to great lengths to simplify the interface to the point that if the user just stabs at it, they will probably get the result they want. Extra options, buttons and text just create opportunities for mistakes, confusion, and slowdowns.
If you find yourself creating a multi-step process, or asking a user to choose from a range of options, or to provide a plethora of data, consider whether you can simplify the process to a single step, button, or piece of data. It will probably be hard to figure out a clean way to make it work, but you only have to do that work once. Your users have to deal with an overcomplicated UI repeatedly for the life of your software.
When something becomes easy, people go crazy with it. Desktop publishing made it possible for anyone to print a flyer, and it was seconds before someone decided it would be fun to include as many fonts and clip art as possible.
When something becomes easy, people go overboard.
As it becomes easier to design animated prototypes using tools like Flinto for Mac, there’s always a concern that people will overdo it. When it’s easy to make every element on a screen fly in and bounce all over the place, why not do it? It’s so much fun!
Your customers will hate you.
There’s a time and place in your UI for loud animations. Just as the best print layouts make use of a small amount of carefully chosen fonts, the best UI animations tend to be the subtle ones that people barely notice. They advance the utility of the UI. Animations can and should help with the function of your app.
I have an example prototype that I build whenever I demo Flinto for Mac for local startups. My favorite transition in this prototype is a photo zoom effect where the user taps a photo thumbnail and it zooms to full size.
This is a great animation because it looks nice, it’s fun to invoke, and it serves a functional purpose. This animation helps the user maintain a mental model of where they are in the app. They can see the photo they tapped move seamlessly to full-size, giving them a solid sense of how they are flowing through the app, where they came from, and how to get back.
Animations like this are extremely easy to do in Flinto for Mac thanks to the connected layer feature. By connecting the small photo to the big photo, the animation happens automatically. There is a short tutorial video on using connected layers on our tutorials page.
Pasquale D’Silva designed a fun Jupiter Weather app prototype which we added as an example to Flinto’s viewer app. Lots of people have been asking where they can download the prototype to try in Flinto for Mac, so here it is!
If you’re not familiar with Pasquale, he’s an animator and software designer known for his distinctive style. He’s one of those unique creatives who can hop seemingly effortlessly from design to illustration to music and combine elements of them all to build amazing projects.
We recently asked him a few questions about his Jupiter Weather project and his lol-worthy inspiration for it. Here’s what he had to say:
You're a great mobile app designer, what do you think makes a mobile experience great or terrible?
A great piece of mobile software carefully considers the physicality of the device, and kinetic user input. It's intimate.
A terrible mobile experience feels like something designed for consumption on a large screen, shoehorned into a space the size of a credit card.
How'd you come up with the idea of this prototype?
It's a pretty known fallacy that every amateur designer needs to design a static, impractical weather app & post it to Dribbble without irony.
I thought it'd be funny to take it further and make a plausible, but useless app prototype. Maybe one day when we're able to hop around planets, you'll care about the weather on Jupiter & its moons, and this will be a legitimate App Store chart topper.
What's your favorite detail in the prototype?
My favorite detail is the storm-tracker, which lets you see the forecast path of Jupiter's thrashing eye.
We recently sat down with Peter Nowell to discuss what it took to create the meticulous icon system in Flinto for Mac. Peter is a San Francisco based designer who created many of the UI elements in Flinto for Mac.
How did you contribute to Flinto for Mac?
I worked with Flinto in the months leading up to the release of Flinto for Mac, and contributed to various parts of the user interface and experience. But because Flinto is a very specialized tool, the more we thought through each part of the user experience the more we realized that the app was going to require a ton of custom icons. Nearly every part of the interface, from the Layers List, to the Toolbar, to the Transition Designer, to the Gestures dropdown was going to require its own set of icons. So that quickly became my main job!
What is your strategy when designing elements like icons or menus inside of a bigger app?
Design is always driven by context. Surprisingly, I found that designing for a professional Mac app was one of the most complex contexts to work within. Even just for the icons! Toolbar icons have to be a certain size, and look a certain way. That is different from the appearance of sidebar icons, which is different from those you’d find in a dropdown menu. Some icons re-appear in multiple places, at multiple sizes, and in multiple styles. Establishing consistency across all parts of Flinto’s interface meant that every icon had to be especially versatile. No symbols that looked great at one size, or in a certain style, but couldn’t be adapted to others.
My icon design process begins on paper. I’m a big believer in that. It begins with drawing every imaginable possibility for that icon — what the subject matter or metaphor will be and what variations they could take. While in this conceptual phase, I try to remind myself to put everything down on paper — even random ideas that seem unrelated. The next stage is evaluation; analyzing each concept based on how well it fits the goals, constraints, and context for this particular icon.
I find it essential to separate the drawing & conceptual process from the evaluation process. The former requires imagination, curiosity, and withholding of judgement. It is an additive process. It is spur of the moment. Evaluation — while equally important — requires criticism, pragmatism, and the time to consider a long list of implications. It is a subtractive process. If you try to do both at the same time you will end up with nothing. Your pen will never touch the paper.
I recently taught a class about Icon Design at CreativeLive, and outlined what I think are the most important design principles for icons. Those are what I use to evaluate my ideas and sketches.
Generally only a handful of concepts make their way onto the computer. When I fire up Sketch, it’s production time. There will still be some creative decisions along the way, but the predominant goal is to refine the form of an icon and make sure it is pixel-perfect. I’m really passionate about both of those, but I especially cause a racket when the latter is neglected!
Can you explain a little bit more about pixel perfection, and how to achieve it?
The term pixel perfect can mean a lot of things — it’s more of an ideal than a single concrete characteristic. Like “attention to detail,” it’s easier to identify when it has been ignored! Pixel perfection has a tremendous impact on the recognizability and efficacy of a small icon. And achieving it often requires more than just aligning design elements to the pixel grid (tips below). Basically it’s a fight against antialiasing. Antialiasing is a great thing, but it can produce very fuzzy results — especially for diagonal and curved lines.
For example, we wanted to include some indication in the Layers List about when a layer is hidden or locked. We weren’t as concerned about them being easily-clickable buttons (although they are) as we were about having small indicators that took up minimal space — especially because two icons would have to be visible if a layer was both hidden and locked. To accomplish this, the icons had to be meticulously pixel-perfect. I’m incredibly proud of how clear those little 8x8 icons turned out.
“Half Size” bitmaps shown for readers using a retina display, to see the 1x icon in full pixels. “Double Size” shown for readers using a non-retina display, to see the 2x icon in full pixels. Best viewed on a landscape tablet or larger screen.
In an ideal world, a well-made vector icon can simply be exported at various pixel-densities and look great at all of those scales. But much of the time, the limitations of designing a 1x asset aren’t worth carrying over to higher pixel densities. You may be able to build an icon perfectly at 2x, but need to make adjustments to create a decent and crisp 1x asset. At least half of the icons in Flinto’s UI have unique 1x and 2x versions, such as the “Connect Layers” icon throughout the Transition Designer.
For anyone who is curious, here are some techniques I used for fine tuning the antialiasing of icons in Flinto:
Resize and reposition shapes for crisper results, even if that means the position or dimensions have decimals. It’s about appearance, not values.
Only use curves or rounded corners when there are at least 2px to render each 90° angle of that radius’s circle (see below), or 3px for 180°, as with a rounded ends of a line (below). Goodbye, rounded 1pt line caps — at least until we’re all using 3x screens.
Adjust border width/thickness to be slightly wider or thinner than 1pt on thin curved or diagonal lines, for a more consistent perceived thickness.
Mask out unwanted blurry pixels. This will even have an effect if a shape is masked out by a duplicate of itself (no change in shape).
Duplicate a shape or its border (same position) to be slightly bolder.
Determine when it’s ok to have a little antialiasing fuzziness because a more important part of the icon benefits. It’s going to be ok!
What makes a great icon?
That’s such a loaded question! Especially because icons embody so many design principles in a small package. I actually approached that topic in my icon design class, and used a couple stories from working on Flinto.
One of them was about using familiar symbols and being obvious. When we started to make the icon for the home screen in Flinto’s Canvas, Nathan had the idea that we could design the icon to be reminiscent of an Eichler home. Eichler was a builder whose “Mid-Century modern” buildings can be seen in neighborhoods all over California.
Eichler’s mid-century modern homes inspired us to explore less conventional “home” icons.
I think they’re awesome and Nathan was actually in the market to buy one, so we enthusiastically explored the idea. I produced tons of concepts for the home icon, attempting to distill what was uniquely Eichler into a very small square-ish area (ideally 16x16) without relying on color or grayscale (transparency). And we found that these more clever icons didn’t perform their core task as well as the more obvious home icons. We settled on a version that was just slightly expressive and played off the asymmetry in Eichler’s architecture, while remaining obvious and recognizable to users.
Obvious trumped clever, and we selected the bottom-center home icon.
Another characteristic of a great icon is how well it harmonizes with its surroundings. That includes UI around the icon, size & weight of adjacent text, operating system conventions, and other icons in that collection.
So whereas the home icon basically exists on its own, the toolbar icons, Gesture icons, and Arrange icons exist in a set. And designing an icon set can be exponentially more challenging. You’ll get half-way through designing a collection of symbols and realize that the style or visual metaphor you’ve been using doesn’t hold up for every required icon, and now everything needs to change! 🙈
This happened with the Gesture icons (shown here at 200% scale). Their simplicity—which now seems obvious—was born from a long list of constraints and future considerations. Some of the icons shown above aren’t even in the app yet… but it was important to know that the icon set could expand to accommodate them if necessary.
Where can people learn more about all this?
I love this icon stuff, so I recently taught an online class about icon design through CreativeLive. It goes over how to design great icons, build them in Sketch, present them with SVG, and even animate them.
Get excited about Flinto for Mac 1.4, our most desktop-friendly version to date! Even if you don’t design for desktop experiences, this release still has features you’re gonna like.
New Gesture Types
We’ve introduced two new gesture pairs: mouse over + mouse out and touch down + touch up. These will allow you to easily create hover and active states on buttons and menus.
Scroll Wheel Support
We’ve added the ability to use your mouse's scroll wheel inside of scroll groups, great for testing desktop and web prototypes.
Expand Screens
Expand screen frames to more easily view overflowing content. No more hidden details.
Lock Proportions
No more distorting layers by mistake with this addition. Restrict the resizing of a layer to maintain the original proportions.
Interruptible Transitions
For incredibly responsive transitions, we’ve now made it so that you can interrupt transitions of back links and they will smoothy stop and reverse the direction. It’s subtle but pretty cool.
New Demo Prototype
We’ve added a fun new demo prototype designed by Pasquale D’Silva. It showcases the flexibility and utility of Flinto for Mac. Pasquale is an incredibly talented designer and illustrator whose work we’ve been fans of for quite a while. Get the latest version of our iOS viewer app to see it.
Your developers are going to love this update! As part of our Flinto for Mac 1.3 release we’ve made two huge improvements to support the handoff from designer to developer.
1. Added a UIKit spring option to the easing inspector.
When you use the UIKit spring, the values are the exact same ones that are in Apple’s frameworks so a developer can easily plug them in.
This spring’s options match the parameters to Apple’s UIKit Spring for easy handoff to developer trying to match springs designed in Flinto for Mac.
This chart shows the names used in Flinto for Mac and their corresponding UIKit parameter values.
Flinto for Mac
UIKit
Damping
usingSpringWithDamping
Velocity
initialSpringVelocity
Duration
duration
As an example, if you set damping 0.8, velocity 0, duration 300ms, this is what the actual UIKit API call looks like:
It’s called the RK4 spring, and you can find our implementation on GitHub. When you use our RK4 spring, your developer can drop in our small RK4 spring library and use the same values you set in Flinto for Mac for a precise match of spring behavior.
Flinto for Mac version 1.3 is available now. This version includes great new features that we’re pretty excited about (including one that’s been asked for since our original release).
Change your designs and re-import from Sketch
One of the most frequent requests we’ve received about the Flinto for Mac Sketch plugin is a way to import your Sketch file into Flinto again after making changes. The new plugin solves this issue. Changes made in Sketch will be sent to Flinto and links will be maintained. In Sketch, you can change layers, add layers, remove layers, even add new artboards, and it will all be merged into your existing Flinto for Mac document.
A short demo of the updated Flinto for Mac Sketch plugin
Send the same Sketch file to Flinto for Mac multiple times and Flinto will update the layers in place.
Send Sketch files directly to Flinto without needing to save the file first.
New flattening logic speeds up exports and simplifies prototypes.
Several import issues have been fixed, including one that caused things to be cut off and another which caused Sketch files with slice layers to fail not to work with the plugin.
Share spring values with developers
We’ve done two big things in version 1.3 to support developer handoff. First, we added a UIKit spring option to the easing inspector. When you use the UIKit spring, the values are the exact same as the ones in Apple’s frameworks so a developer can easily plug them in. We also have open-sourced our original spring implementation in Swift. It’s called the RK4 spring, and you can find it on GitHub. If you use our RK4 spring, your developer can drop in our small RK4 spring project and use the same values you use in Flinto for Mac for a precise match of spring behavior.
Android and website preset screen sizes
We’ve added the dimensions for the most popular Android devices and desktop resolutions to the new document window. Don’t forget, you always have the option to completely customize the screen size of your prototype in Flinto for Mac.
Have a layer block interactions on links underneath it
If you have a layer with a link below it, you can set the “Block Gestures Below” option to make it cover up the links below, preventing any interactions from passing through. You’ll know when you need this.
Easing curve preview in layer tags
When you animate a layer using the transition designer a tag appears. Now that tag shows a representation of the actual easing curve of your transition, so you can tell at a glance which layers have which easing curves applied to them.
Draw links directly into groups
It’s a lot easier to use the “Draw Link” tool inside groups. Instead of drawing the link outside the group and dragging it in, you can select a layer inside the group, and then draw the link and it will be placed in the group as you’d expect.
View prototypes in the Mac app after trial ends
Many customers have asked for us to provide a free way for their teammates to view prototypes on their Mac. In version 1.3, anyone can download the trial version of Flinto for Mac and continue to view (but not edit) prototypes after the trial expires.
Better scaling in preview and canvas
At certain zoom levels your screens could look weird and jagged, but now they don’t. Fantastic.
Apple introduced the Swift programming language on June 2, 2014. The first Flinto for Mac commit was on July 10, 2014. I worked full-time on the app for 14 months from that date before releasing Flinto for Mac. As far as I know, it is the largest Mac app written entirely in Swift. And I’m glad the timing worked out because I believe using Swift allowed me to write 30% less code than I would have if I had used Objective-C.
Flinto for Mac is a professional tool for app designers. It allows designers to prototype their app designs without writing code. The main benefit of Flinto for Mac is our unique Transition Designer which allows for creating your own animated transitions that can be controlled by taps or swipe gestures. When you’ve designed your prototype, you can test it out on-device using our iOS viewer app (also written in Swift). You can learn more about Flinto for Mac and download a trial from the Flinto for Mac website.
Fortunate Timing
At Flinto, we had the good fortune of starting our new project soon after Swift was introduced. That meant we didn’t need to convert an existing codebase, or deal with mixing Objective-C and Swift. I like to being an early adopter. It’s one of the things that keeps what I do fun and exciting, but it’s not without its risks. There was certainly some pain developing in Swift at the beginning, but things have rapidly stabilized and at this point, I’d certainly recommend anyone building an app for Mac or iOS to use Swift.
It may be more trouble than it’s worth to convert an existing codebase, but if you have a small one, you should do it. The savings in time and lines of code were huge. And that’s as a single engineer on a team of two, an environment where we’re naturally efficient already.
Swift is Easy to Love
Even as someone who has been writing Objective-C for seven years, I’ve found there’s a lot to love about Swift. Swift is safer. With features like optionals and strong types (which don’t rely on cumbersome C-like syntax). I found it easy to take advantage of functional programming tools like map/reduce. There is a good balance and while our code is not fully “functional”, it’s easy to reap some of the benefits as needed. Even the playgrounds feature (which may look like it’s just for fun demos) was of great value to me as a scratchpad for experimenting while building Flinto for Mac.
I’ve really enjoyed the improvements made to Swift during the development of Flinto for Mac. Better error handling in Swift 2 is more than welcome, but new availability checking syntax really save your time by dealing with supporting multiple version of operating system. It is easier than ever to support new API without spending lots of time to make sure the same code works in older operating systems.
Our First Swift Open Source Contribution
Finally, I’m excited to announce my first small contribution to the world of open source Swift. Flinto’s RK4 spring implementation is now available as open source. Designers using Flinto for Mac can now share the spring parameters they use in their animations with developers who can use our spring code to get an exact match from what the designer saw inside Flinto for Mac. If you are interested, please check out the Flinto Spring project on GitHub.
I’ve put Swift through it’s paces. Our app was released to rave reviews and is already an essential tool for many designers and agencies. We’re carrying on, full steam ahead with new features and projects. After all this I feel more sure than ever that Swift is a great language, and not only as a platform for Mac and iOS development, but I suspect it will become an excellent choice for computer science education. It would make a great first language, especially now that it has been open-sourced by Apple. I’m looking forward to using Swift for projects outside of Apple’s frameworks as the open source community finds more ways to use Swift on the server and elsewhere.
