• Designing Smartphone Interfaces

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 was generalized. Often to great effect, exposing fundamental truths I didn't recognize before we started. Occasionally, with 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?

In my ideal world, you are a serious UX practitioner or a student. You have read the classics and follow the points of my philosophy of each pattern. When you decided to get into mobile, you took a class where they used Designing Mobile Interfaces as a textbook, so you have a background in how locations services and radios work, as well as how mobile OSs like to be organized. Then, you get this as your constant companion when you get invited to that startup team or you get your first job. Because the world is going mobile, fast, and you need to know how to make stuff for those.

In reality, I know 90% of you are Web designers pressed into the mobile space. Or perfectly good and happy developers, analysts, or product owners who everyone else decided has the most fashion sense, so you are in charge of adding some user experience to the products. This book is very much for you also. Maybe more so, as many of the lessons and the organization is based on my work directly trying to assist, and more importantly to mentor skilled technicians with no UX experience.

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?

• App, Webapp, Hybrid App, Website

  • My definitions of these. The good, the bad especially (go bad to essay on 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...