Do's and Dont's of Cross Platform Mobile Design
•
2 gostaram•1,070 visualizações
With so many tools available today to make applications run across multiple platforms, it's easy to think that a user experience can translate well to all platforms. The fact of the matter is, users on different platforms have different expectations. What works on Android might not work on iOS, and what works on iOS probably won't transfer well to Windows Phone 7. Apps should make use of features and UI elements specific to their platform, and make the user feel right at home on every possible device. Together, we can examine the design metaphors of each platform and determine the best way to provide a consistent and elegant user experience.
Recomendados
Recomendados
Mais conteúdo relacionado
Último
Último (20)
Destaque
Destaque (20)
Do's and Dont's of Cross Platform Mobile Design
- 2. Good Afternoon! #mobilecross
- 3. Thanks! #mobilecross
- 4. Thanks, Organizers ! #mobilecross
- 5. 2012 our sponsors. ^ M3 Conference founding platinum gold bronze + keynote friend thanks for all the support. #mobilecross
- 6. H ELLO my nam e is n Fjustinerrell s t i b ile _ Ju mo @ #mobilecross
- 7. Mobile Developer #mobilecross
- 8. #mobilecross
- 10. Do’s and Dont’s of Cross-Platform Mobile Design #mobilecross
- 11. Popular Platforms #mobilecross
- 12. Popular Tools #mobilecross
- 13. Do’s and Dont’s #mobilecross
- 14. Popular Platforms #mobilecross
- 15. #mobilecross
- 16. #mobilecross
- 17. #mobilecross
- 18. #mobilecross
- 20. #mobilecross
- 21. #mobilecross
- 22. #mobilecross
- 24. #mobilecross
- 25. #mobilecross
- 26. #mobilecross
- 28. #mobilecross
- 29. Popular Tools #mobilecross
- 30. Titanium #mobilecross
- 31. Titanium Javascript #mobilecross
- 32. Titanium iOS + Android #mobilecross
- 33. Titanium Native UI #mobilecross
- 34. Titanium Modules #mobilecross
- 35. Mono #mobilecross
- 36. Mono C# .NET #mobilecross
- 37. Mono Android + iOS + WP #mobilecross
- 38. Xobot OS #mobilecross
- 39. Mono 100% Native #mobilecross
- 40. Phonegap #mobilecross
- 42. Phonegap Android + iOS + WP #mobilecross
- 43. Phonegap Efficient #mobilecross
- 44. #mobilecross
- 45. Do’s and Dont’s #mobilecross
- 46. Do Share #mobilecross
- 47. Share Code #mobilecross
- 48. Xamarin #mobilecross
- 49. Share Services #mobilecross
- 50. HELLO my n ame is J SON #mobilecross
- 51. Share Resources #mobilecross
- 52. #mobilecross
- 53. #mobilecross
- 54. #mobilecross
- 55. facebook #mobilecross
- 56. Don’t Share to Share #mobilecross
- 57. Share fever #mobilecross
- 58. Sharing is a tool #mobilecross
- 59. Do Stick to Branding #mobilecross
- 60. Using the Logo, Colors and Fonts #mobilecross
- 61. #mobilecross
- 63. #FFFFFF EFFRA BOLD #00000 #113E90 0 #F5361A
- 65. Branded Features #mobilecross
- 66. #mobilecross
- 67. Don’t Overdo Branding #mobilecross
- 68. Let the experience speak for the brand. #mobilecross
- 69. Do REST #mobilecross
- 70. API Design #mobilecross
- 71. #mobilecross
- 72. #mobilecross
- 73. foursquare #mobilecross
- 74. Don’t Neglect Presentation #mobilecross
- 75. UI/UX Design #mobilecross
- 76. Do Stay True #mobilecross
- 77. True to the Platform #mobilecross
- 78. #mobilecross
- 79. True to the Brand #mobilecross
- 80. #mobilecross
- 81. True to the User #mobilecross
- 82. #mobilecross
- 83. Don’t Back Down #mobilecross
- 84. Are You Right? Are You Sure? Don’t Back Down. Prove It. #mobilecross
- 85. #mobilecross
- 86. #mobilecross
- 87. ? @mobile _ justin #mobilecross
- 88. #mobilecross
Notas do Editor
- *\n
- Good afternoon!*\n
- I’d like to Thank everyone\n*\n
- Events like this are far from easy to organize, and our organizers deserve all of the credit we can give them *\n
- Events like this are also not cheap, which is where our wonderfully awesome sponsors come in *\n
- Kick things off, introduce myself. \nJustin Ferrell.\n*\n
- Mobile developer at...\n* \n
- A digital agency in Fayetteville, WV called Digital Relativity * \n
- The people that I work with at Relativity are among the coolest and most passionate I’ve ever met, and I count myself lucky to work with them.*\n
- Do’s and Don’ts of Cross-Platform Mobile Design *\n
- Popular Platforms on the market right now and how their experiences are driven by different factors*\n
- Popular tools available to devs and the differences between them not only technologically, but in terms of what users see*\n
- Do’s and Dont’s of cross-platform design. Examples from my own work and the work of larger brands. \n*\n
- Platforms\n*\n
- Big 3. WinPho, Droid, iOS. All different, but still solutions to the same problem. Still serve the same core purpose, helping real people accomplish real tasks while mobile *\n
- iOS\n*\n
- The iOS that we see today is a lot different from the iPhone OS that we saw Apple ship in 2008. Platform has matured, expanded in terms of hardware diversity, which has changed the way developers and designers approach the platform. * Less givens\n
- Experience-driver. App-Driven. inb4 all platforms have apps. Apps = center universe. Everything about iOS lives inside of some app. iOS, at its core, is a framework for navigation between apps * \n
- Boy Genius Report: 32%*\n
- Android\n*\n\n
- Because open-source, by nature more diverse. Vast galaxy of wildly different screen ratios, densities and resolutions. So interface design is approached with responsiveness and scalability in mind *\n
- Device-Driven. Because OEMs tweak os and play huge role in UX design. Devices are marketed first, with the OS as more of a feature. *\n
- 51%\n*\n
- Windows Phone\n*\n
- Cool thing about WinPho is that it provides a happy medium. Different manufacturers, different hardware styles, but very much adherent to the ecosystem. Controlled-freedom. *\n
- When you look at WinPho, it’s not hard to discern what the driver is when you think about usability. Lots of information up front, ability to easily share information. Very data-driven. Live Tile. OS sort of gets out of the way *\n
- 4%\n*\n
- Big 3. Different approaches, but with a shared context. Different solutions to the exact same problem*\n
- Popular tools. Not every tool, but IMO refined.\n*\n
- Titanium, Appcelerator\n*\n
- Primary language here is javascript. Appcelerator offers a full IDE and compiler, super easy for web devs to pick up and run with * \n
- iOS-Droid. Executed line-by-line on the device at runtime, which sounds really inefficient, until you look under the hood at the UI created * \n
- Titanium creates 100% native UI elements. No images, no skinned HTML. The UI’s created by titanium are fully functioning, fully native elements on every platform * \n
- Appcelerator offers a marketplace where developers can buy and sell this drag and drop functionality, so porting specific features from platform to platform isn’t difficult at all * \n
- Mono (Xamarin). Not Mono, actually M4A and MT. *\n
- C# .NET. Like Ti, Xamarin offers an IDE that has some really cool features like an Interface Designer for Android, which is insanely badass. Great for any .NET dev to pick. Existing libraries are fully supported. * \n
- Android, iOS and of course WP7 because it IS .NET. And because of the way that the Xamarin team as bound these SDK’s, you get 1:1 native mapping. There is NOTHING that can be in done that can’t be done in Mono. * \n
- To speak to the capabilities of Mono, they actually did an experiment in May, where they ported the ENTIRE functioning Android OS from Java to C#. And it was faster. A lot faster. * \n
- What you get is a 100% native executable. Support for native libraries even, able to bind Objective-C and Java libraries right in the framework. * \n
- Phonegap, Nitobi. Acquired by Adobe. \n*\n
- Uses web tech and web content. HTML, CSS, Javascript. Even easier than Titanium for web developers to pick up and use to crank out some solid work*\n
- Able to target Android, iOS, WP and many others. Uses a Javascript API to tap into native code using a sort of native frame around that web content * \n\n
- Coolest thing about Phonegap is how efficient it is. Because it supports so many platforms, and generally has 100% code share, the amount of time saved here is just phenomenal * \n
- Like OSes, these are the tools that I’ve found form the ‘big three’ as far as cross platform tools are concerned. Disagree? May have missed your favorite or you may think one of these is terrible. These are just tools. We’re all trying to do the same thing*\n
- Do’s and Dont’s. Based on my own experience. Big examples and examples taken from my own work.*\n
- Do: Share\n*\n
- Share code. Sounds obvious, but sometimes its necessary to be reminded why we pursue these things. Targeting multiple platforms at once is a great way to save time, money and resources, and it doesn’t always mean you have to make a terrible UX. *\n
- Another great example from Xamarin. MWC2012 app for iPhone, iPad and WinPho. 100% native on every platform, all in C#. Great UX, and the coolest part is that 65% of the code is line for line identical on all three. *\n
- Share services\n*\n
- We always like to think of cloud computing in terms of products and rarely as a means of UX design. But with sharing user data across platforms and doing server-side work, we provide consistency and platform agnostic experiences * \n
- Like code, cross-platform dev also helps us share other resources like iconography and colors. * \n
- Example: Facebook\n*\n
- Virtually everyone knows what Facebook is and what Facebook does. This is because that functionality is branded. The whole experience is. Doesn’t matter what platform it is. It will always look the same, and always have YOUR data * \n
- Virtually everyone knows what Facebook is and what Facebook does. This is because that functionality is branded. The whole experience is. Doesn’t matter what platform it is. It will always look the same, and always have YOUR data * \n
- Virtually everyone knows what Facebook is and what Facebook does. This is because that functionality is branded. The whole experience is. Doesn’t matter what platform it is. It will always look the same, and always have YOUR data * \n
- Virtually everyone knows what Facebook is and what Facebook does. This is because that functionality is branded. The whole experience is. Doesn’t matter what platform it is. It will always look the same, and always have YOUR data * \n
- Virtually everyone knows what Facebook is and what Facebook does. This is because that functionality is branded. The whole experience is. Doesn’t matter what platform it is. It will always look the same, and always have YOUR data * \n
- Virtually everyone knows what Facebook is and what Facebook does. This is because that functionality is branded. The whole experience is. Doesn’t matter what platform it is. It will always look the same, and always have YOUR data * \n
- Larger still is the overall brand. Colors, fonts, hierarchy of the layout. It all feels like facebook, and that’s what matters to the user * \n
- Don’t share just to share. *\n
- Share-fever. Ailment that will cause developers and designers to disregard things likes the user experience, application performance and even overall application quality in favor of sharing as much code and graphical elements as possible.*\n
- Sharing is a tool. Generally, sharing isn’t a goal. Goal is consistent, native, natural UX. It’s a path to a goal. *\n
- Do-StickToBranding.\n*\n
- Saw it with Facebook. Using platform-agnostic branding like the logo, fonts and colors are dead simple ways to produce a consistent design that doesn’t alienate users. * \n
- Using a sample of my own work, we recently wrapped a web and mobile project for an event back in WV called Bridge Day, where hundreds of base jumpers come for a massive festival on the largest arch bridge in the western hemisphere. \nColors. * \n
- We were not only able to take the logo, and translate it to web* But also to take the colors and fonts and * port them, the brand, to Android and iOS* \n
- We were not only able to take the logo, and translate it to web* But also to take the colors and fonts and * port them, the brand, to Android and iOS* \n
- We were not only able to take the logo, and translate it to web* But also to take the colors and fonts and * port them, the brand, to Android and iOS* \n
- We were not only able to take the logo, and translate it to web* But also to take the colors and fonts and * port them, the brand, to Android and iOS* \n
- Like colors, logos, fonts and anything else, features and functionality are also a huge part of a mobile brand * \n
- Building the Bridge Day app using Monotouch and Mono for Android, we were able to bring all of the functionality to either device, while remaining native and still being respectful of accepted platform design paradigms * \n
- Dont: Overdo Branding\n*\n
- Like sharing, branding has a dark side. It is very possible to neglect user experience in favor of misguided marketing. A good experience more important than branding. Ship a button doesn’t work or use the same font as the website and see which has a bigger effect*\n
- Do: REST. As in, REST API. \n
- I have long been a proponent of API design as the original cross-platform dev. It’s 100% platform-agnostic, reusable and on any platform that can send and receive an HTTP request * \n
- Foursquare\n*\n
- Like facebook, three clients. Branded, but respectful of their platforms. Feel like Foursquare. But these are really just presentations of the API. Website. Core purpose of these apps is to tap into geodata and leverage location and proximity. * \n
- And again, branding. Colors and fonts, general style. They all feel like Foursquare. * \n
- Because we just mentioned API presentation in Foursquare, it’s important to point out that we can’t neglect that * \n
- APIs are vastly IMPORTANT but no one SEES and API. Users don’t care about APIs. We need to be sure that we are presenting these things to users in a way that provides real utility * \n
- Do: Stay True. By that, I mean be cognizant of the things that will be demanding your apps respect. \n*\n
- True to platform. We saw earlier that every platform’s users have different expectations based on the ecosystem of their device. They expect things on their phone to function like other things on their phone * \n
- Every platform revolves around a different driver, and each driver alters the core usability of the OS. The way users approach these devices in every day use is different. * \n
- True to the brand. No substitute for user familiarity. Let users know that you are you. If your app is part of a larger brand, make that clear. They knew the brand first, not the app. \n*\n
- Bridge Day again. Colors, fonts, logo, functionality. It all meshes together to form that nebulous thing that people imagine when they think Bridge Day\n
- And of course, we have to stay true to the user. \n*\n
- It’s easy for us to forget that we’re making things for real people in the real world. People’s parents, children, grandparents. Everyone. Not every use case is on your desk Andrew: user’s don’t look down, they look up.*\n
- Don’t: Back Down\n*\n
- What I mean by that is if you have an idea of some kind that someone at your company, or some speaker at some conference, or some document tells you is wrong, and you feel very strongly that isn’t, don’t let them kill your idea. Prove them wrong. * \n
- Example: Instagram\n*\n
- When the Android version of the instagram app shipped, it broke existing UI conventions by placing the tabs on the bottom instead of the top. I immediately thought “WRONG WRONG WRONG” but that clearly wasn’t the case because it has been incredibly successful. *\n
- Questions\n*\n
- \n