Episode 9: Animation in Your Design Process
In this episode Cennydd and Val address the topic of workflow and the process of actually getting good motion design shipped into an end product. They cover how to convince your team and clients that motion is important, how to document your animation decisions in styleguides, and more!
Episode Links
Transcript
Welcome to Episode 9 of Motion & Meaning; a little podcast about motion design for digital designers. I'm Val Head
And I'm Cennydd Bowles. In the last episode, we discussed accessibility, as it related to motion and one of the things we talked about was how to make sure your animations were designed in as universal a manner as possible. I think, kind of this has been a bit of a theme through the series that we've talked quite a lot about techniques and tools but finally now in Episode 9 I think we're going to try and address an area that maybe we've overlooked rather, which is workflow; talking about the process of actually getting good motion design shipped and delivered into an end product; so, working with your colleagues, maybe some of whom are kind of recalcitrant to do these kind of things, who just don't have experience or are kind of wondering why you're trying to bring this to the table and trying to work with them and actually get it in there, in the product itself that you're working on. So, we thought the way we'd tackle it today is kind of like a question and answer thing; we've got four questions that have come up from conversations we've had with people out there in the field trying to do this or people who've listened to the podcast and who've asked us things and so we'll sort of ask each other these questions and hopefully that'll be relatively illuminating and interesting. And I guess we'll find out by doing it as well, right?
Hopefully we'll even actually answer them!
Right. So, I'll crack on with the first question then which, this comes up a lot and actually it's kind of your classic conference talk question; someone sticks their hands up and they go, oh, this is all very well and good but my team would never go for it, right? How do I convince my team to spend the extra time doing it your way? So; Val, I guess, over to you. Do you want to take a stab at that?
I have definitely gotten this question after a conference talk. Usually maybe phrased a little bit more timidly, like, this is great, but seriously, my boss will never go for it. And I think it's a situation a lot of designers find themselves in because your boss and the rest of your team isn't necessarily out reading the same things you are, or just not necessarily interested in the same things you are and that's totally find. I think a really good way or the way I usually suggest people attack it is kind of taking the slow, stealthy approach to it; just start, at your meetings or stand-ups or whatever when you talk to your colleagues be like: hey, so I saw this thing, maybe it's a case study; I know Campaign Monitor's done a pretty interesting case study on how animations change their email builder; Stripe's done a pretty detailed one on how they change their checkout process; kind of do that and be like, oh hey, did you notice that Stripe does this, this and this and here's why they did it. We'd like to do that stuff with our product too; maybe we want to take the same approach. And kind of just doing that in little pieces at a time, calling attention to where other products or other sites have done motion very well and are using it in a way you would like to use it in your product and just subtly point that out here and there; maybe even go as far as trying to design some in. If you're doing some exploratory stuff be like, hey, I tried it this way. That kind of working your way up to that. It doesn't quickly change people's minds but I feel like it's a good approach for making them think it was their idea.
Yeah. I think there are couple of things in there that appeal to me. One is, certainly in some companies you can appeal to a competitive instinct; it's not something I recommend all the time but sometimes if a company's motivated that way, you can say, well, hey: our competitors are starting to do this stuff. We've got start to get involved because the benefit in terms of experience and so on are going to be good. So, you can use that as a bit of a driver, but the problem with that I think is it comes a bit kind of negative; you end up just trying to get motivated to copy their interaction design or their motion design.
You want to do it for yourself, not just because they are. But it is a good little…it's a good hook.
Yeah, it's kind of a good artificial motivator, if you need that kind of kick-start then that'll do it. I really like what you say about doing it undercover as well. This is something that I've always had strong belief in is essentially just doing it anyway without permission and if anyone has been following me for a little while, they'll know that I actually wrote a book, Undercover User Experience, which essentially about how to bring that mindset to do user experience work without actually having permission to do so. So, that totally appeals to me, the idea of just saying: well, we're just going to sneak a bit in and get these small victories and eventually they'll mount up, without having to do a big pitch and proposal saying: everyone, it's time to turn our attention to animation and to motion design. Just start drip-feeding it into your work and yeah, you might make some pretty good progress, right?
Yeah. And I guess you want to avoid that whole big reveal thing. If you went over the weekend, redesigned your entire product with motion and then Monday you come in and you're like, hey everyone! That's just…that could be very disastrous! So that's a good contrast there.
One of the things…think about this….one of the things I think that has surprised me when I've done this previously is actually a lot of the time, people don't need selling on it, once they see it. If you start to talk about motion without showing the motion then yes, you're going to have some problems, but if you actually start putting in prototypes, you start demo-ing: here's how something might work, a lot of the time that's actually pretty compelling, in and of itself. I've found particularly for engineers; less so when they actually have to think about, oh God, how are we going to build this, but they see it and they go, oooh….oooh, that's quite exciting and you actually see eyes light up before they start realising: oh, hang on, this is extra work!
And it is, if you can show it and then they can form their own opinions of it; they're not just like, oh, I should listen to Cennydd because he says we should do this. They're like: I see that and I like it too.
Yes, yes. So, kind of relates actually to some of the stuff we've said in earlier episodes. For me, the main cause of things that designers think are valuable, the main cause of those not shipping is when the rest of the team thinks they're kind of arbitrary and they don't see why they're put in; they think it's just designers faffing around doing that sort of stuff. So it comes down to pretty much everything we've talked about, making sure everything is there for a purpose and then that purpose you can explain when you do have people in; critique sessions or in sprint planning or something like that saying, well why do we even need this? You have an answer for it. Either it improves the mental model of what's happening, it better communicates the function of the product, it adds some brand personality, whatever it is, obviously to which I'd refer you to all the previous glorious episodes of the podcast. But once you have that in place, that really strengthens your case.
Yeah, being able to say why as opposed to just, because I want to or because it looks good. That's kind of the answer they expect from designers is, oh, because it looks good and that doesn't really go very far, really.
Sometimes, actually frequently, that really actually is the true answer but you still need to find a way!
Just don't say it is!
Essentially you need a way to say it that sounds slightly more meaningful and has a bit more content to it. There are always ways to do that.
And you want both; you want it to have a reason for being there and you do want it to look good; you're not going to be like, well, it's really ugly but it works. That's not the argument you want to make as a designer!
Right!
Unless that's like…anyway, unless that's your whole concept. But that's a different story.
There's one angle on this as well which I just want to talk about which is the MVP. I've seen very few MVPs that have good motion. It's something…
MVP meaning Minimum Viable Product?
Yes, sorry. MVP as in Minimum Viable Product.
Just making sure we weren't talking baseball or something!
No, no, no! I know pretty much zip about baseball! Much more of a cricket guy. Yes, so MVP and motion design can be quite tricky to pair because, is motion even minimum? Perhaps not. This is essentially just the same problem as we have with any kind of high-finesse interaction designer user experience design in an MVP and for me it's generally, this problem comes up when people have a poor conception of what an MVP actually means. What it should be is a full slice of the cake, not the bottom layer of the cake. If you're doing a sponge, it's not just all of the sponge; it's a small bit of sponge, a small bit of filling, a small bit of icing and some decoration, just a little bit of it.
I like that we keep going for dessert metaphors in this podcast. I think we should keep it up! It's a good one though!
Yeah. And I think it's about trying to just shift the perception and shift the discussion of what an MVP is meant to do: it should be a full stack experience. God, that's a horrible phrase, but it should contain a bit of everything; the core functionality and the tasty stuff on top so again, if you're successful in that conversation, I think there is scope for getting it in but the rest of the team needs to want it and needs to see the value of if so that refers back to what we said throughout the series.
That reminds me of an article I read a while ago that I'm hoping I'm remembering the title correctly, but it was talking about Minimum Viable Delight and basically just the idea of, if you're going to put together a minimal product, it needs to have a, kind of like what you said; it needs to have the thing that's going to make it actually, not necessarily, they used delight because you know, delight, but the thing that's going to make it pleasurable to use still has to be in there and if there's none of that, why'd you bother?
Yep, absolutely right.
Right. Let's go onto question two, which is kind of similar but a little bit more, I don't know, I guess detailed which is, how to convince your client or team that animation doesn't just mean using parallax scroll-jacking effects that you see everywhere else and that they should be looking to use animation in more meaningful ways that actually fit your product versus following a trend.
Mmm…is this from the perspective of working with client teams, working as a consultant outside a client team and then them saying, hey, we saw something cool in the New York Times or whatever it is, where they did this scrolljack-y think and we want something similar. Is that the kind of angle?
Yeah, when I've gotten this question it's been from that kind of angle like, hey the client really likes this; there's definitely a disconnect of who's…the designers and the people that own the product are coming from two different places.
Mmm, I see. I kind of take a classic consulting viewpoint on that which is, I want to understand why they're saying that. What's the motivation behind that question? Is it that they genuinely think it's the best thing for the product, or is it because they want to have on the résumé that they shipped something kind of glamorous and "ground-breaking" and so on? I suspect it's probably both but probably with more of the latter than the former. I would try and drill down and say OK, what specifically was it about that presentation, that site or that product that you thought was really effective? How did it solve problems for users? OK, great, we now know that; how can we take that and make it our own? And without just blindly copying these techniques that may or may not be appropriate. I mean, there is a place for scroll-jacking if it's done tastefully and all these sorts of things, but it's really about understanding those motivations and they're looking for an alternative way to address them. For me also, prototyping. Again, prototype different options and they will give you solutions or they will give you at least options that these client teams can say yes, this is the kind of thing I'm looking for in terms of the sort of glitzy-glamour and the excitement and things whizzing around, or no, I was thinking something even bigger or just help to really translate those words into what that actually means on the screen, because it may be actually just what they mean is not the scrolljack-y full sliding things as you go down the page but it might just be motion generally is actually what they're excited by, but they didn't really know how to phrase that; they've just seen this much more full-featured version and think that's kind of what they're after.
That's kind of a situation you get into with other design things as well, like if the client's like, this really needs to be this shade of blue and you're like, why? And then it turns out it's because their competitor uses a blue and they like that blue, or whatever; it's not necessarily because they really want that one, they just want to say they're business-y and you're like, well, we could do that with a different blue, or something. It's getting to that core meaning or that core motivation really helps. And not for any fault of their own but especially when it comes to dealing with clients, they shouldn't be expected to call things by the correct terminology if they're not design professionals, right?
Oh yeah.
With our job, they figure out what they mean, they're not going to be like, I would like this to have more of, I don't know, follow-through or something because they don't need to know what that means: that's our job.
Yep, absolutely. And as you say, that comes up all the time in visual critique as well; it needs to pop more and so on. Eventually you learn how to translate that, you know what that actually means in design language and this is just an extension.
Yeah, it's kinda funny how it so applies here: you're like, just because it's motion it's the same deal. People have preferences that may or may not be based in useful things for what they're trying to do. I would kind of add somewhat the answer to the last question too; you kind of touched on it with the prototyping of just finding examples. Maybe even if it's not full out prototypes, but if they're showing you these crazy parallax sites or, what was that McDonald's one that just came out recently? The McWhopper or whatever it was when it was burger pieces flying all in; they're like, we want this, and maybe you can find something that has more meaningful motion, maybe not so much, motion flying in from everywhere, but motion for more of a purpose or maybe more subdued and be like hey, maybe something like this, maybe you look at Stripe because we just talked about them or maybe you look at some apps like TweetBot or something, you're like, what about this kind of motion? Does this feel like something your brand would do, and kind of pull it from that, having them look at completely different examples and see if it's something that feels like it would fit their brand or their message and maybe you'll find something of a happy medium or like you said, where they didn't actually mean that much motion, they just wanted something moving and that's another way to get to that kind of borrowed from Dan Mall wrote a thing a while ago about doing these really quick design tasks of sticking your client's logo on someone else's site and being like, does this feel like it would fit you? Just these quick things, you don't want to build actual prototypes. He had a fancy name for it: can't remember what it is, but I will remember and link it in the show notes, because it's an interesting read!
I haven't seen that McDonald's site, but it doesn't sound entirely tasteful, let's put it that way!
It's lettuce and tomatoes flying on into buns! I don't know!
OK, well I suppose it could work. I really like what you're talking about around showing different products as well and just getting people to play with them and say, is this kind of what you meant, or is this what you meant? Because not only will that help give you an idea of what they're looking for but it also will help to, I suppose I'd say, to raise the motion literacy of the client; just exposure to more types of motion broadens the palette of the sort of conversation you can have; it broadens the language. You can go, well, we can have more of this kind of style with opacities and these fades and so on, and they have an example of what that is; they don't need to try and work it out from square one, which is nice.
Yeah, it's a nice, sneaky way to get it in there. I find when you do those examples near the beginning they come up later in the project when they're looking at what you've done they're like, oh, hey, that reminds me of the way TweetBot did this thing and you're like, aha, yep, exactly. You can have more meaningful conversations later on too, just by laying that groundwork; it's really helpful.
Nice. OK. Let's move onto question three then. I want to talk a bit about documentation. How best should we document animation or motion design? What format should we try and present it in? Who should we document it for and particularly, how detailed should we get with it?
I guess the first thing I always go to is, since style guides are such a thing these days, as they should be, is that if you have a style guide, motion should be in your style guide; it should be a section of your style guide. If you're documenting things like colours and type, you should also be documenting motion in a similar way. I think the format, really whatever works best for your team. I think a lot of people end up doing it in some, at least for web stuff, end up doing it in some HTML sort of browser-based format because that's what is easy to pass around and is easy to use. It doesn't necessarily have to be but I think that's, at least for the kind of work I do, I know that's the most useful and it's kind of based on whoever the audience is. If you work for a giant company and you're setting these rules for all the designers and there's going to be like, a hundred; I don't even if know if that's a big company's worth of designers; a hundred designers…
Biggish!
A million designers, I don't know, you want to write it in a way that it's going to be understood by designers. If it's something that you want people who maybe aren't necessarily designers, you're at a smaller company, less than a hundred designers; maybe, like, four, I don't know. My company size estimates are terrible, but then you might have some people who maybe it's more developers who will be reading this too and then you want to have it be something that would be meaningful for them that they can take from it easily, understand what it means and use it, so it's not like they read it and they're like, well, I don't get it, I'm just going to do my own thing anyways. You want to avoid that. And details kind of the same way as to how far detail to you need to get for it to be usable? I know some places or some people will do a little example that's maybe an animated gif or video thing, then there'll even be a little code next to it of, here's how to pull it off in CSS, and if that document's going to be used by a lot of developers or maybe a lot of even just people who are meant to implement it and can't spend a lot of time figuring out how to make that work in code, they can just copy and paste it and go. But then there's other ones that don't go into quite so much detail and I think could be very useful for different audiences, especially people who are maybe more designing things versus actually implementing them, so really I think it depends a lot on your company and your audience of who you're sharing it with and who it's for.
Yeah, you're right. I think the audience definition is probably the key thing.
Otherwise it won't get used! Then you wasted your effort!
Yeah, absolutely. I'm a big fan, theoretically, of style guides; in practice they can be a bit more difficult than they appear, I think. The most recent, when I worked at Twitter we had a style guide and I was part of a project to help motion be part of that. That was aimed at designers because there were a hundred designers, or roughly that number.
Good guess!
And so it's important that everyone understands what Twitter's motion standards were and what motion meant for the company and how it should happen across all products and so on, and so it was written for designers, it was written in design language. You could be more precise that way but we still had interested people from across the organisation from Product and Engineering particularly diving in and saying hey, show me more about what you've got. In terms of the format, I think really the only thing is it can't be static. It has to be motion, it can't be…
A printed pdf!
Yeah; certainly you can't have a pdf, you can't have a paper handout. It has to move. I think we just used gifs; we had a confluence page and on that…maybe it wasn't, it was actually…no, I think we sort of hand-rolled HTML if I remember rightly and we just threw some gifs in it and it was particularly good to have dos and don'ts as well like, animation works like this but not like this. We talked about the Material Design guidelines quite a bit; they have exactly that which is a really nice kind of representative format for that.
Yeah, it's good to show the good example versus bad example, just to give a range of…because usually, especially if you're doing good and bad examples, you're not like it always has to exactly this good example or you need a little room to work with there.
Yeah, it's more talking about the class of solution; things all move in from this direction but we're not going to show every single possible component that can come in from this direction; just, if in doubt, it comes in from the right, or whatever it may be. I think also like your prototypes are also documentation. They are harder to arrange into a canonical style guide because they're not as componentisable but if it's appropriate, put some of those in as well.
Yeah, you can pull from them to get the style guide pieces.
Yes exactly. Screen grab them or whatever.
Yeah, we talked a little bit about that in the choreography episode of the idea of objects that are on screen that exist for similar tasks or similar content should move in a similar way, so you could document those main categories very easily. And I just realised that I totally forgot part of my answer, of what to document, of things like the categories of that animation like…and you kind of touched on that too: what are you using it for? Your example of when things come in, they come in this way it's like OK, we use animation to have things enter and exit the screen. If you have a shortlist of these are the things we use animation for, it helps as you're designing new things or making new stuff, you can have that sort of focused, that kind of similar aim through things. If there's a new page on your site and it's the only one that decides to animate opacity and everything else does scale and rotation, that's going to look weird, so if you document, we have decided to use these two properties for these two reasons; that gives you some instant cohesive choreography going on, assuming people follow it!
Yeah. You're right.
But it lets you define it there.
It becomes more of a kind of reference material in that way, doesn't it? I've seen style guides that are more reference-y and I've seen style guides that are more frankly sales-y. Sales-y in terms of hearts and minds as to why we should do all this sort of stuff: we use motion because it represents a clean and modern brand, it's exciting; all this kind of stuff and you can use that kind of documentation for it, but if it's something that you're trying to work across a bigger team, just make sure that it's choreographed well and harmonised and everyone's got the same building blocks, then you'll want it to be much more specific about the opacity values and the scaling, timings and all this sort of stuff.
I guess that kind of makes you think there's a couple, things like material design and also IBMs, machines in motion and Sales Force has released a very public one too; it's like, some people or some companies are releasing these very publicly and I think in part because it's a trendy thing to do right now, I think it's a good trend, I think it's very helpful to everyone.
I agree. It's a very web-like trend.
Yeah, share all this stuff.
It's an important key of the web, yeah.
But that's not necessarily the audience you need to be making these for. You don't have to make your style guide or your design guidelines for motion public. I think when you make them public, there seems to be more of that sales-y talk to it. Not in a bad way of just like, here's why we do it; here's why it fits with our brand, but also if you're at a really large company, you kinda need that because there's people reading this that you've never spoken to.
That's true. Frankly, a lot of it's going to be dictated by NDAs and confidentiality and so on, so I think it's a good default to share if you can; I think that has to be a good thing but if you can't, so be it, there's still value in doing it, it's just less of a public performance, it's more of an internal performance.
Not being able to share, just because you can't share, doesn't mean you shouldn't do it; you shouldn't be like, oh, no style guide for us because we can't make it public because of all these rules; that's such a secondary thing
Right. You can still put it on your résumé later, you just can't put all the details; you can't share the specifics, that's all. You just say you did one!
Yeah, yeah, I think it's a good thing to point out because it seems like so many people, so many companies are sharing them and I know there's some people who are like, I want to do this but my company would never let me public it, because that's words; they would never let me make this public. It's like, you should still totally do it. That's the smallest piece of the puzzle.
Yes, exactly.
So, question four. How often, speaking of documentation, should this documentation be updated. And we just talked about how public or non-public it should be, but who's responsible for sharing it or responsible for updating it, rather?
Mmm, you know, I think that's kind of the key question with style guides for me. Everyone agrees they're a good idea and not everyone wants to actually do it. I'm also reminded of the Kurt Vonnegut quote of, what is it? "Everyone wants to build and no one wants to do maintenance."
Yes!
And everyone wants to be involved in the creation of the first bits of the style guide, then it gets really tough, just laborious detailed work; people drift away from it and then it's done and then no one wants to touch it. You should obviously update it as often as you can but you have to balance that because every minute that you're spending updating that is potentially a minute you're not improving your product. And if you have to choose between the two it's clearly better to improve your product. But you can of course improve the product by spending the time to get those fundamentals right and get that style guide prepared so you need to find the balance. Who's responsible for it? Personally, I think your design team is responsible for it; your designers are responsible for it, because although it's a piece of work that cuts across the organisation, you're going to have developers involved, product people involved, you may even have marketers involved, copy-writers, talking about what's happening on screen or a new feature launch where motion figures deeply, you might have those people involved as well, but design is still going to be the driving force behind it, so I think design has to be the driving force behind documenting and maintaining that. How you then balance that against all of your other priorities as a designer is the big question and the vast majority of people who are listening are going to be in companies, I think, that are too small to have dedicated motion design people on staff which is totally understandable.
Yeah, that's definitely not, oh that's so terrible for you, it's just the reality of how it goes.
It's definitely a bit of a luxury to have a full-time motion designer. It's a wonderful luxury to have but most people you're going to be doing this yourself so you have to make those kind of trade-offs. Don't under-estimate the maintenance effort, I think.
Yeah, definitely. That's definitely I think the harder part of style guides is keeping it up and maintaining it, because like you said, no one really wants to and it's easy to let it go when you also have to shift something or there's…or even for client stuff when you're like, that's not my project any more. I don't even know how you…those get a little trickier, I guess, it kind of becomes the client's responsibility to update it then. But yeah, I think it definitely needs to come from design because that seems to be the intention of style guides anyway is a way to share this design thinking and design motivation with everyone else, or whoever else is implementing it, so it should definitely come from design. The balance is the tough part of figuring out how you find the time to put into it and keep it updated and keep it, I guess, like a living document. I don't have all the answers for that! I know it's hard.
I think one thing that helps on that is to have as small a style guide as makes sense. You want detail to an extent but if you start going too far with detail, then it starts to be out of date more quickly and that means you have to update it more frequently and that overhead is greater as well. So, I much prefer keeping motion guidelines on a somewhat abstract basis rather than, this is how the close button moves in and out, because you may in version1.2, you may get rid of close buttons altogether and then suddenly you've got to take all that out as well. Keep it more about general motion principles and types of components and how they interact and so on, rather than tiny, specific, minute elements because then you'll find that, as you say, you just don’t have any time left to update it or if you do update it, you haven't got any time left to actually improve the product.
Yeah, or worse, you're like, I don't want to update this thing in the actual product because I'll have to change my style guide and I'm not doing that! That's just a…
I have had that motivation sometimes; I've managed to fight it usually but yeah…
Hey, it's gonna come up if you're like, oh no, this is big part of…this is in the style guide in fifty places: if I change it here, I'm going to be up late tomorrow. Or not tomorrow, but whatever. You're going to think of those things, it happens. We're all lazy by default. We don't want to make extra work for ourselves.
The point about design being in charge of this. Again, that depends slightly on the format and the intent of the style guide. I've seen style guides that are just as much developer tools, in terms of code components and snippets and things like that.
Yeah, and ones that go to …are almost like a code library in a sense or partly code library.
Yeah, exactly. Now I think the intention is slightly different between a design style guide and a code style guide. I've seen a lot that are combined but a design style guide you can only do at the end of all the design work, I think, basically; I don't think designers can really work in terms of designing specific components and then putting everything together to hope it makes a page, whereas developers have much more of a kind of componentised progressive enhancement sort of approach that they can use where they can do those and combine. With design, you have to go with the big thing and then decompose it.
Yeah, or at least look at both pieces of it; you can't be all…micro-pieces of things without looking at the macro level ever.
Right, exactly, if you're an architect, you can't start by designing a door and then fit a house around it: you've got to sketch out the outline of the house and the plan and so on. So, if you have that kind of thing, designers are always going to retro-fitting; they're always going to be doing new master files or sketches or whatever it is and then from their complete work, filling in a style guide, whereas developers can make tweaks to the CSS and the mark-up or whatever it is in their components that then may trickle forward into the product so there's kind of a different direction; it's always going to be a bit more…it's almost kind of more busy work for designers because, well, the real work is done, now this is just documentation, whereas a more developer-leaning style guide can be more closely related to some of the components you actually put in the product. So, that may skew how you separate those responsibilities as well.
Yeah, yeah, it kinda comes down to the audience again, like you said. It's documentation but it's definitely valuable documentation, but you have to balance what value you get out of it by the amount of work you put into it. You don't want to be putting in tons of work and then you're like, and this provides a tiny bit of value. Real fun!
Yup; exactly that. So those are our four questions. If you have any other questions, if you're listening, by all means throw us a DM or something or a message on Twitter or something like that and we'd be glad to try and answer those at some point if we can. Let's move on to our what we're reading section. Now, Val, you've got quite a lot on this list here, so over to you!
Yeah, it looks like I've been reading a lot, in contrast. One of the first ones I was reading is Tooling Up. It's on Google Design and we're talking about Pixate what was it, two episodes ago?
Yeah, two.
In this article, Tooling Up is kind of essentially just an interview with some of the folks, or I guess one of the folks from Pixate about what kind of hinting at what Google might do with all this and why they wanted it to begin with. And it has some nice illustrations, so it's a good read to give you an idea of where this might be going and just kind of an interesting take on what Google is doing with these tools and how they might change.
It was an interview format, wasn't it, with one of the Pixate folks, one of the Form folks and then Matias Duarte, who's the VP of Design at Google.
Yeah, it's got Paul Colton, I think, from Pixate; I'm just looking at it now, and then Max Weisel maybe, from Forum. So those two tools and the VP of Design at Google. I thought it was an interesting read. Another one was the Medium article of course, because that's all the internet is these days! It's Motion Interface Design: Continuity and Expectation and there's some interesting breakdowns of how continuity works well in the Apple home-screen and how it falls apart, and some interesting points on choreography and just that kind of…a lot of that spatial orientation of once you start moving things in a certain way and you've established this kind of rule-set for lack of a better word, how it gets weird when you break that and a lot of it's like the super-tiny details that maybe only people like us that obsess over the motion would notice, but I think on a higher level, it does get noticed by your average user, just maybe not in that detail; they might not be like…
Subconsciously.
Yeah, they're not like, oh, that's confusing because that faded in and nothing else did an opacity fade ever; they're just like, huh, you know, and it's a little extra stumbling thing, so there's a lot of detail if you like those kind of geeky details, there's a lot of that in there.
That sounds good.
And a lot of animated gifs! Which means it's going to be good anyways. And then one last one I was reading in Motionographer this morning kind of completely unrelated to UI animation, but I found it really interesting. It's an interview as well with…let me find his name…Adam Plouff, I think is how you might say that. Adam Plouff…and he's talking about various code-based tools that traditional animators are building themselves to make things…what is it…inverse kinematics when arms and legs move and stuff like that, and it's just interesting to see the kind of tools that he's built and the kind of tools he uses to do walk cycles and arms and stuff; even though it's nothing we would use in interfaces, it's just there's an interesting parallel there, it's like, but we have some code based tools that we use to do the stuff we want to do, so I found it to be an interesting read and there's some really cool animated gifs in there too! That's the only reason I read the internet; if you've animated gifs, I'll read your article!
Right. Sounds good.
So that's my reading list for this time around.
And you're putting me to shame because I have essentially nothing on my list. I read a decent amount of that Google article but I've been travelling; that's my excuse, so I haven't read anything, so I'll be sure to book up for next episode so I've got some impressive things to share.
It's hard to fit in internet reading when you're on a plane for hours and hours; it's totally understandable!
That's very true. I have all these articles in Pocket but I just…it was the last thing I wanted to do on these ridiculously long flights, so: sorry listeners, but I'll book up, as I say, for the next episode.
Next time it's going to be all you; I'm not reading anything for the next week!
Sounds like a challenge! OK, so in that next episode, we're going to talk about design problems that motion can answer, so almost like a cook book or a reference thing; if you have problem X then try motion answer Y, if that makes sense. Hopefully it will by the time we actually share that episode with you.
Of course, it makes complete sense!
Just to give you some specific tactics that you can try and use, if you have certain challenges, just to give you a bit of a kick start to put some useful motion to use. I think that's it for Episode 9 so we hope you can tune in for the next time.
You've been listening to Episode 9 of Motion & Meaning with Val Head and Cennydd Bowles. You can find out more about this show at motionandmeaning.io and we'd love to hear your feedback on Twitter as well. We're @MotionMeaning there. We are also now on iTunes, so if you're enjoying the show, please give us a rating or a review in iTunes so that more people can find out about Motion & Meaning. See you again soon.
Transcribed by Alison