Design for Many Devices

Hinweis der Redaktion

1. Thanks to Jan and his team for organizing. Great to be in Berlin.\n\n
2. I think, before I get started talking about cross-platform design today, it would be a good idea to let you all know that I really am a well-rounded person who enjoys more than just talking about mobile design!\n\n.5 min/.5 total\n
3. But, in my day job, I work at Adobe. I started working there last year after the web consultancy that I was working at in Vancouver, a company called Nitobi, was acquired - primarily for our work in the mobile space on an open source project called PhoneGap.\n\n\n\n1 min/1.5 total\n
4. PhoneGap, or Cordova, is an open source framework for building mobile apps using HTML, CSS, and JavaScript. It allows you to use web technologies to build applications for multiple mobile platforms.\n\nGreat - but this talk isn’t about meant to be about PhoneGap. Rather, what I’d like to talk about is what I have learned in when making cross-platform apps, and it is important that you know that I come from the experience of building them with PhoneGap and web technology.\n\n\n1.5 min/3 total\n
5. So, why even talk about building an app for multiple platforms?\n
6. Taking a look at these numbers from Gartner, we see that over the past 5 years, the market share has drastically changed. What was once the most common platform is now far from it. And there have always been multiple players in the field. It would be responsible to note that this data is saying nothing about who buys apps on which platforms nor who surfs the web most on which platforms. However, my point in showing this data is to say if your app is only available on one platform, then you are likely missing large parts of your current or potential user base, and you may not be prepared for the future.\n\nAnother interesting question that comes to my mind when looking at this data is “What operating systems are not showing up here, that might be in 5 or even 1 years time?” Firefox OS? Tizen? Thinking of the future when building your product is a good idea.\n \n\n2 min/7 total\n\n\n\n\n
7. Okay - so assuming you agree with me, then you might ask “How do I do it? Where do I start?\n\n\n.5 min/14.5 total\n\n
8. Let me start of by saying that creating apps for multiple platforms is hard. Designing products that are usable and awesome on multiple platforms isn’t easy, and can be tedious and puzzling work. Grappling with minutiae becomes an everyday occurrence.\n\n.5 min/7.5 total\n\n
9. why: use the tech, open source the assets & code, show what is possible, good times\nwhat: a to-do list application, easy to understand\nwhen: design process started in september, 2012\n\n\n\n\n1.5 min/4.5 total\n
10. .5 min/15 total\n\n
11. What challenges, specifically?\n\nTo start off with, there are significant hardware differences to contend with. Screen size (both width and height), screen density (that new third dimension - reference ppk’s article “a pixel is not a pixel” here), available inputs (Is it multitouch or trackpad? Is there a virtual keyboard or a hardware one? Are there hardware navigation buttons or do you need to take care of that in the UI?), and compute power (We know it is more powerful that a room-sized computer from ancient history, but that doesn’t mean that device has the same capabilities as that desktop/laptop computer that you may be more familiar with). This is not only across platforms, but within platforms, of course.\n\nIF I WAS trying to help these people out, I’d tell them how/where to find specs for the devices they’re focused on...but not sure that one canonical place exists. Maybe I should work on creating something like that in the future....though it seems like a lot of work for little return (would become out of date very quickly). Maybe in later slides, on “how to do it” talk about how to approach different screen sizes (fluid/responsive design), screen densities (images at various sizes? images at highest resolution?), compute power (no unnecessary code or assets, avoid layers of fluff [gradients, rounded corners]).\n\n1.5 min/9 total\n\n
12. How to do this? \n\nSame as it ever was: RESEARCH\nSpecific market research, statistics review (of your existing web-based app/site)\n\n* minimum viable product ought to be the goal - you don’t have to do everything RIGHT NOW, build upon what you learn once your product is out there.\n\n1 min/16 total\n\n
13. \n
14. What I mean here, is stop designing for a fixed width and height - it doesn’t exist. I’m not saying don’t make it look good, but rather let go of the idea that it will look the same on every device it is viewed on. Embrace responsive design (you’ve just heard a great talk on the subject)!\n\nAs for unnecessary flourishes - consider whether your users really want rounded corners, dropshadows, gradients, and textures. Over decorated interfaces can strain performance when building for mobile. Be judicious about what visual adornments you include.\n\n1.5 min/19 total\n\n
15. Then, there’s the software. So, to be clear, the Gartner data we saw before doesn’t really get into the nitty gritty. The report just says that “X” is the operating system, but not which version. And the version is oh so important. For example, the differences between Android 2.3 (Gingerbread) and Android 4.1 (Jellybean) are significant, not only in the operating system’s UI, but also in the capabilities. For example, touch events are pretty messed up in gingerbread - multitouch doesn’t work in the webview.\n\nAlso, if you’re using the device’s browser to render your application you’ll likely be dealing with WebKit. But which version of WebKit? And what are the differences?\n\n1.5 min/11.5 total\n\n\n
16. Are analogies dumb and overdone? Have I ever seen it done well? Is it condescending or does it really help to understand the concept?\n
17. Create functional prototypes and test on the actual devices you’re designing for. Not going to tell you that designers have to do it, you can work closely with your developer team-member, but we do it with HTML prototypes.\n\nGetting something working on the phone allows you to quickly see the little things make a big difference in the overall experience you’re want your users to have, and those are hard to see when you aren’t on the device.\n\n\n1 min/20 total\n\n
18. .5 min/20.5 total\n\n
19. Not to mention the fact that different operating systems have difference conventions to how actions and tasks are completed. Think of the difference between how a user might usually delete a list item on iOS (swipe left) versus how it might be done in Android (sustained press for context menu). Knowing these differences is crucial if you are going to design an application that is learnable by users on many platforms.\n\n1 min/12.5 total\n\n
20. Are analogies dumb and overdone? Have I ever seen it done well? Is it condescending or does it really help to understand the concept?\n
21. Use the devices you’re building for - get really familiar with the platforms and the patterns therein. \n\n* get familiar with HIG for each platform - they exist for a reason...but don’t expect to stop there. You gotta use the devices.\n\nCASE STUDY: threedoo meant personally trying multiple existing to-do list applications that exist on different platforms, along with other cross-platform apps.\n\n1.5 min/17.5 total\n\n\n
22. text entry/keyboard hide show: difference on iOS and Android\n
23. Different platforms call for different designs - don’t be afraid of that!!\n\nAlso, be open to learning a thing or two - and to breaking the mould when you need to. All of the best solutions have NOT been created yet, and we shouldn’t be expecting operating system vendors to solve all of the problems (or assume that their solutions are the best for our app’s users). I’m certainly not saying “go out, change everything, design everything in a new and different way, and change everything often”...predictability is good.\n\n1.5 min/22 total\n\n
24. When a brand is more important than the operating system of the device that it is running on - McIntosh Labs\n
25. 1 min/13.5 total\n\n
26. Develop using the technology stack that makes the most sense for your situation.\n\nDo consider, though that if you build for the web you can:\nReuse code (that exists now and in the future) that you’ve already created for the mobile web\nNo vendor lock-in\nNot always “easier”, but you likely have existing skills\n\n
27. \n