''Since you probably missed it, Eric and I wrote Designing Mobile Interfaces pretty much on this wiki, then turned it into Word and sent it to O'Reilly. I am doing the same again for a somewhat different work, but another book length one on mobile. If it pans out, you can follow along, and add your comments, here.'' 

When Eric Berkman and I conceived and wrote ''Designing Mobile Interfaces'', the world of mobile was rather more complex than it is today. As much as everyone likes to complain about fragmentation, we had to contend with many more popular OSs, with ubiquitous featurephones, with an unclear niche for tablets, and the expectation that other devices like portable gaming, or stripped down eReaders would be a major force in mobile and portable computing. 

''Designing Mobile Interfaces'' was, in many ways, a manifesto against books like ''Tapworthy''. While fine, wonderfully-done, even aspirational works, they also espoused a singular view of the world. And back then, that was either an iOS view, or a Web view. This has persisted, but been joined by a popular and often well-done Android-only world view, and the well-designed factions built around the also-ran Blackberry and Windows platforms. ''Designing Mobile Interfaces'' deliberately offered a generalized solution. Often, this exposed fundamental truths I didn't recognize before we started. Occasionally, it was a bit of a stretch. Sometimes, eliminating interesting but singular features or widgets as being too much of a particular platform. 

In the very few years since then, the world has changed. Smartphones rule. Tablets have a home, and it's something other than a big phone. eReaders are just for reading. Game devices are also smartphones. There is much to be done on featurephones, SMS and other critical interfaces, but these are -- like tablets -- something else and increasingly best pursued by experts in those fields. 

And one more thing happened: The smartphone interfaces are starting to agree with each other on what it means to be a good GUI. As I write giant strategy screeds, and build style guides and pattern libraries, and assist developers for my clients, I have been finding that the variations between platforms are increasingly subtle, technical, and semantic. It is possible now to really make sense of principles of designing for every platform, using these common GUI elements, and better understandings of how people actually use their mobile devices. 

 * [[Is this book for me?]]
 * [[What is in this book, and what isn't]]
 * [[Air logic]]

=== More random intro ===

The following are thoughts -- increasingly ordered thoughts, though -- that have come up lately based on writing about creating specs, creating pattern libraries for clients, trying to help startups and small clients get their heads around design in an ordered manner, and speaking on design in general. This is partly because things seem to be settling into better cross-platform patterns. And also from some touch revelations about differences in clicking parts of the screen. Instead of adding and tweaking, an all new structure. ''Designing Smartphone Interfaces'' is not a revision 2 of ''Designing Mobile interfaces'' but a new format, leading you through a design process much more linearly. 

This is not the intro for an actual book. I'd write that later. Examples will be provided, both screenshots/specs and technical methods, for Android/iOS/BB10/Windows?

Note to myself: Need to make the patterns much more around Design By Zones. See the article on that and ponder a segue from the intro and structural overview topics into it.

 * App, Webapp, Hybrid App, Website
  * My definitions of these. The good, the bad especially (go bad to essay on [[http://shoobe01.blogspot.com/2012/08/hybrid-development-is-worst-thing-ever.html|hybrid]]), how html5 works, and doesn't (cache sizes change all the time). 
  * How this book doesn't draw distinctions for one key reason: The distinctions get real, real fuzzy and are getting fuzzier over time. 
  * Need to define some terminology. "Your app" is what I call them anyway or come up with something like "Your system" to be generic? 
 * IA - Multi-device/Omni-channel stuff. Core to this is design-once -> branch to each platform. 
 * New section title. Then move "IA" down to the Flow/Process section which is next, with a few of these features. 
  * Define device classes
   * Top out at phablets
   * How tablets are different, but are not really discussed here. Same for touch kiosks, touch-enabled desktop/laptop computers, 
  * Discuss features
   * Sensors, available and soon to appear. Summarize location services especially, including beacons, use of radios for it
   * Browser technologies. I think. Are they different enough anymore for /smartphones/ to matter? 
   * What else the phone does: Software are OS features. Custom URI, intent pickers for Share, etc. 
   * Radio technologies, with the point that a lack of mobile ntwk makes it a MID and how these change location (no AGPS), remove features (no SMS), etc. But how this is increasingly unimportant as VoIP and constantly-dropping voice use rates make it less important.  
   * Feature detection for apps and Web, device detection for Web. Seed discussion on next section about designing ''for'' features. 
 * Flow & Process - Cover stuff like the stack from Android, in principle, and. 
  * Principles of design for imperfection, failure, etc.  
  * Features you don't include because they are provided by other apps, the OS, etc. Details about intent pickers, etc. 
  * Maybe a bit about specifying widgets vs. designing them. 
 * Information Design - Back to that term, consider it like IA per page component. 
  * Device grasping and touch stuff. Cover the research. Why this matters (e.g. obscuring content with the selection finger). 
  * How people use their phones. Context, in the broader sense like in the article with Mudassir. 
  * There are no pages. Be clear about states and widgets and info areas. View areas, and so on help understand why scrolling is not for the page. 
  * Break out the sections of the page, and how hierarchies work within the viewport. 
 * Patterns, grouped by section - Much like DMI structure but add something about (section or focus?) on Fault Tolerance, to avoid errors and make it track to the resilience principles. 
  * Intro: All patterns are good. Misuse, and incorrectly following the pattern is what causes issues. 
  * Like, Title bars are getting to be much the same so can be covered in one pattern
  * Like, Menus are more often drawers than fixed (iOS) or popups. 
  * More, more, more... 
  * [[Lists & Tables]]



Things which may or may not be related and I want to read:
 * http://www.patternlanguage.com/archives/alexander1.htm