Designing for Ember Apps
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Trevathan, Steve
Ember allows us to design highly adaptive, extendable, and fast web apps, but with those possibilities comes greater responsibility. Successfully leveraging the characteristics that make the technology worth while requires a myriad of methods, principles, and patterns that aren’t readily obvious to those breaking into single page application design. In this talk I’ll hone in on those requirements with relevant examples and give the audience a starting point to make their next Ember.js product design successful.
 So I made this slide just to mess with you. There's no presentation loading. So I'm going to start this talk off with a metaphor. All of us here, building with Amber, we're designing a house. I chose the metaphor of the house because much like the applications that were able and capable to build with Amber, we're dealing with an infinite or an impossibly large number of use cases and problems to solve. There are rules and regulations in place that we both have to discover, but also beyond that have to uphold and abide by. It makes for a very complicated job. Because like Amber actually allow us to create digital solutions that we couldn't have possibly imagined just a few years ago. And again, the number of use cases that we're encountering through our projects are just overwhelmingly large. Everyone uses them different. It's really important for us to understand our audience and what our ultimate solution is going to be. So we're also building a lot of them. We're building a vast network of interconnected experiences. I'm Stephen Chirbathin. I'm partner and creative director at Dockyard. We're designed driven software consultancy based out of Boston, Massachusetts. So we might know of us perhaps from our contributions to Amber. We've got Rob and our team. Oh, thank you so much. Okay. So my talk is going to be about designing for single-page applications. And I've broken my talk into a couple parts. With the intent of explaining the first part of my talk, I'm going to be your pain in the ass user. I'm going to hate the house that you built me. I'm using the house metaphor, by the way. I'm going to hate the house that you built me and curse at the front door that you chose. I'm going to show a little respect for you and the challenges that you faced in creating the solution for me because it doesn't satisfy my personal needs or tastes. Even if you give it to me for free, open source, I'm going to show you how much pain you've caused me without acknowledging anything that you managed to do right. Does that sound familiar? I'm sure a lot of us. And for the newbies in the audience, welcome to the world of making things for people. So how do we stop our users from spitting all over us and treating us like this? I'm just so excited to have this as a slide. Well, first off, we don't marry them. Second, we start with mental models. We start with trying to understand where our users coming from, who they are and what types of interactions they deal with on a day-to-day basis that we may be able to borrow from for our own scenarios. Does anybody know what mental models have experience working with mental models to know how they impact your reception of your application? We got a couple. I was talking for a few hands out there. Cool. Nobody. I love it. So mental models is both what I think the thing is and how I think the thing works as a user. So that is all developed really from my past experiences. So experiencing one object, say, a laptop, and then I come to another laptop, I expect a certain type of experience. I'm saying laptop because I see a ton of laptops right now. But I see, you know, you expect your experience or the solution to match those from your experience or at least improve upon them. So they're not always solid. A mental model is ever evolving throughout my life as I come into contact with different objects as I use them. They can be updated or changed by certain innovations. So if I improve upon a particular feature or function, it's great for us to release that out into the world, use it in our apps, and have that become the new de facto standard. I think the pull to refresh was actually one of those scenarios which is kind of now outdated, but for the time being that was a really great scenario and that sort of built itself into mental models of users with that type of content or feeds. So I'm going to take the home metaphor a little bit further. We're going to try to analyze what I think a home is. So what is home? How do I know a home is home? What is my mental model of this? Home is really a concept of home is greater than the concept of it is greater than the sum of all the features that the home actually offers me. It's more than just the kitchen sink. It's more than the couch. It's actually a total experience. I think of home. I think of a lot of things simultaneously. Is this a home? Certainly not. It's hardly passes for a raft. These kids are running away to form a rival to the insane clown posse. Is this a home? Perhaps House of God, but it's a little bit too lavish for me. I am not worthy. All right. You know I was going to get to this slide. This is a home, right? This matches all of our models or understanding of what a home should be. There are things about this, though, characteristics visually that we're able to identify really cleanly and clearly. There are windows of particular widths and heights. They're equi-distant from each other. There's a door. There are gutters. There's a roof. The building itself is of particular shape and it's often nestled between other buildings of similar shapes. This may all seem really obvious to you, but this evolved over time. If we compare this to this, we notice that this actually still kind of seems like a home, but you're judging it. You're valuing this home very different from the other home because there are very unique characteristics that break them apart, that make them different from each other, but they still share some common experiences, common design patterns. Still has windows, still has a roof. It's got a chimney. It's got a door for access. There's something about this that makes it very weird and that's really the shell shape. Your interpretation of the value of this object is based off of your previous experience with houses and how those function and seeing how this one might function differently than yours. There are two types of mental models to be aware of when we're designing our apps. There's the macro, which is really the point of view that we have in the house. That's from a distance. It's before I've actually had a chance to interact with it on a micro level. It's the assessment that I make on what I believe it's going to do for me. It's the thing that makes me want to go, things that make me want to try it and experience it for the first time. A lot of people write this off as marketing, but I have a different approach to that and we'll talk about that a little bit later. The macro experience is how I think the individual interaction works itself. It's how I think it, like the specific feature, will work. It's also what I think the application will do on an individual feature by feature basis and ultimately the micro model is where the core value or core interactions of your product are derived. This is the last of the house bit, I promise you. This is a door that I need to say it. On a micro level, this is a particular feature of the home. It's got a handle that turns, the door is going to swivel in and out, close, it's got a lock, and so on. That's great. It seems pretty simple. This is a different door. If I were to interact with this, this is actually very similar to a lot of experiences I have on the web. You come to believe that this is the way things are going to be, this is how it's going to work, this is what I should come to expect. Somebody decides that their application needs to be super secure and then they add all these locks that just really interrupt my flow and my process. On the micro model, this doesn't quite match. If we printed out the feature list, though, of course they would match. Like both of these doors probably have the same feature list. Should open, should close, should lock, go on. All right. I'm going to shed the whole metaphor. We're going to talk about digital experiences and how the mental models actually apply to what we're creating today. A few of us may be familiar with the Motorola Razer. Anybody else have that phone in here? I definitely did. It was miserable sending messages. We're going to ignore the keyboard on that phone. We're going to talk about this interface here. We've got a large space for composing message. We have an OK button at the bottom right. I realize when I put this together that some of us in the room are probably not old enough to know what this is. It's really depressing. All right. So I say, well, I'm a messenger. I wish I could use my laser from here. I don't think it's going to, you know, I can see anything. But there's a bunch of erroneous features that we can ignore that thank God we kind of shed them as we push forward in chat-based applications and in texting. But generally this is the same thing. We have a large composure box and we have a send button at the bottom right. There has been added a dialogue, though. We can see that history right here. This is a very squished view of Apple's messages application. Again, there are things that are really, really similar to each other, but from the Motorola Razr experience to the AOLN submersion drive, I forgot the name, I haven't used it in so long, to messages, we don't have that large of a mental jump. The leap is very short and easy to cross. So we still have a messages box at the bottom and when you start typing your message, you are able to hit send. This is my favorite example. Does anybody know what this experience is just by looking at it? I'm waiting for someone to shout it. People are probably a little embarrassed to say it. So this is Tinder's communication experience. So look at the difference between this one and this one. Like this is, it's not even different. Like I believe the Android phone, sorry, the Android Tinder application actually operates very much the same way. The point here is that the users of Tinder already had a model for short transmission length, but really high frequency of communication. That was called texting. That already existed. So they're able to take from this experience and effectively model their behavior in their application because that's what they wanted. That's what they knew their users were going to use. This is critically important to notice. Somewhere out there in the world of your target audience, the applications that you're building, problems you're trying to solve, there are models for interaction that already exist, both macro and micro. And if you're able to build the applications and design them in such a way that utilize those, whether the applications are strikingly similar or even competitors, you're able to build a framework of understanding. It's going to allow me to get to know your application, to see the value. It makes your application more usable, and it also gives me a clear path to learn. Some applications have a very difficult learning path, but you believe in the value so much that you're willing to dig through it. I don't think that always has to be the case. This is an example of a direct copy that gets you sued. Don't do that. Selling mental models is different from directly copying a competitor's solution. As I should with Tinder and Messages, those aren't really competitors. They're really promoting Apple's platform by using that space. Ultimately, people will move off from Tinder and start using their texting anyway. It's not really competing with an app. It's not like Apple is selling Messages app. It's a bare base app for the product. So anyway, we don't want to start nature of wars with people. So don't copy. Just try to understand the mental models and how they may apply to your experience. You should use them explicitly if they directly apply to an experience. So I've already interacted with the Jillian radio buttons in the world. You don't necessarily need to redesign a radio button all the time. Some cases, there may be unique value to be gained on that micro level, but generally, you can just keep using it. But you want to break them where you can improve the understanding and value of your product. This is a really good example of that. You'll probably know what this is just by looking at this part. I just wanted to focus the shot here. But this is the first generation iPod. I was not lucky enough to have one. I had a bunch of really crappy MP3 players. But all the other MP3 players at the time operated on a D-pad. So if you want to navigate through your folders of media to gain access to certain music, you would actually have to press up and then press down and then navigate into the right one and then back out when you decided I don't want to listen to that song. Apple actually produced a really incredible design for this. You can use one continuous motion instead of constant tapping, exhausting tapping and with annoying clicking sounds. You can use that one continuous motion, which is actually kind of fun, and much more quickly move through your file structure, your folder structure. Of course, we changed the paradigm of the folder structure over time, but that's how things worked at this period, I think. So they both increased the ability for users to move through their product, but they also created somewhat of a fashion item that was really unique. And this is an example of a micro model here or a micro interaction. So this is just one part of the whole. And differentiating here made a big difference for Apple. So how can we in our applications start creating experiences that delight our users, differentiate our products so much, and really cement the value of our product in our user's minds? We want to do that through creating repeatable design methods and design patterns for both interactions and song. So I'm going to talk about five major ones here. So one is gradual engagement. This is really more of a method than anything. It's not necessarily a particular pattern because it's going to be very different with every product that you design. But the idea of gradual engagement is that you can reduce the perceived risk of signing up for your application by allowing them to get to know it over time. A good example of that is Pandora. Instead of throwing a sign up wall to start their radio, they actually drop you right there on the homepage. It communicates that it's a new type of radio. Okay, I've got the radio in my head. And it plays stations that only I like. So radio, personalization, good. And a single text area. So I start typing, go to Panda. I move forward and my, it's done. Like I get the core value of this product. It's already starting, it's music. I can listen to it for free. I'm able to access and understand what Pandora is ultimately trying to provide for me and why I should like it or why I should use it. I didn't have to sign up for that. It's great. After a number of songs, they may tell you or ask you to sign up to continue playing the radio, but you've already gained the value from them. It's a much easier sell. This is a video and unfortunately, screen dimensions are a little off, but GuShark does effectively the same thing. And they are loading just, just look at that, double spinners. I'm saying they necessarily do it perfectly. But down here I'm adding a whole StereoLab album. My favorite ones are theirs. And I'm playing. I get so much of that experience without requiring to do any real work up front, aside from learning their UI. But that's a good thing. I learned your UI. I found the value. Maybe I'll sign up and save it. So I kind of complained about the spinners for a little bit. I don't know if we can get rid of them or at least get rid of a lot of them. There's some cases where you might want to keep them. I understand. But there's a better way for the most part. That's with Skeleton UI. So this is Google Maps. I'm actually not sure if you can see on these screens, but there is a grid that's in the background that resembles content to be. It's effectively just a tile. It doesn't even have to line up with the image that's rendering there. But the idea is that you can give your users an increased sense of speed of your application by providing sort of a stand-in or scaffolding of content to come. Instagram does an OK job. It's in your CY. They basically did the bare minimum. Sorry if anyone's from Instagram here. But they did the bare minimum, I think, for their application for a Skeleton UI, but it still helps. It's still better than just having a blank screen with a spinner. So here I know that there's an avatar that's going to show up. I've got labels for posts, followers, and following. My follow and unfollow button is just sitting there saying loading for some reason. I guess they didn't know where else to put the loading. Facebook actually does a much better job. This is their application, of course, the mobile app. Let's look at their web application. They do the same thing. So if you can see, there's a little bit of an animation on those content or the scaffolding on Skeleton UI that we have there. And it gives you a much better sense that something is happening, that the product is moving forward. It's listen to your request and content's coming. It's on the way. Hold tight. Another product that does this really well, and I think they do it the best, is Pinterest. They actually source the image height or dimensions to produce their tiles, as they do here. And since it is an experience, really kind of a lookbook, Docker, I'd actually create mood boards using Pinterest. And I've grown to fall in love with this product. I don't know if people really use this as much as I do. But they've also sourced the base color from all these images, and they present with that. And then they load the images in. It's pretty simple, but it's beautiful, and it actually fits really well with the core interaction of the product. Another thing I think that we could be doing better, is carrying context. So don't leave me waiting at the bus stop. If one parent chaperone or bus driver drops me off at the bus stop, I expect my parents to pick me up. And I think that's true for applications. So I think a really good example is Ardio and Spotify. So in this case, if I'm playing Ardio on my laptop and I go over to my iPad, let's say my laptop's in the other room, and I want to change the song because it's playing on my speakers, and it's hooked up, and I'm sitting somewhere else, I can actually tap here on my skip, or I can change the song, and that's great. I can actually operate my application from a whole other location. And that's fantastic. So I can do that here as well. There's a couple reasons why this is really nice. Obviously, added functionality. I can see that it's currently engaged with elsewhere. But I also get a greater sense that the system really knows where I stand. It knows more about me and my current experience with the app, and it presents that back to me. Spotify does effectively, they do a fair job. I like the way that Ardio did it better, although Spotify's actual engineering seems to be better. It's faster. But this is what we call an intercom or a generic message at Duckert. They effectively just say your music has been paused up here. So that's the kind of indication that they give, indicated that they give to you if you're on a device that's no longer the control point. But you can still interact with the application. They don't block you from interacting and playing with it and making changes. And there's one case where I can give you an example for a major save. So in the case of continuous streaming music, that's a really easy thing to understand why you should be able to operate in both locations. But here's another one. Imagine that you're giving a trade or making a trade of a couple hundred thousand dollars and you're making investment for a client and it's $3.55 and you've got to get it in before the market closes at four. A lot of pressure. You're in the middle of making the trade and your computer dies or something. It just catches on fire. Some monkeys take it. Then you're able to pick it up on your phone. Imagine if you're able to just pick up your phone, log into the website and pick up right where you left off. See that you've made it halfway or 70% of the way through the trade, entering certain information about how you want it to work. And you can trade. Done. It's a major save. You could have saved your client hundreds of thousands of dollars. You could save yourself a job. Core interactions are really more of a micro-model layer. There are the things that cement in that value. So the whole reason someone should use your application to be conned with is the example of reusing core interactions. Some applications have many of them. Other ones have just a few. What I'm showing you right now is the way that Pinterest actually works. So core interaction of Pinterest really is going on a tangent. It's just browsing, just looking at something, becoming interested, clicking on it again, finding something else that looks just like it. Wherever you go in Pinterest, you're able to click and follow a new tangent. So that's a repeated core interaction here. An example of... Oh. Okay, I might have actually moved that slide one forward. So the core interactions actually become a symbol of our app. So when we come to understand the value, we come to understand why I should be using app to begin with, and you repeat that over time, that micro-model of the individual interaction that experience I'm having will override and become the macro-model. It will become what I remember your application by. When I go home and I think of your application, I think of those things. Think of the experience I had with it. When I open a can of Coke and I drink it and I throw the Coke away, what do I think about? I think about the experience of drinking Coke, not about necessarily their ad that was on the subway. And that's the same as true for our applications. Another example of repeating a core interaction is threes. A lot of us play threes. Yeah? We've been obsessed about this game for a while. Essentially you just use the same interaction. You win or lose by, I think this game actually you only lose. At least I do. I don't think you can ever get to a point where it's like, ta-da, you defeated the universe. But you get my point. There's only one way to interact with this app, and they repeat that. They keep it super, super simple. Our applications, of course, are often much more complicated than that, but it's important to identify where our users derive or retrieve the core value from applications and find ways to replicate their mental model of that through our application where it is relative. Another example of an interaction that is repeated that provides very serious value, I think, is the iPhone thumbprint scanner. This is effectively de facto authorization interaction. So to log into my phone, I just tap, man, that's great. Sometimes it's buggy for sure, but when I want to buy a book, an iTunes, sorry, a book and iBooks or an album on iTunes or whatever it may be, there's always an authorization step. And they've improved and sped that up quite a bit by allowing me to hold my thumb there instead of typing a password. But they've also repeated this in multiple similar scenarios instead of just only once when you log into your phone, right, or unlock your phone. So repeating those core interactions or repeating those interactions are going to cement, in this case, a sense of security in your app. But also it repeats your value and your users know what they're getting. So I decided to call this Goliath mode because it's like, you know, you build up this great fantastic application, like it solves everything your user needs, everyone's raving about it, and then your user loses internet connection and then it's like snow caved your roof in. The application is dead, there's no value to be gained from it. There'll be disallowed editing. I think in most cases we shouldn't. Here's one example of where I get really angry. This is actually a document when I was working on this talk. Trying to connect. I can't do anything. I'm just like sitting here looking at that little yellow thing. The rest of the website of Google Docs doesn't show me that I can't interact with it. I just start typing and nothing happens. It's incredibly frustrating. All right. Just that's what I think about Google Docs. So Spotify, they just let you know if there's generic message, which is slightly cut off up here, but connection lost. I see this generic message. I know that there's an issue. It's very different from the rest of the application. It's really easy to see and understand, but they still allow me to kind of click on their application. Even though that new music is going to come, or like if I click to browse an album, I know not everything's going to load. Perhaps if I've preloaded something, if I've looked at it previously, maybe it will react and load immediately. I like this term, responding optimistically. I think we should be careful with this. I'm setting this to offline mode. Instagram does a pretty good job. So I can like, I can actually interact with the core interactions of Instagram's product on their web app without being online at all. Presumably when the Internet connection, sorry, when my connection is reestablished with a server, it can send the updates. It'll store those, queue them up, fire them up. That'd be ideal. Certain scenarios, we can't always do this, obviously. We don't want to pretend like something happened if it's a sensitive thing. But if it's something like an Instagram case where the user closes the browser before you had a chance to connect with the server and they come back to Instagram on their phone, they're not going to see that image anyway. This actually poses no real effect on their future life. That's really just a moment, and they recognize that. Okay. With that, we are working on a project to effectively create a design pattern library. So we want to document methods and design patterns for use directly in our applications for Ember. We want to provide code examples of certain implementations of those that we believe can help our community grow and help our community build and design better applications. We're going to try to do that through project recalling tools of the trade. Right now, you can sign up for our release date on tools of the trade.doccare.com. But what we really hope to do, once we've got the first initial patterns out the door and methods for you, we'd like to get your help. So if you are experiencing challenges and you have a design solution that you think is applicable and helpful to the rest of the community, we'd love to get your help. We want to open source this and create more patterns. Thank you.
 So I made this slide just to mess with you.  There's no presentation loading.  So I'm going to start this talk off with a metaphor.  All of us here, building with Amber, we're designing a house.  I chose the metaphor of the house because much like the applications that were able  and capable to build with Amber, we're dealing with an infinite or an impossibly large number  of use cases and problems to solve.  There are rules and regulations in place that we both have to discover, but also beyond  that have to uphold and abide by.  It makes for a very complicated job.  Because like Amber actually allow us to create digital solutions that we couldn't have  possibly imagined just a few years ago.  And again, the number of use cases that we're encountering through our projects are just  overwhelmingly large.  Everyone uses them different.  It's really important for us to understand our audience and what our ultimate solution  is going to be.  So we're also building a lot of them.  We're building a vast network of interconnected experiences.  I'm Stephen Chirbathin.  I'm partner and creative director at Dockyard.  We're designed driven software consultancy based out of Boston, Massachusetts.  So we might know of us perhaps from our contributions to Amber.  We've got Rob and our team.  Oh, thank you so much.  Okay.  So my talk is going to be about designing for single-page applications.  And I've broken my talk into a couple parts.  With the intent of explaining the first part of my talk, I'm going to be your pain in  the ass user.  I'm going to hate the house that you built me.  I'm using the house metaphor, by the way.  I'm going to hate the house that you built me and curse at the front door that you chose.  I'm going to show a little respect for you and the challenges that you faced in creating  the solution for me because it doesn't satisfy my personal needs or tastes.  Even if you give it to me for free, open source, I'm going to show you how much pain you've  caused me without acknowledging anything that you managed to do right.  Does that sound familiar?  I'm sure a lot of us.  And for the newbies in the audience, welcome to the world of making things for people.  So how do we stop our users from spitting all over us and treating us like this?  I'm just so excited to have this as a slide.  Well, first off, we don't marry them.  Second, we start with mental models.  We start with trying to understand where our users coming from, who they are and what types  of interactions they deal with on a day-to-day basis that we may be able to borrow from for  our own scenarios.  Does anybody know what mental models have experience working with mental models to know  how they impact your reception of your application?  We got a couple.  I was talking for a few hands out there.  Cool.  Nobody.  I love it.  So mental models is both what I think the thing is and how I think the thing works as a user.  So that is all developed really from my past experiences.  So experiencing one object, say, a laptop, and then I come to another laptop, I expect  a certain type of experience.  I'm saying laptop because I see a ton of laptops right now.  But I see, you know, you expect your experience or the solution to match those from your experience  or at least improve upon them.  So they're not always solid.  A mental model is ever evolving throughout my life as I come into contact with different  objects as I use them.  They can be updated or changed by certain innovations.  So if I improve upon a particular feature or function, it's great for us to release that  out into the world, use it in our apps, and have that become the new de facto standard.  I think the pull to refresh was actually one of those scenarios which is kind of now outdated,  but for the time being that was a really great scenario and that sort of built itself into  mental models of users with that type of content or feeds.  So I'm going to take the home metaphor a little bit further.  We're going to try to analyze what I think a home is.  So what is home?  How do I know a home is home?  What is my mental model of this?  Home is really a concept of home is greater than the concept of it is greater than the  sum of all the features that the home actually offers me.  It's more than just the kitchen sink.  It's more than the couch.  It's actually a total experience.  I think of home.  I think of a lot of things simultaneously.  Is this a home?  Certainly not.  It's hardly passes for a raft.  These kids are running away to form a rival to the insane clown posse.  Is this a home?  Perhaps House of God, but it's a little bit too lavish for me.  I am not worthy.  All right.  You know I was going to get to this slide.  This is a home, right?  This matches all of our models or understanding of what a home should be.  There are things about this, though, characteristics visually that we're able to identify really  cleanly and clearly.  There are windows of particular widths and heights.  They're equi-distant from each other.  There's a door.  There are gutters.  There's a roof.  The building itself is of particular shape and it's often nestled between other buildings  of similar shapes.  This may all seem really obvious to you, but this evolved over time.  If we compare this to this, we notice that this actually still kind of seems like a home,  but you're judging it.  You're valuing this home very different from the other home because there are very unique  characteristics that break them apart, that make them different from each other, but they  still share some common experiences, common design patterns.  Still has windows, still has a roof.  It's got a chimney.  It's got a door for access.  There's something about this that makes it very weird and that's really the shell shape.  Your interpretation of the value of this object is based off of your previous experience  with houses and how those function and seeing how this one might function differently than  yours.  There are two types of mental models to be aware of when we're designing our apps.  There's the macro, which is really the point of view that we have in the house.  That's from a distance.  It's before I've actually had a chance to interact with it on a micro level.  It's the assessment that I make on what I believe it's going to do for me.  It's the thing that makes me want to go, things that make me want to try it and experience  it for the first time.  A lot of people write this off as marketing, but I have a different approach to that and  we'll talk about that a little bit later.  The macro experience is how I think the individual interaction works itself.  It's how I think it, like the specific feature, will work.  It's also what I think the application will do on an individual feature by feature basis  and ultimately the micro model is where the core value or core interactions of your product  are derived.  This is the last of the house bit, I promise you.  This is a door that I need to say it.  On a micro level, this is a particular feature of the home.  It's got a handle that turns, the door is going to swivel in and out, close, it's got  a lock, and so on.  That's great.  It seems pretty simple.  This is a different door.  If I were to interact with this, this is actually very similar to a lot of experiences I have  on the web.  You come to believe that this is the way things are going to be, this is how it's going to  work, this is what I should come to expect.  Somebody decides that their application needs to be super secure and then they add all these  locks that just really interrupt my flow and my process.  On the micro model, this doesn't quite match.  If we printed out the feature list, though, of course they would match.  Like both of these doors probably have the same feature list.  Should open, should close, should lock, go on.  All right.  I'm going to shed the whole metaphor.  We're going to talk about digital experiences and how the mental models actually apply to  what we're creating today.  A few of us may be familiar with the Motorola Razer.  Anybody else have that phone in here?  I definitely did.  It was miserable sending messages.  We're going to ignore the keyboard on that phone.  We're going to talk about this interface here.  We've got a large space for composing message.  We have an OK button at the bottom right.  I realize when I put this together that some of us in the room are probably not old enough  to know what this is.  It's really depressing.  All right.  So I say, well, I'm a messenger.  I wish I could use my laser from here.  I don't think it's going to, you know, I can see anything.  But there's a bunch of erroneous features that we can ignore that thank God we kind of shed  them as we push forward in chat-based applications and in texting.  But generally this is the same thing.  We have a large composure box and we have a send button at the bottom right.  There has been added a dialogue, though.  We can see that history right here.  This is a very squished view of Apple's messages application.  Again, there are things that are really, really similar to each other, but from the Motorola  Razr experience to the AOLN submersion drive, I forgot the name, I haven't used it in so  long, to messages, we don't have that large of a mental jump.  The leap is very short and easy to cross.  So we still have a messages box at the bottom and when you start typing your message, you  are able to hit send.  This is my favorite example.  Does anybody know what this experience is just by looking at it?  I'm waiting for someone to shout it.  People are probably a little embarrassed to say it.  So this is Tinder's communication experience.  So look at the difference between this one and this one.  Like this is, it's not even different.  Like I believe the Android phone, sorry, the Android Tinder application actually operates  very much the same way.  The point here is that the users of Tinder already had a model for short transmission  length, but really high frequency of communication.  That was called texting.  That already existed.  So they're able to take from this experience and effectively model their behavior in their  application because that's what they wanted.  That's what they knew their users were going to use.  This is critically important to notice.  Somewhere out there in the world of your target audience, the applications that you're building,  problems you're trying to solve, there are models for interaction that already exist,  both macro and micro.  And if you're able to build the applications and design them in such a way that utilize  those, whether the applications are strikingly similar or even competitors, you're able  to build a framework of understanding.  It's going to allow me to get to know your application, to see the value.  It makes your application more usable, and it also gives me a clear path to learn.  Some applications have a very difficult learning path, but you believe in the value so much  that you're willing to dig through it.  I don't think that always has to be the case.  This is an example of a direct copy that gets you sued.  Don't do that.  Selling mental models is different from directly copying a competitor's solution.  As I should with Tinder and Messages, those aren't really competitors.  They're really promoting Apple's platform by using that space.  Ultimately, people will move off from Tinder and start using their texting anyway.  It's not really competing with an app.  It's not like Apple is selling Messages app.  It's a bare base app for the product.  So anyway, we don't want to start nature of wars with people.  So don't copy.  Just try to understand the mental models and how they may apply to your experience.  You should use them explicitly if they directly apply to an experience.  So I've already interacted with the Jillian radio buttons in the world.  You don't necessarily need to redesign a radio button all the time.  Some cases, there may be unique value to be gained on that micro level, but generally,  you can just keep using it.  But you want to break them where you can improve the understanding and value of your product.  This is a really good example of that.  You'll probably know what this is just by looking at this part.  I just wanted to focus the shot here.  But this is the first generation iPod.  I was not lucky enough to have one.  I had a bunch of really crappy MP3 players.  But all the other MP3 players at the time operated on a D-pad.  So if you want to navigate through your folders of media to gain access to certain music,  you would actually have to press up and then press down and then navigate into the right  one and then back out when you decided I don't want to listen to that song.  Apple actually produced a really incredible design for this.  You can use one continuous motion instead of constant tapping, exhausting tapping and  with annoying clicking sounds.  You can use that one continuous motion, which is actually kind of fun, and much more quickly  move through your file structure, your folder structure.  Of course, we changed the paradigm of the folder structure over time, but that's how  things worked at this period, I think.  So they both increased the ability for users to move through their product, but they also  created somewhat of a fashion item that was really unique.  And this is an example of a micro model here or a micro interaction.  So this is just one part of the whole.  And differentiating here made a big difference for Apple.  So how can we in our applications start creating experiences that delight our users, differentiate  our products so much, and really cement the value of our product in our user's minds?  We want to do that through creating repeatable design methods and design patterns for both  interactions and song.  So I'm going to talk about five major ones here.  So one is gradual engagement.  This is really more of a method than anything.  It's not necessarily a particular pattern because it's going to be very different with  every product that you design.  But the idea of gradual engagement is that you can reduce the perceived risk of signing  up for your application by allowing them to get to know it over time.  A good example of that is Pandora.  Instead of throwing a sign up wall to start their radio, they actually drop you right  there on the homepage.  It communicates that it's a new type of radio.  Okay, I've got the radio in my head.  And it plays stations that only I like.  So radio, personalization, good.  And a single text area.  So I start typing, go to Panda.  I move forward and my, it's done.  Like I get the core value of this product.  It's already starting, it's music.  I can listen to it for free.  I'm able to access and understand what Pandora is ultimately trying to provide for me and  why I should like it or why I should use it.  I didn't have to sign up for that.  It's great.  After a number of songs, they may tell you or ask you to sign up to continue playing  the radio, but you've already gained the value from them.  It's a much easier sell.  This is a video and unfortunately, screen dimensions are a little off, but GuShark does  effectively the same thing.  And they are loading just, just look at that, double spinners.  I'm saying they necessarily do it perfectly.  But down here I'm adding a whole StereoLab album.  My favorite ones are theirs.  And I'm playing.  I get so much of that experience without requiring to do any real work up front, aside from learning  their UI.  But that's a good thing.  I learned your UI.  I found the value.  Maybe I'll sign up and save it.  So I kind of complained about the spinners for a little bit.  I don't know if we can get rid of them or at least get rid of a lot of them.  There's some cases where you might want to keep them.  I understand.  But there's a better way for the most part.  That's with Skeleton UI.  So this is Google Maps.  I'm actually not sure if you can see on these screens, but there is a grid that's in the  background that resembles content to be.  It's effectively just a tile.  It doesn't even have to line up with the image that's rendering there.  But the idea is that you can give your users an increased sense of speed of your application  by providing sort of a stand-in or scaffolding of content to come.  Instagram does an OK job.  It's in your CY.  They basically did the bare minimum.  Sorry if anyone's from Instagram here.  But they did the bare minimum, I think, for their application for a Skeleton UI, but  it still helps.  It's still better than just having a blank screen with a spinner.  So here I know that there's an avatar that's going to show up.  I've got labels for posts, followers, and following.  My follow and unfollow button is just sitting there saying loading for some reason.  I guess they didn't know where else to put the loading.  Facebook actually does a much better job.  This is their application, of course, the mobile app.  Let's look at their web application.  They do the same thing.  So if you can see, there's a little bit of an animation on those content or the scaffolding  on Skeleton UI that we have there.  And it gives you a much better sense that something is happening, that the product is  moving forward.  It's listen to your request and content's coming.  It's on the way.  Hold tight.  Another product that does this really well, and I think they do it the best, is Pinterest.  They actually source the image height or dimensions to produce their tiles, as they do here.  And since it is an experience, really kind of a lookbook, Docker, I'd actually create  mood boards using Pinterest.  And I've grown to fall in love with this product.  I don't know if people really use this as much as I do.  But they've also sourced the base color from all these images, and they present with that.  And then they load the images in.  It's pretty simple, but it's beautiful, and it actually fits really well with the core  interaction of the product.  Another thing I think that we could be doing better, is carrying context.  So don't leave me waiting at the bus stop.  If one parent chaperone or bus driver drops me off at the bus stop, I expect my parents  to pick me up.  And I think that's true for applications.  So I think a really good example is Ardio and Spotify.  So in this case, if I'm playing Ardio on my laptop and I go over to my iPad, let's say  my laptop's in the other room, and I want to change the song because it's playing on  my speakers, and it's hooked up, and I'm sitting somewhere else, I can actually tap here on  my skip, or I can change the song, and that's great.  I can actually operate my application from a whole other location.  And that's fantastic.  So I can do that here as well.  There's a couple reasons why this is really nice.  Obviously, added functionality.  I can see that it's currently engaged with elsewhere.  But I also get a greater sense that the system really knows where I stand.  It knows more about me and my current experience with the app, and it presents that back to  me.  Spotify does effectively, they do a fair job.  I like the way that Ardio did it better, although Spotify's actual engineering seems  to be better.  It's faster.  But this is what we call an intercom or a generic message at Duckert.  They effectively just say your music has been paused up here.  So that's the kind of indication that they give, indicated that they give to you if you're  on a device that's no longer the control point.  But you can still interact with the application.  They don't block you from interacting and playing with it and making changes.  And there's one case where I can give you an example for a major save.  So in the case of continuous streaming music, that's a really easy thing to understand why  you should be able to operate in both locations.  But here's another one.  Imagine that you're giving a trade or making a trade of a couple hundred thousand dollars  and you're making investment for a client and it's $3.55 and you've got to get it in  before the market closes at four.  A lot of pressure.  You're in the middle of making the trade and your computer dies or something.  It just catches on fire.  Some monkeys take it.  Then you're able to pick it up on your phone.  Imagine if you're able to just pick up your phone, log into the website and pick up right  where you left off.  See that you've made it halfway or 70% of the way through the trade, entering certain  information about how you want it to work.  And you can trade.  Done.  It's a major save.  You could have saved your client hundreds of thousands of dollars.  You could save yourself a job.  Core interactions are really more of a micro-model layer.  There are the things that cement in that value.  So the whole reason someone should use your application to be conned with is the example  of reusing core interactions.  Some applications have many of them.  Other ones have just a few.  What I'm showing you right now is the way that Pinterest actually works.  So core interaction of Pinterest really is going on a tangent.  It's just browsing, just looking at something, becoming interested, clicking on it again,  finding something else that looks just like it.  Wherever you go in Pinterest, you're able to click and follow a new tangent.  So that's a repeated core interaction here.  An example of...  Oh.  Okay, I might have actually moved that slide one forward.  So the core interactions actually become a symbol of our app.  So when we come to understand the value, we come to understand why I should be using app  to begin with, and you repeat that over time, that micro-model of the individual interaction  that experience I'm having will override and become the macro-model.  It will become what I remember your application by.  When I go home and I think of your application, I think of those things.  Think of the experience I had with it.  When I open a can of Coke and I drink it and I throw the Coke away, what do I think about?  I think about the experience of drinking Coke, not about necessarily their ad that was on  the subway.  And that's the same as true for our applications.  Another example of repeating a core interaction is threes.  A lot of us play threes.  Yeah?  We've been obsessed about this game for a while.  Essentially you just use the same interaction.  You win or lose by, I think this game actually you only lose.  At least I do.  I don't think you can ever get to a point where it's like, ta-da, you defeated the universe.  But you get my point.  There's only one way to interact with this app, and they repeat that.  They keep it super, super simple.  Our applications, of course, are often much more complicated than that, but it's important  to identify where our users derive or retrieve the core value from applications and find  ways to replicate their mental model of that through our application where it is relative.  Another example of an interaction that is repeated that provides very serious value,  I think, is the iPhone thumbprint scanner.  This is effectively de facto authorization interaction.  So to log into my phone, I just tap, man, that's great.  Sometimes it's buggy for sure, but when I want to buy a book, an iTunes, sorry, a book  and iBooks or an album on iTunes or whatever it may be, there's always an authorization  step.  And they've improved and sped that up quite a bit by allowing me to hold my thumb there  instead of typing a password.  But they've also repeated this in multiple similar scenarios instead of just only once  when you log into your phone, right, or unlock your phone.  So repeating those core interactions or repeating those interactions are going to cement, in  this case, a sense of security in your app.  But also it repeats your value and your users know what they're getting.  So I decided to call this Goliath mode because it's like, you know, you build up this great  fantastic application, like it solves everything your user needs, everyone's raving about it,  and then your user loses internet connection and then it's like snow caved your roof in.  The application is dead, there's no value to be gained from it.  There'll be disallowed editing.  I think in most cases we shouldn't.  Here's one example of where I get really angry.  This is actually a document when I was working on this talk.  Trying to connect.  I can't do anything.  I'm just like sitting here looking at that little yellow thing.  The rest of the website of Google Docs doesn't show me that I can't interact with it.  I just start typing and nothing happens.  It's incredibly frustrating.  All right.  Just that's what I think about Google Docs.  So Spotify, they just let you know if there's generic message, which is slightly cut off  up here, but connection lost.  I see this generic message.  I know that there's an issue.  It's very different from the rest of the application.  It's really easy to see and understand, but they still allow me to kind of click on their  application.  Even though that new music is going to come, or like if I click to browse an album, I know  not everything's going to load.  Perhaps if I've preloaded something, if I've looked at it previously, maybe it will react  and load immediately.  I like this term, responding optimistically.  I think we should be careful with this.  I'm setting this to offline mode.  Instagram does a pretty good job.  So I can like, I can actually interact with the core interactions of Instagram's product  on their web app without being online at all.  Presumably when the Internet connection, sorry, when my connection is reestablished with a  server, it can send the updates.  It'll store those, queue them up, fire them up.  That'd be ideal.  Certain scenarios, we can't always do this, obviously.  We don't want to pretend like something happened if it's a sensitive thing.  But if it's something like an Instagram case where the user closes the browser before you  had a chance to connect with the server and they come back to Instagram on their phone,  they're not going to see that image anyway.  This actually poses no real effect on their future life.  That's really just a moment, and they recognize that.  Okay.  With that, we are working on a project to effectively create a design pattern library.  So we want to document methods and design patterns for use directly in our applications  for Ember.  We want to provide code examples of certain implementations of those that we believe can  help our community grow and help our community build and design better applications.  We're going to try to do that through project recalling tools of the trade.  Right now, you can sign up for our release date on tools of the trade.doccare.com.  But what we really hope to do, once we've got the first initial patterns out the door  and methods for you, we'd like to get your help.  So if you are experiencing challenges and you have a design solution that you think is  applicable and helpful to the rest of the community, we'd love to get your help.  We want to open source this and create more patterns.  Thank you.
