Differences between revisions 14 and 278 (spanning 264 versions)
Revision 14 as of 2010-10-14 05:28:33
Size: 10885
Editor: shoobe01
Comment:
Revision 278 as of 2011-07-05 23:47:46
Size: 12455
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Mobile Design Patterns Library =
{{attachment:pattern-wiki.png}}
{{attachment:Book-Cover.png|A black and white (the real one will be color) mockup of the cover of our forthcoming O'Reilly book, Designing Mobile Interfaces, by Steven Hoober & Eric Berkman. I thought it would be alphabetical, but now we know who's more important :) |align="right"}}
Line 5: Line 4:
An intro needs to go here...

{{{#!wiki red/solid
'''Please Add Your Thoughts'''

This is a wiki on purpose. We want the entire mobile design community to help with this effort. Even if you disagree, add your thoughts. For very significant changes, please add comments, instead of just over-writing what others have done without discussion.
If you are picking up this book, you don't need to be told how ubiquitous mobile is, how quickly it is growing and changing, and how much it is supplanting desktop computing, and even more traditional media such as film, television, radio, papers and books.

Mobile is so huge and growing so fast, that astonishing numbers from just a few years ago pale in comparison. So much so, that we won't even bother quoting any figures, as they will be quaint far before the rest of the content looses its relevance.

One thing that has not yet happened is true standards of design. There are just now movements to design the mobile experience first. A good reason is that in many markets, many of your customers look at your website on mobiles more than desktops.

Yet, too much design is based on older paradigms for desktop, or even for TV or print. Within mobile, too many design discussions are very narrowly focused. They pay special attention to applications on a single platform, or only to the mobile web. And almost always at the specific expense of every other platform. Certainly, almost no one discusses anything but smartphones, despite huge marketshare and vast use rates of featurephones.

Fragmentation is discussed as a bad thing for marketing, and sometimes for design, but designers themselves contribute too often by focusing on pixel-based layouts, and the specifics of their favorite OS. This does no one any good, and is especially pointless when you consider the user. Devices generally have many more features and methods of interaction in common than their differences might imply.

Serious mobile design now, and especially in the future, will require building for every user, and providing some solution on every platform.


This book offers a set of common patterns for interaction design on all types of mobile devices. A few patterns require specific hardware or form factors, but most are absolutely universal.

Most do not concern themselves at the top level with implementation details. The correct solution is correct whether at the OS level, as an application or as a website.

Of course, there are notes to discuss alternatives, methods and limitations to assist with decision making. And, many of the specific patterns are coupled with alternatives or variations that allow similarly-useful solutions to be achieved on any type of device.

 * [[Who would read this book?]] √
 * [[What Do You Mean by "Mobile"?]] √
 * [[What is a Pattern?]] √
 * [[Where Did These Come From?]] √
 * [[Common Practice vs. Best Practice]] √
 * ''[[Disagree? Change it.]] wiki only''
 * [[Reading the Patterns]]
 * [[Successfully Designing With Patterns & Heuristics]] √
 * [[Principles of Mobile Design]] √
 * [[Acknowledgements]]


{{{#!wiki yellow/solid
It's a wiki, but also a book (to be released in October). We need to keep things in synch, so please see the help tab for formatting information, be respectful of content on the site, and add your notes and comments to the appropriate section at the bottom of each page.

Contact @shoobe01 or @ericberkman if you don't see us responding to your change fast enough.
Line 13: Line 41:
== Patterns ==

=== Components ===
A section or subsection of a design - This carousel is one of those. Components are made of widgets, and maybe other, custom stuff.

==== Display of Information ====

* [[Vertical List]]
* [[Infinite List]]
* [[Thumbnail List]]
* [[Fisheye List]]
* [[Carousel]]
* [[Grid]]
* [[Film Strip]]
* [[Slideshow]]
* [[Infinite Area]]
* [[Select List]]

==== Control & Confirmation ====
  Confirmation Maybe Principles ... but the thing where you don't label buttons yes or no. Mostly modal dialogues.
  ExitGuard
  CancelGuard
 4 Revealing More Information / Drilldown -
  Windowshade individual and list - explicit opening. When used as a list item, doesn't make it a new list type. Just the select action is in place, vs. a new screen or a popup.
  Pop-ups Various sorts. Should we steal from Sprint and use their several types, or just call them all variations on a theme. OR? Is this the sort of thing that goes in pages? Behavior as a modal popup is a page behavior thing... ????
  Heirarchical lists Open up little arrows or +s to see the next level down. Like file system explorers...
 4 BELOW HERE UNASSIGNED
  Returned results http://patterns.design4mobile.com/index.php/Returned_Results Could be a LIST, could be just a widget at top of screen... could be something else. Like uses LIST display modes, but it's a result section.
  Revealable Menus From softkeys to android to that weird thing on the Pre you pull up (or the bar on some FF mobile things)
  Fixed menus Same as revealable, but Apple style of it living there all the time.
  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.
W - 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.
 1 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
  Prev/next Not just pagination... or is it? Could be that this is where that goes...
 2 Drilldown -
  Stack of photos Tap to expand stack, etc. See all ways of doing it on Surface ... Many other drilldown methods'
 4 BELOW HERE UNASSIGNED -
  Vertical Scroll
  Horizontal Scroll Or sideways indicator... see Seesmic details for an interesting version of "more over here"
  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.
  Pointers Including text insertion points, the mag insertion for iPhone edit? Pre "splash" thing
  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
  Text entry http://patterns.design4mobile.com/index.php/Text_Entry --- Probably several of these, so we cover all the usual form elements, and which work better and worse, and notes about pop-up selection or entry on default J2ME, S60... (and not to do it!)
  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.
  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)
  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.
  Pagination Convention page of page, range of total, but also dot indicators of position in a list (as for multiple home pages), etc.
  Location Within Indicates location, without a jump to feature, or a pagination control per se. Dot indicators may be THIS instead
  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.
  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.
  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.
  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.
  Type principles? Like, pick good readable stuff, try to pick fonts where bold face is not roomier than roman. Even mention square serifs for readability. Or... too much and not really a pattern???? - GO TO END OF THAT LINK. Has simple rules you should follow! Add square serifs to it, if not mentioned.
P - Page page layout and basics stuff - NOT WIDGETS THOUGH...
   Multi-encoding? (text/icon, color/contrast) REally basic stuff like this, or should there be a "Principles" section... or should P stand for principles instead???
  Screens? auto brightness?
  Wrapper I think the concept is valid and worth mentioning. 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? DO think we can combine as one. Unless you think it should be multiple items.
  Idle Screens Basic deck, and the multiple-home-screen mentality Apple esp brought us. Side or other scrolling, pros and cons, indicators of position...
  Signon/Pswds Everything I say about non-obscuring, and notes that you probably don't need it at all; devices are personal and those with secure info better lock the device -- device lock hints: make gestures clear, pattern codes, etc.
  Notifications 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.
  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.
B - Behaviors interaction with no key screen component - Sound, vibration, etc. May overlap gestures but I think it meant output vs. input???
  LED Blink, colors, etc. - Again, got some of these in the blog post on battery indicators
  Sound Audible feedback guidelines, AND reading of on-screen stuff, or reminders, or...
  Backlight Timing can be odd
  Use of technology? Like the N8s nice sleep state clock. Something along the lines of avoiding common practice, and using best practice (OLED power per lit pixel)
K - Key Keyboard, Keypad and Other input features. Gestures here or somewhere else? Sensors?
  Soft keyboards Probably. Unless it should be under Key below. Use my gripes about non-standard Galaxy Epic as a baseline.
  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?
  Haptic feedback?
  Spacing Worth repeating basic ergonomics? Or are we getting into hardware design too much
  Input modes Mostly, the indicator of which mode. http://patterns.design4mobile.com/index.php/Text_Entry should come back even with full keyboards, and soft keyboards I think. Some value as indicator of what entry is ALLOWED for a field, not just what mode currently in.
  Autocomplete All the bad things about predictive text input. I guess. Complex issue.
  Accesskeys Includes screen listing of them. Contrast with numbered lists...
{{{#!wiki yellow/solid
We're editing again: Notes and in-progress pages are the norm for the month of July.

Yeah, it's sub-optimal to read this on many mobile devices. Oh, the irony. We know. This was quick and cheap.
}}}



-----
== The Patterns ==

=== I - Page ===

Introduction to the [[Page]] section.

==== 2 - Wrapper ====

Introduction to the [[Wrapper]] chapter.

 * [[Scroll]] √
 * [[Annunciator Row]]
 * [[Notifications]]
 * [[Titles]]
 * [[Revealable Menu]]
 * [[Fixed Menu]]
 * [[Home & Idle Screens]]
 * [[Lock Screen]]
 * [[Interstitial Screen]]
 * [[Advertising]]

Summary to the Page section [[Page-Wrapup]].

-----
=== II - Components ===
Introduction to the [[Components]] section.

==== 3 - 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]]

==== 4 - Control & Confirmation ====
Introduction to the [[Control & Confirmation]] chapter.
 * [[Confirmation]]
 * [[Sign On]]
 * [[Exit Guard]]
 * [[Cancel Protection]]
 * [[Timeout]]


==== 5 - Revealing More Information ====
Introduction to the [[Revealing More Information]] chapter.
 * [[Windowshade]]
 * [[Pop-Up]]
 * [[Hierarchical List]]
 * [[Returned Results]]

Summary to the Component Section [[Component Wrapup]]

-----
=== III - Widget ===
Introduction to the [[Widget]] section.

==== 6 - Lateral Access ====
Introduction to the [[Lateral Access]] chapter.
 * [[Tabs]]
 * [[Peel Away]]
 * [[Simulated 3D Effects]]
 * [[Pagination]]
 * [[Location Within]]

==== 7 - Drilldown ====
Introduction to the [[Drilldown]] chapter.
 * [[Link]]
 * [[Button]]
 * [[Indicator]]
 * [[Icon]]
 * [[Stack of Items]]
 * [[Annotation]]

==== 8 - Labels & Indicators ====
Introduction to the [[Labels & Indicators]] chapter.
 * [[Ordered Data]]
 * [[Tooltip]]
 * [[Avatar]]
 * [[Wait Indicator]]
 * [[Reload, Synch, Stop]]

==== 9 - Information Controls ====
Introduction to the [[Information Controls]] section.
 * [[Zoom & Scale]]
 * [[Location Jump]]
 * [[Search Within]]
 * [[Sort & Filter]]

Summary to the Widget Section [[Widget Wrapup]]
-----



=== IV - Input & Output ===
Introduction to the [[Input & Output]] section.



==== 10 - Text & Character Input ====
Introduction to the [[Text & Character Input]] section.
 * [[Keyboards & Keypads]]
 * [[Pen Input]]
 * [[Mode Switches]]
 * [[Input Method Indicator]]
 * [[Autocomplete & Prediction]]


==== 11 - General Interactive Controls ====
Introduction to the [[General Interactive Controls]] section.
 * [[Directional Entry]]
 * [[Press-and-hold]]
 * [[Focus & Cursors]]
 * [[Other Hardware Keys]]
 * [[Accesskeys]]
 * [[Dialer]]
 * [[On-screen Gestures]]
 * [[Kinesthetic Gestures]]
 * [[Remote Gestures]]


==== 12 - Input & Selection ====
Introduction to the [[Input & Selection]] section.
 * [[Input Areas]]
 * [[Form Selections]]
 * [[Mechanical Style Controls]]
 * [[Clear Entry]]


==== 13 - Audio & Vibration ====
Introduction to the [[Audio & Vibration]] section.
 * [[Tones]]
 * [[Voice Input]]
 * [[Voice Readback]]
 * [[Voice Notifications]]
 * [[Haptic Output]]


==== 14 - Screens, Lights & Sensors ====
Introduction to the [[Screens, Lights & Sensors]] section.
 * [[LED]]
 * [[Display Brightness Controls]]
 * [[Orientation]]
 * [[Location]]

Summary to the Input & Output Section [[Input & Output Wrapup]]
-----



=== V - Stuff We're (Probably) Not Putting In the Book ===
We made up a LOT of patterns as short descriptions, and when we got around to organizing and detailing them... they didn't all sound that good after all. Also, we have to keep the book at a reasonable size. But, we don't want to loose track of these, so here's an un-ordered list of those ideas we've kicked aside. For now.
 * [[Attach & Reference]] - I liked this concept (it was under Input & Selection), but when I started really thinking about it, I realized it was far more about integrating other stuff with the widget, which is not really the way the rest of the book is written. The reason is, there are like half a dozen of these in the world. No one writes (or can write?) a different one. It's OS based, and even the paradigms change slightly between OSs. Android lets you use any number of services, others do not for example. So... maybe later. Contribute to it if you want.
 * Meter and Levels - Generalized version of what I think of battery meters. For all those things, signal strength, and anything else. Over broad. Also, talked about a bit in the [[Annunciator Row]] pattern itself, so redundant.
 * Ratings - Star ratings, and the like. Indicates a min, max, common and yours. But, every time a service changes it (IMDB, Netflix) people complain. And that's on the desktop side. It's worse when trying to offer multiples, and interactivity on mobile. No best practice yet.
 * Flagging - How you say a piece of content is inappropriate, etc. Some good practices, but all have to be learned (in a comment stream, does it disappear after a while, etc.?) and there's no best practice, therefore. And that's desktop. What about mobile?
 * Tagging - Like adding word tags to an image to make it easier to find. Good idea. Problem is that it can be implemented in so many ways. No one good or commonly used best practice for mobiles as yet.
 * Augmented Reality - Not really a pattern, and too nascent anyway, and when seen now, generally uses common patterns from other types of interactions. Expect to see some unique ones in the future as AR becomes mature.
 * Accessibility - Because of the approach we're taking to describing reasoning, and establishing norms for user perception, it's hard to robustly address accessibility. We're starting to gather this stuff down below (see [[Color Deficit Design Tools]] for one example) but in the pattern book above are just generally considering and making reference, instead of explicitly addressing every edge case. Maybe we need a followup book "Designing Mobile Computing Devices for Universal Accessibility"???
 * [[Screen Stuff]] - A variety of interesting tips and tricks could go here, but are mostly too much tips and tricks, and not enough pattern. Will be more relevant as lit-pixel displays appear, but may be covered other places, like the [[Lock Screen]], which actually already mentions it.



-----
== Design Tools ==
This is all stuff that is not actually in the book, but which we think is very helpful for designing, or getting introduced to mobile design. Much of it is simple links to others, or are design templates, so aren't that useful in a book anyway.

Some of the rest will be real familiar if you read the book (or the wiki chapters above). The templates created by us and shared here are the foundation of the book illustrations, the location discussions in the book are summaries of that below, etc.

Feel free to edit these to add new information, flag or delete bad links and even just add comments about whether some link or bit of information is good or bad.
 * [[An introduction to mobile radiotelephony]] - Cause everyone working in the field really should know.
  * [[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.
 * [[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.
  * [[Italics and Obliques For Digital Display]]
 * [[Greeking]] - If you need to represent placeholder text, read this.
 * [[Color Deficit Design Tools]] - And other tools to help understand colorblindness and related conditions.
 * [[Script Events]] - How different mobile browsers handle, or don't handle, DOM events for Javascript/ECMAscript. NOT DONE.
 * [[Emulators]] - Emulators, prototyping tools, design aids, etc.


-----
== Events & Locations ==
Eric works in Sydney, Australia. Steven lives in the Kansas City, Missouri (US) area, but is mostly around Charlotte, NC or New York City during the week.

We're pretty busy with day jobs, freelance jobs and actually writing the book. But if we're scheduled to go somewhere and talk about anything remotely related to mobile, much less the book, we'll post it here:
 * [[http://floatlearning.com/symposium/|Float Mobile Learning Symposium]] 10 June 2011, Bradley University, Peoria, Illinois


-----
== References ==
 * [[List of References]]

A black and white (the real one will be color) mockup of the cover of our forthcoming O'Reilly book, Designing Mobile Interfaces, by Steven Hoober & Eric Berkman. I thought it would be alphabetical, but now we know who's more important :)

Introduction

If you are picking up this book, you don't need to be told how ubiquitous mobile is, how quickly it is growing and changing, and how much it is supplanting desktop computing, and even more traditional media such as film, television, radio, papers and books.

Mobile is so huge and growing so fast, that astonishing numbers from just a few years ago pale in comparison. So much so, that we won't even bother quoting any figures, as they will be quaint far before the rest of the content looses its relevance.

One thing that has not yet happened is true standards of design. There are just now movements to design the mobile experience first. A good reason is that in many markets, many of your customers look at your website on mobiles more than desktops.

Yet, too much design is based on older paradigms for desktop, or even for TV or print. Within mobile, too many design discussions are very narrowly focused. They pay special attention to applications on a single platform, or only to the mobile web. And almost always at the specific expense of every other platform. Certainly, almost no one discusses anything but smartphones, despite huge marketshare and vast use rates of featurephones.

Fragmentation is discussed as a bad thing for marketing, and sometimes for design, but designers themselves contribute too often by focusing on pixel-based layouts, and the specifics of their favorite OS. This does no one any good, and is especially pointless when you consider the user. Devices generally have many more features and methods of interaction in common than their differences might imply.

Serious mobile design now, and especially in the future, will require building for every user, and providing some solution on every platform.

This book offers a set of common patterns for interaction design on all types of mobile devices. A few patterns require specific hardware or form factors, but most are absolutely universal.

Most do not concern themselves at the top level with implementation details. The correct solution is correct whether at the OS level, as an application or as a website.

Of course, there are notes to discuss alternatives, methods and limitations to assist with decision making. And, many of the specific patterns are coupled with alternatives or variations that allow similarly-useful solutions to be achieved on any type of device.

It's a wiki, but also a book (to be released in October). We need to keep things in synch, so please see the help tab for formatting information, be respectful of content on the site, and add your notes and comments to the appropriate section at the bottom of each page.

Contact @shoobe01 or @ericberkman if you don't see us responding to your change fast enough.

We're editing again: Notes and in-progress pages are the norm for the month of July.

Yeah, it's sub-optimal to read this on many mobile devices. Oh, the irony. We know. This was quick and cheap.


The Patterns

I - Page

Introduction to the Page section.

2 - Wrapper

Introduction to the Wrapper chapter.

Summary to the Page section Page-Wrapup.


II - Components

Introduction to the Components section.

3 - Display of Information

Introduction to the Display of Information chapter.

4 - Control & Confirmation

Introduction to the Control & Confirmation chapter.

5 - Revealing More Information

Introduction to the Revealing More Information chapter.

Summary to the Component Section Component Wrapup


III - Widget

Introduction to the Widget section.

6 - Lateral Access

Introduction to the Lateral Access chapter.

7 - Drilldown

Introduction to the Drilldown chapter.

8 - Labels & Indicators

Introduction to the Labels & Indicators chapter.

9 - Information Controls

Introduction to the Information Controls section.

Summary to the Widget Section Widget Wrapup


IV - Input & Output

Introduction to the Input & Output section.

10 - Text & Character Input

Introduction to the Text & Character Input section.

11 - General Interactive Controls

Introduction to the General Interactive Controls section.

12 - Input & Selection

Introduction to the Input & Selection section.

13 - Audio & Vibration

Introduction to the Audio & Vibration section.

14 - Screens, Lights & Sensors

Introduction to the Screens, Lights & Sensors section.

Summary to the Input & Output Section Input & Output Wrapup


V - Stuff We're (Probably) Not Putting In the Book

We made up a LOT of patterns as short descriptions, and when we got around to organizing and detailing them... they didn't all sound that good after all. Also, we have to keep the book at a reasonable size. But, we don't want to loose track of these, so here's an un-ordered list of those ideas we've kicked aside. For now.

  • Attach & Reference - I liked this concept (it was under Input & Selection), but when I started really thinking about it, I realized it was far more about integrating other stuff with the widget, which is not really the way the rest of the book is written. The reason is, there are like half a dozen of these in the world. No one writes (or can write?) a different one. It's OS based, and even the paradigms change slightly between OSs. Android lets you use any number of services, others do not for example. So... maybe later. Contribute to it if you want.

  • Meter and Levels - Generalized version of what I think of battery meters. For all those things, signal strength, and anything else. Over broad. Also, talked about a bit in the Annunciator Row pattern itself, so redundant.

  • Ratings - Star ratings, and the like. Indicates a min, max, common and yours. But, every time a service changes it (IMDB, Netflix) people complain. And that's on the desktop side. It's worse when trying to offer multiples, and interactivity on mobile. No best practice yet.
  • Flagging - How you say a piece of content is inappropriate, etc. Some good practices, but all have to be learned (in a comment stream, does it disappear after a while, etc.?) and there's no best practice, therefore. And that's desktop. What about mobile?
  • Tagging - Like adding word tags to an image to make it easier to find. Good idea. Problem is that it can be implemented in so many ways. No one good or commonly used best practice for mobiles as yet.
  • Augmented Reality - Not really a pattern, and too nascent anyway, and when seen now, generally uses common patterns from other types of interactions. Expect to see some unique ones in the future as AR becomes mature.
  • Accessibility - Because of the approach we're taking to describing reasoning, and establishing norms for user perception, it's hard to robustly address accessibility. We're starting to gather this stuff down below (see Color Deficit Design Tools for one example) but in the pattern book above are just generally considering and making reference, instead of explicitly addressing every edge case. Maybe we need a followup book "Designing Mobile Computing Devices for Universal Accessibility"???

  • Screen Stuff - A variety of interesting tips and tricks could go here, but are mostly too much tips and tricks, and not enough pattern. Will be more relevant as lit-pixel displays appear, but may be covered other places, like the Lock Screen, which actually already mentions it.


Design Tools

This is all stuff that is not actually in the book, but which we think is very helpful for designing, or getting introduced to mobile design. Much of it is simple links to others, or are design templates, so aren't that useful in a book anyway.

Some of the rest will be real familiar if you read the book (or the wiki chapters above). The templates created by us and shared here are the foundation of the book illustrations, the location discussions in the book are summaries of that below, etc.

Feel free to edit these to add new information, flag or delete bad links and even just add comments about whether some link or bit of information is good or bad.


Events & Locations

Eric works in Sydney, Australia. Steven lives in the Kansas City, Missouri (US) area, but is mostly around Charlotte, NC or New York City during the week.

We're pretty busy with day jobs, freelance jobs and actually writing the book. But if we're scheduled to go somewhere and talk about anything remotely related to mobile, much less the book, we'll post it here:


References

Index (last edited 2019-12-04 17:45:44 by shoobe01)