Nov. 8, 2011 webcast desiging mobile interfaces by steven hoober
•Download as PPTX, PDF•
2 likes•1,378 views
This webcast covers the intent of mobile patterns, and how to use them correctly in your design. Designed to be especially helpful for those migrating from other platforms, such as desktop web design. Presenter by: Steven Hoober
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Nov. 8, 2011 webcast desiging mobile interfaces by steven hoober
Similar to Nov. 8, 2011 webcast desiging mobile interfaces by steven hoober (20)
More from O'Reilly Media
More from O'Reilly Media (20)
Recently uploaded
Recently uploaded (20)
Nov. 8, 2011 webcast desiging mobile interfaces by steven hoober
- 1. Applying Patterns to Mobile Design Designing Mobile Interfaces: Patterns for Interaction Design 1
- 2. Why mobile patterns? To fill a gap in the literature: • Platform agnostic, without being technical. • Interface agnostic. • Structured and organized. • Researched and scientifically-founded. 2
- 3. How to use patterns • Understand the interaction and interface. • Understand the reasoning and use. • Know when not to use it. • Determine how to apply it to your design. • Codify it as a standard for your project or organization. This is what we’ll talk about today. 3
- 4. How to use patterns Apply the right information at the right level • Grid: Viewport, scale, type, gutters, margins and columns. • Wrapper: • Templates: • Pages: 4
- 5. Knowing history is knowing design • We always prefer the next big thing, and follow the winners. • But this has all happened before, and it will all happen again. • Know where ideas and technologies come from, why they work, and what failed about them in the past. With a good grasp of history, you can predict the future. 5
- 6. Patterns are not scrapbooks • Collection is not enough. • Curation is better. • Analysis and comprehension is the key. 6
- 7. Patterns are universal Mobile devices all share key attributes. Understand them all to understand any one. 7
- 9. Patterns are universal Live a mobile lifestyle: • Believe in your users, and your product. • Try out the competition. • Use mobile, even when you don’t have to. • Browse, share, tweet, photograph. • Try new things. 9
- 10. Patterns are generalized • Illustrative & explanatory. • Focused. • Examples can be confusing. 10
- 11. Patterns are organized 11
- 12. Patterns are organized 12
- 13. Patterns are explained 13
- 14. Patterns are explained 14
- 15. Patterns are explained 15
- 16. Patterns are best practices • Not necessarily common practice. • Not necessarily popular or fashionable. You have to know enough about why design works, and how your users work, to avoid trendy solutions and worst practices. 16
- 17. Patterns are misunderstood • Reactionary. • Rote solutions. • Single view. • Too high level. • First solutions. Avoid these traps to make good design decisions. 17
- 18. Learn more • Buy the book: Designing Mobile Interfaces available now as an eBook, soon in print. • Visit the Wiki: Basically the whole book is up on 4ourth.com/wiki. Check back for updates. • Listen more: • Next month, right here, Avoiding the Heuristic Solution – How to take your design from functional and correct to joyful and inspiring. • In January, User Centered Execution – How to get your well-intended, well- designed systems built as you want and, and promised. 18
- 19. Steven Hoober shoobe01@gmail.com 816 210 0455 @shoobe01 shoobe01 on: www.donttouchme.com www.4ourth.com 19
- 20. Special Offer Visit http://oreilly.com to purchase your copy of Designing Mobile Interfaces and enter code 4CAST to save 40% off print book & 50% off ebook with special code 4CAST 20 Visit http://oreilly.com/webcasts to view upcoming webcasts and online events.
Editor's Notes
- TEASER DESCIPTION: Applying Patterns to Mobile DesignGood mobile designs share many features in common, regardless of the fidelity of the device type, the OS or the user. Almost two decades of interactive design experience, as well as the creation of almost 76 mobile patterns for Designing Mobile Interfaces have led to some very specific and actionable insights into their use. Covers the intent of mobile patterns, and how to use them correctly in your design. Designed to be especially helpful for those migrating from other platforms, such as desktop web design.
- Conception/history of our effort (collecting for years, process, documenting by patterns, etc.) – Copied from architectural and CS classics, but even just Apple and Microsoft guidelines are like this (SHOW SOME?)What ORT asked for (so, iPhone only or also Android?), what we did instead… I assume confuses ORT a bit, as it’s more about design and psychology than technology and implementation.(had to add in implementation details at the end to satisfy all you guys)…
- That’s why you care about this: not how to read my book, but how to use principles of patterns to make your own work better and faster.Patterns are applied heuristics. You need to not just pick patterns to use, but be able to understand them enough you can bend them to your will. Then you are not constrained by patterns, but can use them for your needs, and customize and codify for your products, instead of just absorbing and re-using everyone else’s ideas.
- Patterns can be applied at various levels. I will assume everyone has the time to design in a reasoned manner, though sometimes it’s not that simple I know. When you start work, you set the grid, and not just the columns and margins, but you start setting standards you will use for type sizes, you have to set all this by knowing the viewport size (and physical size or scale) of the device or set of devices you will design for. Class-based design is crucial for multi-device design. At the wrapper level you start deciding which access methods to meet the IA. Do you use tabs? What kind? Where is the title, and how does it relate to navigational labels? Templates apply more of these, and assure that general rules decided above work for all the content types.
- We like to loose history; Apple didn’t invent almost anything, and it’s not to be an anti-fanboi, it’s that you need to know where things came from, what caused them to develop, what was abandoned and why.With a grasp of history, you also get a chance to predict the future. When we get to antipatterns this will make more sense, but basically, if a product failed for good reason, like good cognitive psych reasons (people’s brains don’t work like that) then you know not to try it again, without a sensible change.Here I have as examples:Palm IIIc - I have one of these that still works (I did not own one at the time) and glancing at it, it’s got all sorts of very modern interactions. With a wireless connection and a browser, it would be a pretty reasonable device today. The middle device is an early camera phone. I am pretty sure there were real embedded cameras in phones in Japan, but this was another way to do it. Didn’t take off. You might ask why? You might be able to come up with good reasons that most things which bolt on are not a great idea. Even Square went through a serious hardware iteration very early in their life, partly to fight the friction of Not-In-The-Phone.To the right is something I worked on, and which my wife carried diligently for years. The first MP3 phone in the world. Which had most of all no memory and a terrible way to get music onto it. But it worked, and there’s nothing radically different from even the use of iTunes as a management tool to synch music to an iPhone.
- This is gonna look like I am picking on Mari Sheibley. And yes, the image is from http://mobile-patterns.com/. But before that existed I had the same basic slide in other presentations.Actually, I’ve had much the same opinion for around 30 years. From the time I started acting like a designer, I collected interesting things. Mostly print things, so I had a whole file drawer full of magazine clippings. Which I eventually sorted into categories. But it took a long time to find a good image. And just having that file didn’t make me a better designer. It took decades of school and work to get there. Collection is not enough. Selective keeping and organizing is a bit better. But as I just said, you need to know a bit of why, how, and what came before, so you can predict how it will work in the future, for you. You have to analyze, and be able to do so in a coherent, repeatable manner.
- These are just some of the devices I actually own. A common question, right after “why a lovebird,” is what phone I carry.Doesn’t matter. Right now, a Droid 2 Global. But in the last 3 years I have carried -- full time, porting my number and everything -- 7 different devices with 4 different OSs. Part-time, a lot more than that.You need to keep your hand in the market, and not just stick to your favorite device. Because design is not about one device, or browser, and even if /your design/ is, you are missing out on other good ideas, and will miss the historical context these ideas came from, and misunderstand why they got this way.TACTIC: Image comparing same thing on a couple devices? Wording from “live a mobile lifestyle.” Use everything, and do not get locked into a platform. I haven’t carried an iPhone for years because I always work places where /everyone/ has one. I can borrow, ask, observe. Instead, I try other stuff and bring unique insights to the game. Switch it up. Image of my browser screen: Even on one device, try new software, and use the mobile for stuff you don’t absolutely have to. I have SEVENTEEN browsers on my handset now. I have a contract to do some browser design, but the principle applies to whatever interface you are working on. Don’t just look at the best case, or the most popular one in the Appstore. Look at all solutions.
- You can learn from anything, and be exposed to different solutions. There’s no iOS device here, because you know those, but here’s four other devices, on four different OS’s, showing four different ways to provide access to other screens via a tab paradigm (these are all covered in the Tab pattern in the book, yes). I found them -- and not just for the book, I’ve known many of these for years – because I find something to learn from every device.
- Use everything, and do not get locked into a platform. I haven’t carried an iPhone for years because I always work places where /everyone/ has one. I can borrow, ask, observe. Instead, I try other stuff and bring unique insights to the game. Switch it up. Image of my browser screen: Even on one device, try new software, and use the mobile for stuff you don’t absolutely have to. I have SEVENTEEN browsers on my handset now; they don’t even all fit on one screen anymore (this is just 16 of them). I have a contract to do some browser design, but the principle applies to whatever interface you are working on. Don’t just look at the best case, or the most popular one in the Appstore. Look at all solutions.
- Patterns are very non-specifc. Even talking about specific examples sometimes bothers me; just like when showing off your design everyone gets hung up in details of what color things are. I use illustrations. Not just in the book, but for all high level documentation and concepts. To the left is a typical illustration as used in the book. This one is explaining menu that reveals on gesture. To the right is a real one. A real finger obscures the image so much you cannot see anything, so I had to include two shots to show the action. And, what are you supposed to be looking at, anyway? The screen is full of stuff. On the right, the trash can sticks out to me. Fine in reality, as it’s deliberately obscured by the user, making it lower priority, but here it’s very obvious. Exemplars are useful, and experiencing real interfaces is key, but explaining interfaces requires illustration and explanation. Higher fidelity is used only as needed, such as when designing the actual interface. But that’s when you get people asking if you can change the color. Which is fine, if you have
- Part of the analysis of the patterns is grouping, and not just by immediate relations, but by higher level categories, and related tasks in other categories.Building a taxonomy of patterns helps understand them (it certainly helped me) and is designed to help you find them and use them correctly.They also cross-link a lot. Blue is the color used to mean “Pattern” throughout the book. Might be a bit hard to see, but there’s blue words all over the place on the right.
- I also want to be clear, this is not an easy thing. Weagnonized for a long time to get this right. And by “agonized” I mean we went back and forth a lot. I was bucking for a fairly different organization along a more functional taxonomy. Others wanted storytelling, or an approach by meaning to the end user. And even once settled, we spent time staring at the Google Spreadsheet this was organized in, working out what is included, and where, and how much it’s included.The number of patterns only settled down because we had to get the book out. I could have spent ten more years doing this, easily. Yes, the cat helped a lot.
- Similarly, we built an organizational structure to each pattern, which we strictly followed. Every one can be compared pretty much straight across. I am going to go ahead and go over each section, but not the way they are explained in the preface to the book, but why we did them, and how you can use them yourself. Titles were a pain. All too often, people have pet names. We had to avoid those, or OS specific names, or anything which could be confused with another. Some are a bit… clunky. Some seem jargony. “Annunicator Row” bugs some people, but annunciators are old-school and generic. Notifications are something else, so we couldn’t use that. Yes, really, we spent this much time thinking about (and changing) names. Problem is how we start each one. I like problem statements. This bugs a lot of people, especially in marketing and product development, who maybe want them to be “opportunity statements” or something. I say own up to your problems. Realy, here, it’s part one of the introduction. At the end, after feedback from others, we added the implementation-focused bit to the Problem section. Web, specific OS, or whatever domain it could be.The second real part of the introduction is the Solution. This summarizes the problem, often with a generalized illustration of a common version of it. If you don’t get the gist of the pattern after reading the title, problem and solution, we’ve failed.
- The next section is probably the most important one. More than even the title. Variations also caused a lot of heartburn. Because sometimes, a variation is worthy of being a pattern. Sometimes, two patterns start getting too close, and we end up merging them. Sometimes, there is not A and B, but a range of options between A and B. And also a range of options between C and D. Pick which you want along these two axes. Variations is sometimes very, very long, and it was easy to drift into speculation and possibilities. Interaction details is both the first of the two really tactical sections, and exemplifies a key distinction in design of interactive systems. There are interactions, and interfaces…
- … both that and the Presentation Details are basically lists of features, or requirements. Be sure to do things, and do them in certain ways. I’d rather have called this “Interface Details” but it sounds too close to ‘interaction” as well as the issue with people confusing the two. This does fine. Presentation details basically covers all the bits that just sit there, or which the user cannot control directly. Wording, color, shadow, spacing, even how words are read back in voice interfaces. My favorite section is the last, Antipatterns. Ideally, an antipattern is a complete pattern that you don’t do. But that’s not super-useful, and the name is catchy. So I use it here. There’s more to the reasoning, but don’t worry about it. Suffice it to say, if you do something in the antipattern list, your implementation will generally not go well. Read these, more than any other section. When building custom implementations, you will find your own pitfalls, or violations of other principles of your design, faster than good uses. Document them like this.
- The antipatterns we listed are also very often quite common and popular. But patterns are not just collections of popular themes in the world of design, or what I have taken to calling “common practice.” Fashion and interior design work differently, but UX is evidence-based. Just because it’s popular doesn’t make it right, and if there is clear evidence (from research, generally) that this is wrong, I say so.Many patterns are improperly implemented in the majority of devices. Now, I didn’t buck the trend completely; this example is simply that you need to hide pointlessly repeating avatar stand-ins. But that’s an easy fix, and there are several ways to do it. To the right is another solution, using the icon to denote the type of primary phone more clearly.
- Obviously, this is not a key attribute of patterns that we want to have. But it’s true. Patterns are misunderstood, and therefore mis-used.Design solutions are Reactionary and solve for point problems, instead of considering the entire system.Even when larger solutions are found, they are Single view or only for one screen, one device or one platform.The first satisfactory solution is accepted, and rapidly becomes entrenched. There should always be incentives to find the best possible solution.There is likewise no incentive to find unique, interesting or differentiable solutions. The Rote solution, or the published pattern, is used without modification (another reason I don’t like to give examples).Patterns that do consider solutions generally sometimes lead to excessively High-level design, with no reasoning (or an incomprehensible one). VizDs and developers won’t understand what part is important so will modify it and miss the point.I tend to call all of this the “heuristic solution.” It’s not /bad/ per se, in fact it checks all the boxes, but it’s not inspired, and is never truly satisfactory. It might even pass CSAT measures, and show improvement. But it levels off and you never get up to that really top-tier, no matter what you do. The example is an okay site. Each decision is at least marginally acceptable, but not great and only in isolation. As a system, it falls down.
- I’ll be talking more about that next month, with a whole presentation right here on avoiding the heuristic solution, while still applying patterns and other good principles. Buy the book now? Check the wiki out regardless.Example that we added the gesture library stuff after the book was completed.
- QUESTION TIME.