 So I made this slide just to mess with you. There's no presentation loading. So I'm going to start this talk off of the metaphor. All of us here building with Ember, we're designing a house. I chose the metaphor of the house because much like the applications that we're able and capable to build with Ember, 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. Technologies like Ember 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, and we're also building a lot of them. We're building a vast network of interconnected experiences. I'm Stephen Chavathan. I'm partner and creative director at DotGuard. We're a design-driven software consultancy base out of Boston, Massachusetts, so we might know of us, perhaps, from our contributions to Ember. We've got Rob and our team. Oh, thank you so much. 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've built me. I'm using the house metaphor, by the way. I'm going to hate the house that you've 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've 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 our own scenarios. Does anybody know what mental model is? Have experience working with mental models know how they impact your reception of your application? We've got a couple. I started with a few hands out there. Cool. Nobody. I love it. So mental model 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 as 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. 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 the mental models of users with that type of content or feeds. So I'm going to take the home metaphor a little bit further. And 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? The concept of home 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 a 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 a 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. This matches all of our models, our 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, or 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. And 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. And 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 had 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. So 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 was going to swivel in and out and close. It's got a lock and so on. And that's great. Seems pretty simple. This is a different door. And 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. Then 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 a 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 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. So a few of us may be familiar with the Motorola Razr. Anybody else have that phone in here? I definitely did. It was miserable sending messages. But we're going to ignore the keyboard on that phone. We're going to talk about this interface here. So we've got a large space for composing message. We have an OK button at the bottom right. We realized 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. So I say, well, it's a messenger. I wish I could use my laser from here, and I don't think it's going to 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. And this is a very squished view of Apple's messages application. Again, there are things that are really, really similar to each other, both from the Motorola Razr experience to the AOLN messenger. I forgot the name I haven't used in so long. The message is 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 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 any of the 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. Borrowing mental models is different from directly copying a competitor's solution. As I showed 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 of Tinder and start using their texting anyway, so it's not really competing with an app. It's not like Apple's selling Messages app. It's a bare-based app for the product. So anyway, we don't want to start nature-fors 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. In 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. And this is a really good example of that. People 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 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. It 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. 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 home page. It communicates that it's a new type of radio. OK, I've got 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, build Panda. I move forward, and it's done. Like I get the core value of this product. It's already starting its 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 then. It's a much easier sell. This is a video. And unfortunately, the screen dimensions are a little off. But Gushark does effectively the same thing. And they are loading these 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. Like 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 are 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 of an increased sense of the speed of your application by providing sort of a stand-in or a scaffolding of content to come. Instagram does an OK job. It's, and you'll see why. 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, DockGuard would 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 wanna 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 to like 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, right? So I can do that here as well. There's a couple of 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 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 but 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, right? It just catches on fire, some monkeys take it. Then you're able to pick it up on your phone. Like 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. This is working. Core interactions are really more of micro model layer. There are the things that cement in that value so the whole reason someone should use your application to be given one. Here's an 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. Anywhere 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, will become what I remember your application by. When I go home and I think of your application, I think of those things, right? 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. Like, there's only one way to interact with this app and they repeat that. 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 very 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 its de facto authorization interaction. To log into my phone, I just tap in. That's great. Sometimes it's buggy, for sure, but when I want to buy a book on iTunes, sorry, a book in 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 in you sign into your phone or unlock your phone. So repeating those core interactions or repeating those interactions are gonna 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 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's dead. There's no value to be gained from it. Should 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. Oh, I can't do anything. I'm just 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, 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 in our application even though that new music is gonna come or like if I click to browse an album I know that not everything's gonna load. Perhaps if I've pre-loaded 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 always do this obviously. We don't wanna 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 gonna see that image anyway. This actually poses no real effect on their future life. It'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 wanna document methods and design patterns for use directly in our applications for Ember. We wanna 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 gonna try to do that through project we're calling Tools of the Trade. Right now you can sign up for our release date on tools of the trade at dot care dot 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 wanna open source this and create more patterns. Thank you.