So we set out to find a prototyping tool that met these requirements: For example, full-screen transitions or fixed navigation bars. Simple things that are essentially free in native code can be difficult or quirky in web browsers. It was tempting to simply make prototypes in HTML, CSS and JavaScript-tools we’re very familiar with-but it turns out they’re a poor fit for the kinds of designs we wanted to try. We wanted to see and touch our designs on real devices. We knew right off that static Photoshop mock-ups weren’t going to cut it. Over the course of a day that time adds up.
#Framer vs flinto android#
It’s worse when you consider that making even seemingly minor visual changes to iOS or Android designs in native code can take much more time than you might expect. Even for the simplest of changes the difference between refreshing a web browser and building an app to a device (or simulator) is orders of magnitude slower. When designing Basecamp’s mobile apps it was a completely different story. We’ve done it this way for years -our workflow and development stack are highly optimized for it. We can then see and click the work-in-progress design just like our customers will the finished product. We don’t make highly-polished comps but instead work right in Basecamp’s code making hundreds (even thousands!) of tiny revisions until the design is just right.
In this article we’ll look at how we chose a prototyping tool and take a peek at a few of our prototypes.Īt Basecamp design happens through iteration. Interactive prototyping was essential to designing Basecamp 3 for iOS and Android.
0 kommentar(er)