Designing_for_Ember_Apps_0_83.png Designing_for_Ember_Apps_84_323.png Designing_for_Ember_Apps_324_443.png Designing_for_Ember_Apps_444_539.png Designing_for_Ember_Apps_540_2051.png Designing_for_Ember_Apps_2052_2399.png Designing_for_Ember_Apps_2400_3611.png Designing_for_Ember_Apps_3612_3827.png Designing_for_Ember_Apps_3828_4031.png Designing_for_Ember_Apps_4032_4463.png Designing_for_Ember_Apps_4464_6251.png Designing_for_Ember_Apps_6252_6959.png Designing_for_Ember_Apps_6960_9575.png Designing_for_Ember_Apps_9576_9839.png Designing_for_Ember_Apps_9840_15983.png Designing_for_Ember_Apps_15984_17447.png Designing_for_Ember_Apps_17448_17615.png Designing_for_Ember_Apps_17616_18167.png Designing_for_Ember_Apps_18168_20159.png Designing_for_Ember_Apps_20160_21791.png Designing_for_Ember_Apps_21792_22523.png Designing_for_Ember_Apps_22524_22799.png Designing_for_Ember_Apps_22800_23027.png Designing_for_Ember_Apps_23028_25451.png Designing_for_Ember_Apps_25452_26123.png Designing_for_Ember_Apps_26124_26207.png Designing_for_Ember_Apps_26208_26255.png Designing_for_Ember_Apps_26256_26567.png Designing_for_Ember_Apps_26568_26675.png Designing_for_Ember_Apps_26676_27983.png Designing_for_Ember_Apps_27984_31223.png Designing_for_Ember_Apps_31224_31451.png Designing_for_Ember_Apps_31452_32963.png Designing_for_Ember_Apps_32964_34103.png Designing_for_Ember_Apps_34104_36731.png Designing_for_Ember_Apps_36732_39599.png Designing_for_Ember_Apps_39600_40211.png Designing_for_Ember_Apps_40212_40487.png Designing_for_Ember_Apps_40488_40607.png Designing_for_Ember_Apps_40608_40868.png