1. Triggers
1.1. What?
1.1.1. Initiate a microinteraction
1.2. Types
1.2.1. User initiated
1.2.1.1. Ex: silence iPhone
1.2.1.1.1. User need: All the time, rapidly. Trigger - available all the time; visual affordance tells about the microinteraction; Otherwise, users would expect the trigger, but had to put effort in finding it
1.2.1.2. Principles
1.2.1.2.1. Principle 1: match the user need (when and where) with the location of the trigger
1.2.1.2.2. Principle 2: have the trigger initiate the same action every time -> accurate mental model
1.2.1.2.3. Principle 3: Bring the data forward. Trigger can reflect the data contained in the interaction
1.2.2. System initiated
1.2.2.1. when certain conditions have been met
1.2.2.1.1. Conditions: errors, location, incoming data, internal data, other microinteractions, other people (ex: reply to a chat, send a friend request)
1.2.2.2. ex: silencing phone integrated with calendar; when you are in a meeting -> silence
1.2.2.3. Good practice: Every system-initiated trigger should have some manual means of managing or disabling them. Ideally - at the point of instantiation, minimum - in the settings area
2. Rules
2.1. What?
2.1.1. Determine what happens
2.1.2. Create a nontechnical model of the microinteraction
2.1.3. They define what can and cannot be done, and in what order
2.1.4. 1. Determine the goal of the microinteraction
2.1.4.1. Understandable (I know why I'm doing this) and achievable (I know I can do this); Goal - end state ex: login - goal: to get the user logged in [not just to enter a user and pass]
2.1.5. 2. Rules determine
2.1.5.1. how the microinteraction responds to the trigger being activated;
2.1.5.2. what control the user has (if any) over a microinteraction in process;
2.1.5.3. the sequence in which actions take place and the timing;
2.1.5.4. what data is being used and from where;
2.1.5.5. the configuration and parameters of any algorithms;
2.1.5.6. what feedback is delivered and when;
2.1.5.7. what mode the microinteraction is in if the microinteraction repeats and how often; one time activity or does it loop? what happens when the microinteraction ends?
2.2. Example
2.2.1. Initial: 1. On an item page, user clicks Add to Cart button. 2. The item is added to the Shopping Cart
2.2.2. Upgraded: 1. On an item page, check to see if the user has purchased this item before. If so, change the button label from Add to Cart to Add Again to Cart. 2. Does the user already have this item in the cart? If so, change Add to Cart to Add Another to Cart. 3. The user clicks button. 4. The item is added to the Shopping Cart
2.3. Principles
2.3.1. Principle 1: Don't start from zero!
2.3.1.1. First question after trigger: what do I know about the user and the context?
2.3.1.2. (platform/device, time of day, battery life, location, user's past actions etc)
2.3.2. Principle 2: Absorb complexity
2.3.2.1. All activities have an inherent complexity; there is a point beyond which you cannot simplify a process any further;
2.3.2.2. What to do with that complexity: either the system handles it -> removes control from the user; or the user -> more decisions, more control
2.3.2.3. Suggested: handle most of the decision making if possible.
2.3.2.4. Complexity? Which parts the user might like to have and when?
2.3.2.5. Limited options and smart defaults
2.3.2.5.1. The best way to keep rules to a minimum is to limit options
2.3.2.5.2. The most prominent default should be the action that most people do most of the time
2.3.3. Principle 3: Use rules to prevent errors
2.3.3.1. ex: Apple chargers vs. USB;
2.3.3.2. ex: Gmail "I've attached" with no attachments
2.3.3.3. Make human errors impossible. Keep copy short. Never use instructional text where a label will suffice.
3. Feedback
3.1. What?
3.1.1. Let people know what's happening
3.1.2. Anything you see, hear, or feel that helps you to understand the rules of the system
3.1.3. Feedback is the place to express the personality of the product
3.2. Types
3.2.1. Visual (graphics)
3.2.2. Aural (sounds)
3.2.3. Haptic (vibrations)
3.3. Example
3.3.1. Silencing iPhone - 2 feedbacks: overlay when silencing + strip of orange on the actual switch
3.4. Principles
3.4.1. Understand what information the user needs to know and when. All feedback relies on this understanding. Feedback is for understanding the rules of the microinteraction. Figure out which rules deserve feedback.
3.4.2. Determine what message you want to convey with feedback, then select the correct channel(s) for that message.
3.4.3. Look at context and see if the feedback can (or should) be altered by it. Be human. Feedback can use a veneer of humanity to provide personality to the microinteraction.
3.4.4. Use preexisting UI elements to convey feedback messages. Add to what is already there if you can before adding another element. Don’t make feedback arbitrary. Link the feedback to the control and/or the resulting behavior.
4. Loops and modes
4.1. What?
4.1.1. Meta-rules of the microinteraction
4.2. Loops
4.2.1. What?
4.2.1.1. What happens over time with the interaction?
4.2.1.2. Do the interactions remain until manually turned off? Or do they expire after a while? What happens during an interruption or when conditions change?
4.2.2. Examples
4.2.2.1. Loop: bought 1 in cart, buy it now -> buy another
4.2.2.2. Progressive reduction/disclosure
4.2.3. Principles
4.2.3.1. Use loops to extend the life of a microinteraction
4.2.3.2. Carefully consider the parameters of loops to ensure the best user experience
4.2.3.3. Use long loops to give the microinteraction memory or to progressively disclose or reduce aspects of the microinteraction over time
4.3. Modes
4.3.1. What?
4.3.1.1. Modes are a fork in the rules of a microinteraction.
4.3.2. Principles
4.3.2.1. Only have a mode when there is an infrequent action that might otherwise clutter the microinteraction.
4.3.2.2. If you must have a mode, make it its own screen when possible.
4.3.2.3. For rapid actions, consider using a spring-loaded or one-off mode instead of a traditional mode.
4.3.2.3.1. Spring-loaded mode: mode active when a physical action is done
4.3.2.3.2. One-off mode: lasts for the duration of a single action
5. About
5.1. This is a summary of "Microinteractions" by Dan Saffer
5.2. See more on: http://microinteractions.com/
6. Overview
6.1. What?
6.1.1. Product moments
6.1.2. A single use case
6.1.3. One main task
6.2. Why?
6.2.1. Easier lifes for users
6.2.2. More interesting or fun product
6.2.3. Differentiators: signature moments
6.2.4. "Feel" in the Look & Feel of the product
6.2.5. More important in competitive markets
6.2.5.1. When feature parity - experience matters a lot
6.2.6. Multi-platform
6.2.6.1. Glue that can tie the experience of the users
6.3. Examples
6.3.1. Change a setting
6.3.2. Set am alarm
6.3.3. Comment
6.3.4. Log in
6.3.5. Send feedback
7. To practice
7.1. Fixing a dull microinteraction
7.2. Questions to ask
7.2.1. Should this be a Signature Moment?
7.2.1.1. How memorable should it be? The more memorable, the richer it can be in terms of controls (including custom controls) and feedback.
7.2.2. Am I starting from zero?
7.2.2.1. What do I know about the user or the context that would improve this microinteraction?
7.2.3. What is the most important piece of data inside this microinteraction, and can I bring it forward?
7.2.3.1. What does the user need to know at a glance?
7.2.4. Would a custom control be appropriate?
7.2.4.1. A custom piece of UI practically guarantees the microinteraction will become more prominent.
7.2.5. Am I preventing human errors?
7.2.5.1. If there are any situations where a user can cause an error, what can you do to prevent that automatically?
7.2.6. Can I make an invisible trigger for advanced users?
7.2.6.1. Is there a place to make a hidden shortcut (via a gesture or a command key) to get deeper into the rules faster?
7.2.7. Are the text and icons human?
7.2.7.1. Does the microcopy sound like something another human would say out loud? Can you add a touch of humor?
7.2.8. Can you add animation to make it less static?
7.2.8.1. Could you have transitions between screens or states, or an (nonintrusive) indicator of what the next step would be?
7.2.9. Can you add additional channels of feedback?
7.2.9.1. Sound or haptics?
7.2.10. What happens when the user returns to the microinteraction the second time?
7.2.10.1. And the hundredth time. Figure out what the long loop could be.