Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Principles of Mobile Interface Design

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Próximo SlideShare
Rp Daniel Gonzalez
Rp Daniel Gonzalez
Cargando en…3
×

Eche un vistazo a continuación

1 de 56 Anuncio

Más Contenido Relacionado

Más de Jonathan Stark (20)

Más reciente (20)

Anuncio

Principles of Mobile Interface Design

  1. 1. PRINCIPLES OF MOBILE INTERFACE DESIGN jonathanstark.com 1
  2. 2. FIRST THINGS FIRST prolly preaching to the choir, but here goes... 2
  3. 3. Mobile ≠ Desktop • Tiny screen • Expensive data • Battery powered • Limited storage • Spotty connection • Distracted user • Small pipe • Touch vs mouse 3
  4. 4. Mobile > Desktop • Personal • GPS • Always on • Accelerometer • Always with • Gyroscope • Usually connected • Magnometer • Directly • NFC? Addressable • Pico projector? 4
  5. 5. MOBILE MINDSET first, know thyself 5
  6. 6. BE FOCUSED edit features ruthlessly 6
  7. 7. BE UNIQUE play to your strengths 7
  8. 8. BE CHARMING develop your personality 8
  9. 9. BE CONSIDERATE it is not about you 9
  10. 10. MOBILE CONTEXTS bored, busy, and lost 10
  11. 11. BORED social, news, entertainment 11
  12. 12. BUSY email, calendar, banking 12
  13. 13. LOST attractions, directions, recommendations 13
  14. 14. GLOBAL GUIDELINES stuff that always matters 14
  15. 15. RESPONSIVENESS is absolutely critical 15
  16. 16. POLISH is extremely valuable 16
  17. 17. THUMBS are the default 17
  18. 18. TARGETS must be finger friendly 18
  19. 19. CONTENT is king, minimize chrome 19
  20. 20. CONTROLS should be beneath content 20
  21. 21. SCROLLING should be avoided when possible 21
  22. 22. NAVIGATION MODELS where the hell am i? 22
  23. 23. NONE single screen utility apps 23
  24. 24. TAB BAR three to six major categories 24
  25. 25. DRILL DOWN list + detail content hierarchy 25
  26. 26. USER INPUT damn you, autocorrect! 26
  27. 27. TYPING STINKS even on the best mobile devices 27
  28. 28. KEYBOARDS should be apropos for each field 28
  29. 29. AUTO-WHATEVER should be apropos for each field 29
  30. 30. SUPPORT LANDSCAPE if your app invites lots of typing 30
  31. 31. GESTURES it’s the thought that counts 31
  32. 32. INVISIBLE discovery is an issue 32
  33. 33. TWO HANDS are required for multitouch 33
  34. 34. NICE TO HAVE sorta like keyboard shortcuts 34
  35. 35. NO REPLACEMENT for visible controls and single-finger operation 35
  36. 36. ORIENTATION not just for freshman anymore 36
  37. 37. PORTRAIT RULES so optimize that first 37
  38. 38. LOT ‘O TYPING means you should support landscape 38
  39. 39. DISORIENTATION occurs when change is unexpected 39
  40. 40. COMMUNICATIONS being polite is a good thing 40
  41. 41. PROVIDE FEEDBACK for every user interaction 41
  42. 42. MODAL ALERTS are for total disasters 42
  43. 43. CONFIRMATIONS are for user actions 43
  44. 44. BADGES ARE GOOD except when they are aren’t 44
  45. 45. LAUNCHING suspended animation 45
  46. 46. RESUME OPERATION right where your user left off 46
  47. 47. LAUNCH SCREEN should be “content-less” background 47
  48. 48. FIRST IMPRESSIONS getting acquainted 48
  49. 49. YOUR ICON is like a business card for your app 49
  50. 50. FIRST LAUNCH is a special situation 50
  51. 51. DESIGN PROCESS ready, fire, aim! 51
  52. 52. PERSONAS flesh out a few user archetypes 52
  53. 53. STORYBOARD endlessly on paper 53
  54. 54. PROTOTYPE on device as soon as possible 54
  55. 55. USER FEEDBACK is enormously helpful 55
  56. 56. QUESTIONS? ping me on twitter @jonathanstark 56

Notas del editor

  • 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

×