Differences between revisions 3 and 12 (spanning 9 versions)
Revision 3 as of 2011-04-19 01:52:47
Size: 1696
Editor: shoobe01
Comment:
Revision 12 as of 2013-04-08 20:01:47
Size: 3187
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
{{{#!wiki yellow/solid
This page is a stub. It's just something to get notes down, and is not final in any way.
{{{#!html

<div class="saleshead">
    <div class="block" id="left">
        <a href="http://4ourth.com/wiki/4ourth%20Mobile%20Touch%20Template">
        <div class="salesLeft">
           <h3>4ourth Mobile Touch Template</h3>
           <p>Design for people, not pixels with this handy, wallet-sized inspection and design tool, only $10. <span>Order yours now</span></p>
        </div>
        </a>
    </div>
    <div class="block" id="right">
        <a href="http://4ourth.com/wiki/Mobile%20Design%20Patterns%20Poster">
        <div class="salesRight">
           <h3>Mobile Interaction Design Patterns Poster</h3>
           <p>Every pattern from the book and this wiki, plus easy-to-follow relationships, and key information on sizes for readability and touch. <span>Order now</span></p>
        </div>
        </a>
    </div>
    <div class="salespad">&nbsp;
    </div>
</div>
Line 5: Line 26:
Chat about this. We don't repeat stuff just because it's used everywhere. If it's common, but awful, we include it, but with warnings...
Line 7: Line 27:
[[http://www.amazon.com/gp/product/1449394639/ref=as_li_tf_tl?ie=UTF8&tag=4ourthmobile-20&linkCode=as2&camp=217145&creative=399373&creativeASIN=1449394639|{{attachment:wiki-banner-book.png|Click here to buy from Amazon.|align="right"}}]]
A key overriding principle behind much of this work is the differentiation between common practice and best practice. Although not always explicitly stated, this is what drove activities such as the inclusion of antipatterns (or “worst practices”) for each pattern. There are many, many design patterns that do not work, or do not work as well as alternatives.
Line 8: Line 30:
This is a key reason so much effort went into researching the patterns. We didn’t include something just because it was heavily used, or is a much-lauded feature of a new and well-covered device; if it was common or well known, but bad, we included it, but with warnings.
Line 9: Line 32:
This all needs to be tied together as a single thought. What's a pattern, this, the style and so on. So we can expand on thoughts like: The patterns were developed by observing and analyzing a large number of devices -- featurephones, smartphones, pdas, tablets, gps's, etc. Key components were observed to be true in most devices, and used pretty consistently. Those were generally considered to be patterns. This also means, again, that we had some serious discussions about what qualified as a pattern. In general, a pattern must be a best practice, and common enough to be recognized or encountered.
Line 11: Line 34:
The patterns themselves were then analyzed to assure they meet the basics for good UI/UX design. When gaps are found, or are simply exposed from our own knowledge and observations (from lab tests, etc.) these common practices ended up being anti-patterns, and the best practice is written up instead. Therefore, there may be some odd cases where an antipattern has general solutions listed, but no specific solutions in the body of the pattern. Though the problem is known, no single solution has emerged.
Line 13: Line 36:
In general, best practice that is not implemented anywhere is not described, as it does not rise to the level of a pattern. Only real world items are patterns by our thinking, not clever concepts. There may therefore be some odd cases where an antipattern has general solutions listed, but no specific solutions in the body of the pattern. The antipattern is listed as it's a known problem, but no single solution has emerged. A best practice that is not implemented anywhere (or only very rarely) is not described, as it does not rise to the level of a pattern. Only real-world items are patterns by our thinking, not clever concepts, demonstrations, or videos of how the future might work. These are, however, sometimes mentioned as future technologies or options to look forward to.
Line 15: Line 38:
Other times, this is simply described as such in the pattern. Other gaps, such as emerging technologies or interesting implementations that could use a pattern, but do not yet do so -- or do not do so consistently -- are likewise left out, or are noted as being not yet a pattern. -------
Next: [[Reading the Patterns]]
-------
= Discuss & Add =
Please do not change content above this line, as it's a perfect match with the printed book. Everything else you want to add goes down here.

== Examples ==
If you want to add examples (and we occasionally do also) add them here.

== Make a new section ==
Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.

Click here to buy from Amazon. A key overriding principle behind much of this work is the differentiation between common practice and best practice. Although not always explicitly stated, this is what drove activities such as the inclusion of antipatterns (or “worst practices”) for each pattern. There are many, many design patterns that do not work, or do not work as well as alternatives.

This is a key reason so much effort went into researching the patterns. We didn’t include something just because it was heavily used, or is a much-lauded feature of a new and well-covered device; if it was common or well known, but bad, we included it, but with warnings.

This also means, again, that we had some serious discussions about what qualified as a pattern. In general, a pattern must be a best practice, and common enough to be recognized or encountered.

Therefore, there may be some odd cases where an antipattern has general solutions listed, but no specific solutions in the body of the pattern. Though the problem is known, no single solution has emerged.

A best practice that is not implemented anywhere (or only very rarely) is not described, as it does not rise to the level of a pattern. Only real-world items are patterns by our thinking, not clever concepts, demonstrations, or videos of how the future might work. These are, however, sometimes mentioned as future technologies or options to look forward to.


Next: Reading the Patterns


Discuss & Add

Please do not change content above this line, as it's a perfect match with the printed book. Everything else you want to add goes down here.

Examples

If you want to add examples (and we occasionally do also) add them here.

Make a new section

Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.

Common Practice Versus Best Practice (last edited 2013-04-08 20:01:47 by shoobe01)