Really Using Your Device Capabilities
•Transferir como PPTX, PDF•
0 gostou•1,097 visualizações
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Semelhante a Really Using Your Device Capabilities
Semelhante a Really Using Your Device Capabilities (20)
Mais de Steven Hoober
Mais de Steven Hoober (20)
Último
Último (20)
Really Using Your Device Capabilities
- 1. Really Using Your Device Capabilities One way desktop web thinking doesn’t apply to mobile @shoobe01 #modevux 1
- 2. 2
- 3. That’s better 3
- 4. Just add a button 4
- 5. How does this happen? 55
- 6. How to avoid it Design for Every Screen: • Gather information • Design for users, tasks, and goals • Don’t make assumptions about any one technology, interface or platform • Create a blueprint of the whole service… then branch out • Design to target (end goal) experiences 6
- 7. <p>These are our mobile numbers. We reall <table Everyone can play <tr> <td width="50%"><span class="tel"><h3 clas <p class="value"> <a href="tel:1-816-210-0455">816 210 0455< width="50%"><span class="tel"><h3 cla <p class="value"> <a href="tel:1-816-210-0468">816 210 046 </tr> </table> <h2 class="zero">Visit us</h2> <p>We like visitors, and presents. Come by or7ma
- 8. With a lot of services <a href="sms:1862100455?body=Check out what.. <a href="mailto:steven@4ourth.com">Email Me</a <a href="http://maps.google.com/maps?hl=en&q=5 8
- 9. It’s okay to use these On mobile devices. But still not desktops. 9
- 10. If they leave…. 10
- 11. …they will come back Users: • Look at the handset 150 times a day • Switch tasks 27 times an hour • Switch gaze every few seconds 11
- 12. Mobile is the web experience No desktop web for: • 25% in the U.S. • 59% in India • 70% in Egypt There are 1.8 billion mobile web users. 5 billion people use SMS. 12
- 13. What about your project? Analyze. Think about context and value. Embed truly integrated tools. Don’t launch them if that plan doesn’t work out. 13
- 14. Steven Hoober steven@4ourth.com +1 816 210 0455 @shoobe01 shoobe01 on: www.4ourth.com 14
Notas do Editor
- Today, since I can’t yet talk about any specific projects, how about a specific facet of design that I keep encountering – and correcting – across many mobile experiences?
- This is very typical of a diagram I might encounter when I come into a project late, or go to revise an existing one. You build a page – or function – for users to compose messages to their friends and cohorts, and share whatever info it is your service shares, via email or sms.
- But it’s (almost always) the wrong way to do it.
- If you need to allow customers to share via SMS, or send emails, or get driving directions, or look for local amenities, why would you build it in, when you can just add a simple button? You don’t build a voice application because you want them to call you, do you? Okay, there’s sometimes a little more to it than a button or link, but not a lot more. It certainly saves a LOT of design, development and testing.
- Okay, you might think this is obvious. If you have never, ever encountered it you may ignore me, then check your email. But for everyone who has encountered this, or some similar waste of resources, when an existing feature could do the job better, how does this happen? Well, because web design made all of us, and all of our processes, lazy. You’ve been in meetings where development is estimated based on page count. And page count doesn’t require a UX team to create even something as high level as an IA diagram. Everyone just starts counting the features that some BA, or development manager, or product owner made up. A line in a spreadsheet, or a card, equals a page, on average.
- Not only does this limit the development of interesting interactions, it also means you tend to blindly build out a page for each feature. Not just bad designers and developers, YOU. I have done it. Mistakes are how we learn. But now is time to learn the lesson.I get around this by being very deliberate on my processes. See, I got back to my Design for Every Screen concept after all. Understand the problem, the business, the goals, the users and their goals.Design the process. Even if out of scope for now, consider the whole system, including data structures and cardboard boxes and bits of paper at call centers. Do not design for any one device, or technology, but DO design for all of them. If your scope includes desktop web and call centers and mobile, then you can design so customers contact via email with attachments, voice and SMS as they see fit. THEN, when the system-wide flow makes sense, start specifying specific interfaces and interactions.
- And before I get questions and get accused of being all app-centric, the web can absolutely do this also. Back to the core examples, you’ve all seen how a phone number link works in a web page or email, or text message, right? Well, to make sure it works, you don’t rely on auto-detection, but code it as a phone number.
- And not just voice. You can initiate SMS or email Email. You can send locations to Google Maps. Not perfectly, sure, but almost always. There are absolutely variations and unsupported features, and old versions of the code. Just like most cool feature, you have to check device by device. But there are also basic functions, workaround, and hacks so you can be positive your targeted platforms work fine, and most other devices still work, as a bonus.
- A lot of this, like the email link, will be somewhat familiar. But you probably haven’t used it (except under duress) for years, as it’s worst practice.On desktop, flipping to the email program is dumb, because it loses all context. But switching apps is the expected behavior in mobile; the email app has more input modes and generally more intelligence about you. Best practices vary between platforms. Remember my principles of design. Make none of these constraining assumptions but consider everything, THEN design the methods specific to the platform.
- A lot of the pushback I get is around encouraging users to leave your process. This is just over-applying pithy marketing catchphrases like “three-clicks and they are gone,” to everything. Mobile usage is different, and you probably don’t scream “coffee is for closers” at your developers anyway, so get everyone used to the context of what you work on, and for multiple platforms. Even Apple finally has “Fast Switching” so there are no pitfalls on any major platform. But philosophy doesn’t always work. So, first, I always have to say: They will leave anyway. Interruptions abound – even on desktop, where this diagram actually comes from -- and the model (possibly for very good cognitive psychology reasons) is that activities take up the whole screen on mobile, unlike the windowing nature of desktops. *** 86% use their device while watching TV. They do both, or switch back and forth…
- So, users get interrupted, and get bored and leave. And come back. This is why you have to build enticing, enjoyable experiences. So they WANT to come back. Whereas you have in the past assumed a typical desktop user, who switch tasks on their computer 4 – 5 times an hour, mobile users can switch focus (between tasks on the handset, or from the handset to other media) every two minutes. You can’t stop this by wishing it to be true. As long as you make the app or site work, and preserve session so it’s still there when they come back from texting, or mapping, or watching TV, or talking to a customer, they’ll come back.
- In the US… in the US, 25% of those who browse the web do so exclusively on a mobile device. This is rising. In many countries, it’s much higher. OnDevice Research says it’s 70% in Egypt and 59% in India, where only 1.3% of households have an internet connected computer. I’ve seen figure for certain areas, such as parts of sub-saharan Africa where over 90% of internet traffic is from mobiles. You cannot assume there is a desktop. Not at work, not at school. Not for apps, not for the web. Mobile IS the internet experience for many of your customers.
- But all this is principles. It’s not a law. Just yesterday I had meeting at Cummins where I had to rally against inclusion of mapping as something poorly executed and not desired by end users. And then I go to the hotel room and draw maps for the startup I am helping some friends with. Because that is all about location, so we absolutely must integrate the map to the rest of the service. Or, take the trend of in-app messaging. Sure, do that. If it makes sense. If you have nothing contextual to say, just open an SMS window. And if there’s no way to fit it on the page with the contextual info, don’t bother just stuffing it into another tab; how is that better than just switching apps? And, no matter the plan, if it comes back crippled, or buggy, be prepared to rip it out and go with a link for that first release. Working software is better than sticking to the plan, right?
- This is what I, and some others, are talking about when we say it’s time to design for mobile first, or consider the complete experience. Don’t design for mobile just because your VP wants an iPhone app, and don’t assume anything about features because they are trendy or someone points at a popular example in a meeting. Do the right thing to provide services to every one of your customers, the right way, regardless of their platform. I didn’t document everything, but SOME of the info referenced is from:http://communities-dominate.blogs.com/brands/2012/02/the-state-of-the-union-blog-for-mobile-industry-all-the-stats-and-facts-for-2012.htmlRaquel Benbunan-Fich, Rachel F. Adler, and TamillaMavlanova. 2011. Measuring multitasking behavior with activity-based metrics. ACM Trans. Comput.-Hum. Interact. 18, 2, Article 7 (July 2011), 22 pages. DOI=10.1145/1970378.1970381 http://doi.acm.org/10.1145/1970378.1970381AnttiOulasvirta, SakariTamminen, VirpiRoto, and JaanaKuorelahti. 2005. Interaction in 4-second bursts: the fragmented nature of attentional resources in mobile HCI. In Proceedings of the SIGCHI conference on Human factors in computing systems (CHI '05). ACM, New York, NY, USA, 919-928. DOI=10.1145/1054972.1055101 http://doi.acm.org/10.1145/1054972.1055101Mary Czerwinski, Eric Horvitz, and Susan Wilhite. 2004. A diary study of task switching and interruptions. In Proceedings of the SIGCHI conference on Human factors in computing systems (CHI '04). ACM, New York, NY, USA, 175-182. DOI=10.1145/985692.985715 http://doi.acm.org/10.1145/985692.985715HannuVerkasalo. 2009. Contextual patterns in mobile service usage. PersonalUbiquitous Comput. 13, 5 (June 2009), 331-342. DOI=10.1007/s00779-008-0197-0 http://dx.doi.org/10.1007/s00779-008-0197-0http://www.businesswire.com/news/home/20120409005536/en/Time-Study-Reveals-“Digital-Natives”-Switch-Devices