|
Size: 16249
Comment:
|
Size: 16257
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 34: | Line 34: |
| Introduction to the [[Wrapper]] chapter. | Introduction to the [[Wrapper]] chapter. √ |
There are still some bugs or incomplete elements here and there. If you think something is really broken, feel free to contact a site admin. Please see the help tab for formatting information, and be respectful of content on the site if you add anything.
The Components section is complete as of 15 November 2010. As a general rule, links here without lots of notes after them are completed, or in progress enough they are worth reading. For now, a √ symbol after a link (only on the home page) is entirely completed.
Introduction
Design seems like something that should be ridiculously easy. And for some things, it can be. When you organize your workspace -- move the desks around, get a different keyboard -- you are designing that experience for yourself. And generally you can do a pretty good job.
Now that your office is arranged the way you want it, you get down to developing a mobile application. Design there must be just as easy. You arrange the data, and the structure of the site, in a way that makes sense to you. You make a presentation layer that reflects that perfectly sensible data arrangement. And when you launch it, everyone complains. Why can't they see the brilliance of your ideas?
Because they are yours. And a key to design is that it is a selfless practice. You cannot think of how design will work for you, or even your friends, but for your users, and probably all your users. The language can rapidly sound like a revolutionary; you have to consider your users as a collective.
The Patterns
I - Page
Introduction to the Page section.
2 - Wrapper
Introduction to the Wrapper chapter. √
Page-Wrapup notes and guidelines.
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
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. This definition http://www.webopedia.com/TERM/W/widget.html (#1 only)except mobile scale is smaller, so don't include Pop-Ups, and we put a few things like scrollbars somewhere else for organization.
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.
IV - Input & Output
Keyboard, Keypad and Other input features. Gestures here or somewhere else? Sensors? - Sizes of touch targets, etc. Include diagrams from Mobile Design Elements. Also see this W3C stuff, or at least refer to the group: http://www.w3.org/2010/webevents/
10 - Keyboards & Keypads
Key entry in general, I think. Discuss remote entry as well, at least in the intro. Like remote controls (e.g. TV, game stations).
Soft keyboards Probably. Unless it should be under Key below. Use my gripes about non-standard Galaxy Epic as a baseline. Also, significant overlap: The Samsung Zeal is a dual hinge. Solves the keyboard orientation problem with clear keys, revealing eInk behind it! Changes labels, and orientation (10 key and 5-way converts to QWERTY). Neat as hell, as well as blurring virtual and hardware, so maybe merge all these as one.
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.
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? See Finger Gestures below...
Spacing Worth repeating basic ergonomics? Or are we getting into hardware design too much
Autocomplete All the bad things about predictive text input. I guess. Complex issue. Mostly: autocomplete listings, when to offer autocomplete answers. LOTS about not to do: do not add spaces, at least in user/pswd fields, do not overly aggressively autocomplete in search fields; when modding a bad search, can make it impossible to search a different term, etc.
Accesskeys Includes screen listing of them. Contrast with numbered lists...
11 - Finger Gestures
swipe, pinch and zoom, tapping - Relatively FEW are included, as they are patterns. Need to be identifiable best cases. Weird gestures, or those with too much variability for user type, region, etc. are not included as they are not patterns in the sense we mean. Interesting list of articles: http://www.pointanddo.com/2009/09/10-best-articles-on-multitouch.html -- Discuss remote entry. Like, using a pointing pad, etc. for a TV.
Tap Perform action. Go somewhere, select something, etc. People screw this up. See lowish item in this RISKS https://mail.google.com/mail/?shva=1#inbox/12bf56f02bca29b5 pressing selects item, then item on the next screen!
Tap & Hold Alternative interaction - Light "right click" - should provide option, not just DO other action- Must indicate state change, like how INDD doesn't do what FH11 does on press and hold before drag.
Drag Moves something. Maybe the whole screen. In the direction (or axis) selected. When not free movement, try to have arrows to indicate axis-of-movement - Cover inertia also
Pinch Zoom Two finger apple-like pinch to unzoom, etc.
Axis Rotate Two finger rotate. One is axis, one is rotation.
12 - Kinesthetic gestures
Whole body motions, whole-device motions (e.g. face down=sleep), and even sensing such as speed, gait... - NOT TOO FUTURISTIC! Roll handset: , Raising to face, Lowering from face, Tapping two devices together, Motioning handset towards RFID, Whipping: A quick down-up motion - Consider remoting, where a fixed device senses a remote device (wii) or the user directly (xbox), at least in intro, and in method of writing them.
Shake shaking handset rapidly on multiple axis. Used to refresh and reload displayed information or to scatter data.
Roll Rolling device onto it's opposite side will change it's current state. i,e. face down=sleep.
Tapping Tapping two handsets together can be used for file and information sharing
Whipping Rapid back and forth action used to throw or cast information i,e. fishing reels used in games
Raising consider more...antipattern?
Lowering consider more...antipattern?
Proximity to Signals like audio detection on car radios? RFID, card readers....FUTURE, orientation of detectors on handset? Cultures?
Rotation rotating device on axis or planes to change the orientation of the information displayed.
13 - On-Screen Inputs
Button behaviors (look clicked, press-and hold), also select-lists, etc. - Consider them systematically to be an input selection method. So they go here! NOTE: Buttons are not one of the patterns below? Do they need to be? Sometimes covered in others, can detail: Differentiate which is highlight (like new Sony BD, moves the highlight live!), priority or preference button, etc.
Input Areas Form, or sms input area, or... anything you put text... http://patterns.design4mobile.com/index.php/Text_Entr
Input Method Indicator Hanging off the side of a field. Talk (maybe) about how input method for the whole screen is an anti-pattern? Indicates the current and/or the available methods... Need to work on the best practice here!
Select lists Cover all - pulldowns, radios, checks, because differences can be fuzzy, and some are bad implementation, e.g. J2ME/S60 default full-page input; (NOT on-page lists or simple nav: refer to Information Display chapter above) Anti: Select lists should not look like anything else, and buttons (etc.) should not look like select lists. E.g. Seesmic.
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. Acceleration (especially scroll and select) should snap to even numbers; see Sony alarm clock behavior in this regard.
Attach & Reference Maybe... Push button to go somewhere and get a file to attach, as with MMS. Or reference a person, as with address to send to. Still a field, usually, and you activate differently to cross-link, etc.
Text Insertion Point Text insertion points, the mag insertion for iPhone edit for example.
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)
14 - Audio & Vibration
Beeps and why they are bad. Tone types. Audio readback best practices. Look at med reminder for some of these. Voice input. Vibrate is just crappy haptics. Include it.
Tones See Ecosystem of Beeps, and riff off that. Beeps should imply things. Like crosswalk tones aren't just beeps!
Voice Input look it up. I know little.
Voice Readback Have some of this in specs we can look up.
Voice Reminders Voice reads out without warning. "Time to go to the dentist." Privacy concerns, and "uh" acclimation issues. Needs to probably be after you ack that a message has arrived, so are paying attention, but a valid method for low-vision, or otherwise cog disabled folks.
Haptic Output Vibration responses and reminders. Two different things.
15 - Screens & Lights
LED Blink, colors, etc. - Again, got some of these in the blog post on battery indicators. ALSO: other ways to illum. Wii blinks cd slot, can blink/change color of backlight as parking meters do, have shine thru a custom shape in plastic as printers do, etc, just a reminder to use cleverness and be more contextual vs just another device w blinking lights. And, it should not cost more!
Screen cleverness Like the N8s nice sleep state clock. Something along the lines of avoiding common practice, and using best practice (OLED power per lit pixel)
Distance from users Guidelines, mostly, on how people hold phones closer than tabs, or laptops, or desktops or TVs (like my photo). Guideline or anti: don't change based on distance from user, as they are already adjusting...
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.
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.
Design Tools
Things other than the patterns themselves you can use to help design. Templates (including those used to draw the diagrams here), stencils, simulators, emulators, etc.
Script Events - How different mobile browsers handle, or don't handle, DOM events for Javascript/ECMAscript
Emulators - Emulators, prototyping tools, design aids, etc.
Color Deficit Design Tools - And other tools to help understand colorblindness and related conditions.
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.
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.
Set up Photoshop and Illustrator color controls - Okay, not really mobile, but a constant source of frustration. Valid for anyone who works in interactive pretty much all the time.