These are just thoughts that have come up lately based on writing about creating specs, creating pattern libraries for clients, etc. 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.
- Define device classes
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. Why this matters (e.g. obscuring content with the selection finger).
- 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...