|
Size: 18180
Comment:
|
Size: 2764
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| {{{#!wiki yellow/solid This is brand, spankin' new. There are some bugs or incomplete elements here and there. Add all you want to the Wiki pages, but if you think something really broken, feel free to contact a site admin. |
[[Designing Mobile Interfaces|{{attachment:book.png|Designing Mobile Interfaces, by Steven Hoober & Eric Berkman.|align="left"}}]]~+[[Designing Mobile Interfaces|Patterns book]]+~ |
| Line 4: | Line 3: |
| The Components section is where we're working now. Everything else is just there to fill in the outline. Scroll down a bit to see a "final" pattern. | Buy the O'Reilly book Designing Mobile Interfaces, or read it all right here for free. {{{ #!Frame align=clear |
| Line 7: | Line 9: |
| == Introduction == Design seems like something that should be ridiculously easy. And for some things, it can be. When you organize your workspace -- move the desks around, get a different keyboard -- you are designing that experience for yourself. And generally you can do a pretty good job. |
[[http://4ourth.com/Touch|{{attachment:touch.png|The only touchscreen guidelines you need.|align="top"}}]] ~+[[http://4ourth.com/Touch|Touch guidelines]]+~ Articles, slides and videos on the definitive, up-to-date, reseach-based guidelines on designing for fingers, touch and people. |
| Line 10: | Line 12: |
| Now that your office is arranged the way you want it, you get down to developing a mobile application. Design there must be just as easy. You arrange the data, and the structure of the site, in a way that makes sense to you. You make a presentation layer that reflects that perfectly sensible data arrangement. And when you launch it, everyone complains. Why can't they see the brilliance of your ideas? | [[http://4ourth.com/TouchTemplate|{{attachment:touchtemplate.png|Buy a 4ourth Mobile Touch Template.|align="top"}}]] ~+[[http://4ourth.com/TouchTemplate|Touch Template]]+~ A cheap, simple, plastic guide to help you keep the touch guidelines in mind during design and test. |
| Line 12: | Line 15: |
| Because they are yours. And a key to design is that it is a selfless practice. You cannot think of how design will work for you, or even your friends, but for your users, and probably all your users. The language can rapidly sound like a revolutionary; you have to consider your users as a collective. | * [[http://4ourth.com/TouchTemplate|Touch Overlays]]: Free stencils for use in your favorite wireframe or mockup tool, as long as it's INDD, AI, PSD, Graffle, VSD, or PPT. |
| Line 14: | Line 17: |
| * [[What is a Pattern?]] * [[What Do You Mean by "Mobile"?]] * [[Where Did These Come From?]] * [[Common Practice vs. Best Practice]] * [[Disagree? Change it.]] * [[Reading the Patterns]] * [[Definitions & Styles of the Patterns]] * [[Componentized Design]] * [[Principles of Mobile Design]] * [[Acknowledgements]] |
* [[http://shoobe01.wufoo.com/forms/contact-4ourth-mobile/|Contact]]: With any comments, questions, corrections or to hire us for consulting or speaking. * [[Not Desktop, But Not Quite Mobile|Other devices]]: The patterns in Designing Mobile Interfaces are really best applied to small, portable devices. Here's some info and leads on other devices you may need to work on. |
| Line 25: | Line 20: |
| ----- == The Patterns == |
* [[Mentions, Reviews & Other Writing|Writing]]: A list of all the articles I have written, as well as other books and research reports I have contributed to. * [[Speaking]]: Ask me to speak at your event, or see slides and videos of my previous talks. |
| Line 28: | Line 23: |
| === Page === Wrapper as a concept, is key to the intro for this section. There's a template that exists, with menu indicators, annunciator rows, titles, etc. They all have their place, and you should only eliminate them under certain conditions. Generally, I think you at least allow access to, say, the annunciator row (or equivalent) so you can always find out alerts, status, battery, signal, etc. if you need. Why be surprised when in camera mode, for example? |
[[http://www.slideshare.net/shoobe01|Slideshare]] | [[https://www.youtube.com/user/shoobe01|YouTube]] | [[https://www.flickr.com/search/?w=10316450@N03&q=designing%20mobile%20interfaces|Flickr]] | [[https://www.linkedin.com/in/shoobe01|LinkedIn]] | [[https://www.flickr.com/search/?w=10316450@N03&q=designing%20mobile%20interfaces|Google+]] | [[https://twitter.com/shoobe01/|Twitter]] | [[https://www.facebook.com/shoobe01|Facebook]] | [[https://www.behance.net/shoobe01|Behance]] |
| Line 31: | Line 25: |
| * [[Vertical Scroll]] Usually page, but also chunks of the page... Same element for whole device. All the stuff we talk about, like size, bezel obscuring, indicator or interactive, relative size (suggested!) and so on. Space saving techniques like letting it overlay content, vs being a strip, and letting it disappear being not suggested (how to tell where you are without scroll, when eyes are somewhere else often). * [[Horizontal Scroll]] Or sideways indicator... see Seesmic details for an interesting version of "more over here" * [[Annunciator Row]] Cover what should be in it, how it's always there. Even if you have full screen items. And don't change the layout much. * [[Notification Area]] Strips are becoming a best practice. But also talk about icons as widgets, etc. Non-interrupting, but visible. Refer to copia stuff a lot on this. It's pretty solid, really. * [[Titles]] Guidelines around naming. Say most pages should be labeled, including sub-tabs, sections, states. Also, pop-ups and other elements get titles, even sub-page elements, so mention that. Label everything similarly. Suggested is a straight up title bar, hence you see that in the diagrams here. * [[Revealable Menu]] Android has this. Action opens it. - SKs and things like Bada (visible item, with label maybe, but NOT the menu itself) are variants of this. Also think about weird pullout strips like Pre has. * [[Fixed Menu]] iPhone has a visible menu. * [[Home & Idle Screens]] Basic deck, and the multiple-home-screen mentality Apple esp brought us. Side or other scrolling, pros and cons, indicators of position... Mentioned because it's a totally different layout (very often) than apps and other things on the device. Go deep enough to cover e.g. S60 folders, etc. * [[Advertising]] Consider Weather Channel, size and placement as best practice - Do not let ads get perceived as part of the page; so alignment, size, backgrounds, etc. - HERE because it should not be addressed as a random widget, but always appear the same place, and often has to be on pretty much every page anyway. * [[Widgets]] As a principle. A widget is something that changes. Show eric my Hero200 control icons. Widgets. An icon that pulls up a control panel is an icon, not a widget. Etc. |
[[http://medium.com/@shoobe01|A few Medium articles]] | [[http://shoobe01.blogspot.com/|An old Blog]] |
| Line 42: | Line 27: |
| === Components === Introduction to the [[Components]] section. ==== Display of Information ==== Introduction to the [[Display of Information]] chapter. * [[Vertical List]] * [[Infinite List]] * [[Thumbnail List]] * [[Fisheye List]] * [[Carousel]] * [[Grid]] * [[Film Strip]] * [[Slideshow]] * [[Infinite Area]] * [[Select List]] ==== Control & Confirmation ==== Introduction to the [[Control & Confirmation]] chapter. * [[Confirmation]] * [[Sign On]] * [[Exit Guard]] * [[Cancel Protection]] * [[Timeout]] ==== Revealing More Information ==== Introduction to the [[Revealing More Information]] chapter. * [[Windowshade]] * [[Pop-Up]] * [[Hierarchical List]] * [[Returned Results]] === Widget === Scrollbars, buttons, etc.- Smaller than a Component. Highly reusable items, used many times, over and over, in other places. Some similar sized items are not widgets, because they are custom implemented items. ==== Lateral Access ==== * [[Tabs]] All these not so much sideways and "at the same level" and view switching - solutions to tabs not fitting, like USAT scrolling the tab bar. Note that tabs are terrible because text is horizontally inefficient * [[Peel away]] The google maps on iPhone (I think) thing where you get to see other layers by peeling back to a layer behind * [[Flip over]] Suggest device flipping also, but mostly rotating the virtual space to see the other side of an object * [[Other 3D Effects]] Like cube displays, etc. Find mobile equivalent of Fast User Switching on mac * [[Pagination]] Conventional "page of page" (7 of 23), range of total. This one is the interactive version. You can click prev/next, to a range, etc. All options covered... * [[Location Within]] Indicates location, without a jump to feature, or a pagination control per se. Dot indicators are this, for example. ==== Drilldown ==== * [[Stack of Items]] Tap to expand stack, etc. See all ways of doing it on Surface ... Many other drilldown methods' Antipatterns: do not use a generic icon/graphic to describe the stack, i,e. iphone grouping * [[Links]] Suggest underlines for web. Indicators for off-site? * [[Buttons]] size, indicator of priority. Still like BOA old ones with color/shape icons alongside. Apple arrowed button bars are good examples of this. * [[Bookmarks]] adding notes and nodes along a line graph like google analytics, adding pins to map locations, establishing a reference point with additional information ==== Labels & Indicators ==== * [[Typography]] Like, pick good readable stuff, try to pick fonts where bold face is not roomier than roman. Even mention square serifs for readability. Guidelines for sizes, suggestions to use physical units of measure,... http://4ourth.com/wiki/Introduction%20to%20Mobile%20Typography * [[Truncation]] ellipsis are three dots, or the glyph, and nothing else. Highly suggest those to make it clear (else make sure characters can be chopped at ends of viewport). Character truncation, word truncation and when to use each. Mention marquee, but an old technique so not expected, not favored now except on very small screens. * [[Direction]] Compass direction, or just axis of a chart. * [[Icons]] Some notes about good practice, Consistency, modifiers to icons (+ next to one means, new message, but it better be big enough to see... multiple encoding) * [[Avatar]] Image of a person, or the stand in, and how it's used various places * [[Meters and levels]] Generalized version of what I think of battery meters. For all those things, signal strength, and anything else; ratings is a good one. How to show that your rating is different from baseline. Perhaps systematically similar to the charging state of the battery * [[Wait indicators]] http://patterns.design4mobile.com/index.php/Wait_Indicator this is terrible. See various styles in Sprint guide. Yes, overlaps widget and component. Make it work, as ONE item. Talk through it as wait indicator is the widget, suggestd /implementation/ for some states is as a modal dialogue. * [[Lazy loading]] Different from infinite area, or infinite list. More a widget thing, like if you have an infinite list, the images might lazy load to get the basic list in place. Animation, low-res, etc. * [[Reload/Refresh/Stop]] As one thing, since sometimes you use a single location. Must offer refresh for more than web browser URLs, so a single idea... I think. ==== Controls ==== * [[Zoom, scale]] Methods to zoom in and out, especially suggested icons, ways of indicating zoom level (national to house) and literal scale bars. * [[Location jump]] Thinking of the rolodex slider motif of some address books, but ALSO the widget to type a name in an address book, and it doesn't jump but goes to the first location. See search-within for a contrasting widget * [[Search within]] Simple. Search box, whether website or address book, when typed it either jumps to or filters results. NOT the same as location jump. I think. Unless we think that the jump behavior makes them overlap... * [[Sort and Filter Controls]] Some overlap with location jump and search-within... Work on this. === Input & Output === Keyboard, Keypad and Other input features. Gestures here or somewhere else? Sensors? - Sizes of touch targets, etc. Include diagrams from Mobile Design Elements. Also see this W3C stuff, or at least refer to the group: http://www.w3.org/2010/webevents/ ==== Keyboards & Keypads ==== * [[Soft keyboards ]] Probably. Unless it should be under Key below. Use my gripes about non-standard Galaxy Epic as a baseline. * [[Dialer]] Not always done well, so lets do it well - hard and soft pause for example, and how dialer is different from entering numbers into address book. Things like keep mute/spkr buttons when num pad is visible (soft keypads only... but concept is sold. All those actions on a call are immediate. Allow access to 3-way, etc. but mute better be 1 button) - MAYBE lives in KEY section as a special type of keyboard. * [[Keypad layout]] * [[Keyboard Layout]] Galaxy epic issues, for example. Use localized standards, do not make up own. FN only when needed, and backlight as well as reflective indicators... * [[Press-and-Hold]] Can it be generalized? * [[Spacing]] Worth repeating basic ergonomics? Or are we getting into hardware design too much * [[Autocomplete]] All the bad things about predictive text input. I guess. Complex issue. * [[Accesskeys]] Includes screen listing of them. Contrast with numbered lists... ==== Finger Gestures ==== swipe, pinch and zoom, tapping - Relatively FEW are included, as they are patterns. Need to be identifiable best cases. Weird gestures, or those with too much variability for user type, region, etc. are not included as they are not patterns in the sense we mean. * [[Tap]] Perform action. Go somewhere, select something, etc. People screw this up. See lowish item in this RISKS https://mail.google.com/mail/?shva=1#inbox/12bf56f02bca29b5 pressing selects item, then item on the next screen! * [[Tap & Hold]] Alternative interaction - Light "right click" - should provide option, not just DO other action * [[Drag]] Moves something. Maybe the whole screen. In the direction (or axis) selected. When not free movement, try to have arrows to indicate axis-of-movement - Cover inertia also * [[Pinch Zoom]] Two finger apple-like pinch to unzoom, etc. * [[Axis Rotate]] Two finger rotate. One is axis, one is rotation. ==== Kinesthetic gestures ==== Whole body motions, whole-device motions (e.g. face down=sleep), and even sensing such as speed, gait... - NOT TOO FUTURISTIC! Roll handset: , Raising to face, Lowering from face, Tapping two devices together, Motioning handset towards RFID, Whipping: A quick down-up motion * [[Shake]] shaking handset rapidly on multiple axis. Used to refresh and reload displayed information or to scatter data. * [[Roll]] Rolling device onto it's opposite side will change it's current state. i,e. face down=sleep. * [[Tapping]] Tapping two handsets together can be used for file and information sharing * [[Whipping]] Rapid back and forth action used to throw or cast information i,e. fishing reels used in games * [[Raising ]] consider more...antipattern? * [[Lowering]] consider more...antipattern? * [[Proximity to Signals]] like audio detection on car radios? RFID, card readers....FUTURE, orientation of detectors on handset? Cultures? * [[Rotation]] rotating device on axis or planes to change the orientation of the information displayed. ==== On-Screen Inputs ==== Button behaviors (look clicked, press-and hold), also select-lists, etc. - Consider them systematically to be an input selection method. So they go here! * [[Input Areas]] Form, or sms input area, or... anything you put text... http://patterns.design4mobile.com/index.php/Text_Entr * [[Input Method Indicator]] Hanging off the side of a field. Talk (maybe) about how input method for the whole screen is an anti-pattern? Indicates the current and/or the available methods... Need to work on the best practice here! * [[Select lists]] Cover all - pulldowns, radios, checks, because differences can be fuzzy, and some are bad implementation, e.g. J2ME/S60 default full-page input; (NOT on-page lists or simple nav: refer to Information Display chapter above) Anti: Select lists should not look like anything else, and buttons (etc.) should not look like select lists. E.g. Seesmic. * [[Spinners]] Or, more likely, their alternatives. The Galaxy has some nice ones. The gist is that we think that obscuring the number is dumb, and you need alternative methods (up/down arrows, direct entry... click and get numpad even if softkb only) and scrolling as machine-era interface should be left as secondary; also, if you must scroll, click detents; ALSO: here or other entry methods, pick good numbers. Scroller for minutes on a calendar should be at 15 min intervals, and direct entry required for any odd numbers. Acceleration (especially scroll and select) should snap to even numbers; see Sony alarm clock behavior in this regard. * [[Attach & Reference]] Maybe... Push button to go somewhere and get a file to attach, as with MMS. Or reference a person, as with address to send to. Still a field, usually, and you activate differently to cross-link, etc. * [[Text Insertion Point]] Text insertion points, the mag insertion for iPhone edit for example. * [[Clear fields]] Need an easy way to do this, as typical desktop methods are hard to do, BUT, abide by principles of mobile design and let it be undoable also. (suggest how, if not OS level, like press and hold clear after this returns it, or robust autocomplete saving) ==== Audio & Vibration ==== Beeps and why they are bad. Tone types. Audio readback best practices. Look at med reminder for some of these. Voice input. Vibrate is just crappy haptics. Include it. * [[Tones]] See Ecosystem of Beeps, and riff off that. Beeps should imply things. Like crosswalk tones aren't just beeps! * [[Voice Input]] look it up. I know little. * [[Voice Readback]] Have some of this in specs we can look up. * [[Voice Reminders]] Voice reads out without warning. "Time to go to the dentist." Privacy concerns, and "uh" acclimation issues. Needs to probably be after you ack that a message has arrived, so are paying attention, but a valid method for low-vision, or otherwise cog disabled folks. * [[Haptic Output]] Vibration responses and reminders. Two different things. ==== Screens & Lights ==== * [[LED]] Blink, colors, etc. - Again, got some of these in the blog post on battery indicators * [[Display Brightness Controls]] * [[Screen cleverness]] Like the N8s nice sleep state clock. Something along the lines of avoiding common practice, and using best practice (OLED power per lit pixel) * [[Distance from users]] Guidelines, mostly, on how people hold phones closer than tabs, or laptops, or desktops or TVs (like my photo). Guideline or anti: don't change based on distance from user, as they are already adjusting... ==== Augmented Reality ==== covered in many other patterns. is instead a category of product. Should probably be removed from here. |
|
| Line 168: | Line 31: |
| == Design Tools == Things other than the patterns themselves you can use to help design. Templates (including those used to draw the diagrams here), stencils, simulators, emulators, etc. * [[Script Events]] - How different mobile browsers handle, or don't handle, DOM events for Javascript/ECMAscript * [[Emulators]] - Emulators, prototyping tools, design aids, etc. * [[Color Deficit Design Tools]] - And other tools to help understand colorblindness and related conditions. * [[Drawing Tools & Templates]] - Graphic design tools, UI guidelines, tips for various tools. * [[Documentation Templates]] - Designing documents can be as important to successful implementation as the actual design. * [[Introduction to Mobile Typography]] - Overview of basic type terms and some things to watch out for in small screens. * [[Introduction to Location Technologies]] - Location is not just GPS. If you think it is, and are designing applications and services that use it, read this. * [[http://www.smashingmagazine.com/2009/10/12/setting-up-photoshop-for-web-app-and-iphone-development/|Set up Photoshop and Illustrator color controls]] - Okay, not really mobile, but a constant source of frustration. Valid for anyone who works in interactive pretty much all the time. |
|
| Line 179: | Line 32: |
----- == References == * [[List of References]] |
== Fingers, Touch & People == If there's anything I'm the expert on now, it's how people hold and touch their mobile phones and tablets. I'm trending towards fully writing a smallish book on it. I am working on it [[Fingers, Touch & People|over hereabouts]], but since it'll be a mess for a long while, just check out the [[http://www.4ourth.com/Touch|Touch]] overview page for the most current complete articles, presentations, videos, guidelines and references. |
Buy the O'Reilly book Designing Mobile Interfaces, or read it all right here for free.
Touch guidelines Articles, slides and videos on the definitive, up-to-date, reseach-based guidelines on designing for fingers, touch and people.
Touch Template A cheap, simple, plastic guide to help you keep the touch guidelines in mind during design and test.
Touch Overlays: Free stencils for use in your favorite wireframe or mockup tool, as long as it's INDD, AI, PSD, Graffle, VSD, or PPT.
Contact: With any comments, questions, corrections or to hire us for consulting or speaking.
Other devices: The patterns in Designing Mobile Interfaces are really best applied to small, portable devices. Here's some info and leads on other devices you may need to work on.
Writing: A list of all the articles I have written, as well as other books and research reports I have contributed to.
Speaking: Ask me to speak at your event, or see slides and videos of my previous talks.
Slideshare | YouTube | Flickr | LinkedIn | Google+ | Twitter | Facebook | Behance
A few Medium articles | An old Blog
Fingers, Touch & People
If there's anything I'm the expert on now, it's how people hold and touch their mobile phones and tablets. I'm trending towards fully writing a smallish book on it. I am working on it over hereabouts, but since it'll be a mess for a long while, just check out the Touch overview page for the most current complete articles, presentations, videos, guidelines and references.