Be nice. Or else.
Better yet: go check out the github repo here to play with it on-device: https://github.com/lmmenge/WatchSpringboard-Prototype
Yes, there's no official screen dimensions out there - but from what I've found, it's definitely a 5:4 screen ratio, and likely a 320x400 display. The typeface isn't out yet, either - so I used Helvetica.
So, with a few caveats in mind, I copied screens from Apple's site and made a template - enjoy! For Extra Fun Times, I recommend using Sketch Mirror to preview it on device.
We go from whiteboard discussions into visual comps, then into a variety of prototyping depending on the situation - then into full-on code.
From there, some of us like to dive into AfterEffects to come up with videos, though oftentimes the output is very difficult to translate into actual easing curves and values that an engineer can use.
I prefer to either do (a) a "static" prototype in Flinto, where you've got basic scrolling and push/pop/modal transitions included for free, or (b) export images from our visual comps into a lightweight Xcode prototype.
Whatever you do: sketch out the structure of an animation or transition, and then code that. The exact timings and easing curves should all be hooked up to a framework like Facebook's "Tweaks", which allow you to fine-tune the "feel" of your animation on-device.
What I've generally learned, though: everybody has a different approach, and it's important to let the smart folks on your team work in the way they find best. Some of us can't code, others (like me) don't know a lick of AfterEffects, but as long as we can all communicate the "structure" and "feel" of the things we're making, that's what matters. People over process! :)
yeah, i was sad to see that news, too - but this link is to a cached version that'll live on after the shutdown.
When I'm tackling something like this, I usually do something like this:
Let's say you're designing a nav bar, with a few different states. Sometimes it has a back button, sometimes it says "cancel/update", etc.
I'd come up with shared styles for the contents of the nav bar, and then for each state, come up with a symbol to represent the nav bar.
Use different art boards for each state.
The result? You can change the style of, say, the nav bar's title label, and the style change will cascade to your other symbols across the art boards.
But if you're changing the layout of one of these nav bar states, that layout change will only affect other instances of that nav bar's symbol.
I miss Layer Comps often, but this usually gets me pretty close to that workflow.
Really delightful animations in this app. Nice work!
I've been building this with Jesse Herlitz (@strike on App.net, @strikeux on Twitter) for the past year and a half - and we're really excited to have shipped it!
The first piece of software I ever shipped was a cribbage program written in MatLab.
It's still available to download: http://www.mathworks.com/matlabcentral/fileexchange/14806-cribbage-suite
Thank you! :) We had a lot of fun making it.