Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von Jonathan Stark
Mehr von Jonathan Stark (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Principles of Mobile Interface Design
- 1. PRINCIPLES OF MOBILE INTERFACE DESIGN jonathanstark.com 1
- 2. FIRST THINGS FIRST prolly preaching to the choir, but here goes... 2
- 3. Mobile ≠ Desktop • Tiny screen • Expensive data • Battery powered • Limited storage • Spotty connection • Distracted user • Small pipe • Touch vs mouse 3
- 4. Mobile > Desktop • Personal • GPS • Always on • Accelerometer • Always with • Gyroscope • Usually connected • Magnometer • Directly • NFC? Addressable • Pico projector? 4
- 5. MOBILE MINDSET first, know thyself 5
- 6. BE FOCUSED edit features ruthlessly 6
- 7. BE UNIQUE play to your strengths 7
- 8. BE CHARMING develop your personality 8
- 9. BE CONSIDERATE it is not about you 9
- 10. MOBILE CONTEXTS bored, busy, and lost 10
- 14. GLOBAL GUIDELINES stuff that always matters 14
- 16. POLISH is extremely valuable 16
- 17. THUMBS are the default 17
- 18. TARGETS must be finger friendly 18
- 19. CONTENT is king, minimize chrome 19
- 20. CONTROLS should be beneath content 20
- 21. SCROLLING should be avoided when possible 21
- 22. NAVIGATION MODELS where the hell am i? 22
- 23. NONE single screen utility apps 23
- 24. TAB BAR three to six major categories 24
- 25. DRILL DOWN list + detail content hierarchy 25
- 26. USER INPUT damn you, autocorrect! 26
- 27. TYPING STINKS even on the best mobile devices 27
- 28. KEYBOARDS should be apropos for each field 28
- 29. AUTO-WHATEVER should be apropos for each field 29
- 30. SUPPORT LANDSCAPE if your app invites lots of typing 30
- 31. GESTURES it’s the thought that counts 31
- 32. INVISIBLE discovery is an issue 32
- 33. TWO HANDS are required for multitouch 33
- 34. NICE TO HAVE sorta like keyboard shortcuts 34
- 35. NO REPLACEMENT for visible controls and single-finger operation 35
- 36. ORIENTATION not just for freshman anymore 36
- 37. PORTRAIT RULES so optimize that first 37
- 38. LOT ‘O TYPING means you should support landscape 38
- 39. DISORIENTATION occurs when change is unexpected 39
- 40. COMMUNICATIONS being polite is a good thing 40
- 41. PROVIDE FEEDBACK for every user interaction 41
- 42. MODAL ALERTS are for total disasters 42
- 43. CONFIRMATIONS are for user actions 43
- 44. BADGES ARE GOOD except when they are aren’t 44
- 46. RESUME OPERATION right where your user left off 46
- 47. LAUNCH SCREEN should be “content-less” background 47
- 49. YOUR ICON is like a business card for your app 49
- 50. FIRST LAUNCH is a special situation 50
- 51. DESIGN PROCESS ready, fire, aim! 51
- 52. PERSONAS flesh out a few user archetypes 52
- 54. PROTOTYPE on device as soon as possible 54
- 55. USER FEEDBACK is enormously helpful 55
- 56. QUESTIONS? ping me on twitter @jonathanstark 56
Hinweis der Redaktion
- Hi all! My name is Jonathan Stark and I’m speaking to you today from my home office in Providence RI. \n\nI’m obsessed with wireless computing and its effects on society, and because of that I spend an inordinate time thinking about mobile app development, training, and strategy. \n\nIt’s worth mentioning that my clients are typically large organization who need to reach large groups of customers and employees with their mobile initiatives, so my strengths skew toward cross-platform apps and mobile web. \n\nToday we’re going to talk about principles of mobile interface design. I think most are pretty self-explanatory on their own, but it’s a long list and it can be a bit overwhelming when taken together. I’m going to start with some big picture perspective, then run through ten subject areas, and finish with some advice about design process and take questions from the group. \n
- \n
- As designers and developers, we have to concern ourselves with issues on mobile that don’t really exist on the desktop.\n
- I think because mobile devices are physically smaller than desktops and laptops, people tend to think of them as shrunken down “real” computers or somehow less powerful. But when you think about it, smartphones are actually more powerful than desktops in many ways. \n
- Because of the differences between mobile and desktop, it’s imperative to get yourself into a mobile mindset before getting started. \n
- You ARE going to have to leave stuff out. \n
- Know what makes your app different and amplify it. There are lots of fish in the sea of mobile apps. If there’s nothing special about your app, why would anyone pick it? \n
- Mobile devices are intensely personal. They are our constant companions. Apps that are friendly, reliable, and fun are a delight to use and people will become quite attached to the experience. \n
- App developers too often focus on\n\n* what they want\n* what would be fun to develop\n* personal business goals\n\nThese are all good places to start, but you have to put yourself in your users shoes if you ever hope to create an engaging experience. \n
- The image of the busy professional racing through the airport with a bag in one hand and smartphone in the other is what lots of people picture when they think about mobile computing context. But it would be a mistake to think that it’s the only one. \n\nTo begin to put ourselves in the shoes of our users, we need to consider three major mobile contexts, which I refer to as:\n* Bored\n* Busy\n* Lost\n\n
- Immersive and delightful experience that picks up where user left off is important. \n\n* ebay sells multiple ferraris per MONTH on mobile. \n* personally, smartphones and tablets have completely replaced traditional television.\n* still, interruptions are highly likely so be sure to pick up where user left off.\n
- Ability to accomplish micro-tasks incredibly quickly and reliably in a hectic environment is important.\n\n* Tunnel vision\n* Huge targets\n* Bold design\n
- In transit, in unfamiliar surroundings, or in familiar surroundings but interested in something unknown. \nConnectivity and battery life are big concerns. \n
- \n
- I can’t stress this enough. \n
- Because of the “constant companion” nature of our relationship to smartphones, paying a lot of attention to getting the little details perfect will be noticed and appreciated. I think of this like the “fit and finish” of a car. The engine might be powerful and the body style gorgeous, but if there’s a lot of road noise or rattling on the highway, the experience will begin to degrade for the commuter. \n
- With the advent of touchscreen interfaces, everyone is always talking about “finger this” and “finger that”. In reality, the thumb is what we need to design for. Unless the user has her smartphone is using two hands, it’s almost impossible to get a finger on the screen. And even in a two handed grip, she’s likely to type with two thumbs. \n
- 44px is the magic number\nDon’t put the Send button adjacent to the Backspace button\n
- Let your content shine by minimizing chrome wherever possible. \n(Aside about fixed position headers and footers in web dev)\n\n
- Think of an adding machine, a bathroom scale, or even a computer - the controls are beneath the display. And for good reason - if they weren’t, we wouldn’t be able to see what was going on with the content! \n\nContrast this real-world design consideration with traditional web or desktop software, where navigation and menu bars are virtually always at the top. This made sense because the mouse pointer is nearly invisible. Not so with the meat pointer.\n
- I assure that that “below the fold” exists for mobile. Also, having a non-scrolling screen has a more solid and dependable “feel” than a scrolling view because it’s more predictable. Of course, certain screens have to scroll, but it’s good to avoid it where you can. Also nice to give visual clues that scrolling is possible by reverse animating into view. \n
- If you are going to use one of the common nav models, be sure to pick the one that is makes the most sense for your app. \n
- Weather app on iPhone\n
- Music app on iPhone\n
- Settings app on iPhone\n
- \n
- Minimize keyboard interaction where you can\n
- There are a wide variety of keyboards and variations(ascii, numbers, keypad, email, url, etc..). Be sure to pull up the one that is best for each field. \n\n(Aside that Android Market allows people to install custom keyboards, so you can’t be 100% sure how much screen real-estate is being taken up)\n
- Auto-correct, auto-capitalize, auto-complete. Consider each in the context of every input field in your app. \n\nSo annoying to have auto-correct or auto-caps on an email field. \n\n\n
- Some people (cough-me-cough) have fat fingers and sometimes need the roomier key layout available in landscape mode. \n
- \n
- \n
- \n
- \n
- A common vocabulary for gestures doesn’t exist yet so it’s too soon for most apps to skip visible controls that can be used with a single-finger. \n
- \n
- \n
- \n
- Consider adding an orientation lock for apps that invite long sessions\n
- \n
- * Provide instant visible feedback for every interaction\n* Except when you shouldn’t (tap highlights when scrolling)\n* Use spinners or progress bars to let users know that your app is working on it\n\n
- * Only use alerts when something it truly borked\n* Keep language reassuring and friendly\n* Don't use modal alerts for "FYI" type information\n\n
- * Confirmation dialogs should only be in response to user actions\n* "Safest" choice should be the default button in the confirmation \n\n
- \n
- \n
- Gives the illusion of speed\n
- If possible, launch screen should be a "content-less" image of your app \nAnything that looks interactive (buttons, links, icons, content) will create frustration\nBranded launch screens make user feel like they're sitting through an ad\n\n\n
- \n
- A polished icon suggests a polished app\nIcons live shoulder to shoulder with other icons\nTherefor, an icon is an ad (not an art piece)\nBe literal - show what your app does\nUse a strong silhouette\nDon't go overboard with text\nIt's usually not attractive to scale down large icon for smaller sizes\n\n
- Simple apps should be self-explanatory\nComplex apps might require a "tips & tricks" overlay\nUI might need work if you are considering lots of help text\nAugment empty lists with helpful instructions\n
- It can be tempting to jump right into code... DON’T! \n\nAs the saying goes: “Weeks of coding can save you hours of planning”\n
- \n
- \n
- Simulators are not very useful because you can’t “feel” the app, it’s not the right size, and there might be bugs.\n
- I am routinely shocked at people’s mental model of an app on first launch. Just the other day, a developer a work with built a screen that made perfect sense to her, but left me utterly confused. \n\nEven if you are the customer, get a second opinion. \n
- \n