Design & Implement Responsive Confirmations

Registered by Cassidy James Blaede on 2012-05-12

We need to research, design, develop, test, and implement a system for responsive confirmations in Pantheon. Responsive confirmations are, put simply, confirmations displayed in response to a user action. Some examples would be displaying the brightness or volume level when the user adjusts it, showing multimedia key presses when the multimedia app is not focused, etc.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Medium
Drafter:
elementary UX
Direction:
Needs approval
Assignee:
None
Definition:
Drafting
Series goal:
None
Implementation:
Not started
Milestone target:
None

Related branches

Sprints

Whiteboard

For starters, I think it’s important to distinguish between the three ways we present information to the user. First, we have active notifications, such as incoming email or instant messages. Notifications are related to something that’s happening right now. Next, we use persistent indicators, such as the audio, time, and networking indicators. Indicators display an at-a-glance status while providing a place for more information and interaction. Lastly, we have responsive confirmations, such as when manipulating the volume or brightness. Confirmations tell the user that their intent has been understood and display immediately-relevant information.

One important function of responsive confirmations is to show the user that their intent had been understood whether or not the action can be completed. For example, a user with their display as bright as it goes may press a brightness up key and wonder why their display did not get any brighter. We show them that we understand they pressed the key, but that the display brightness is as bright as it goes. Another example could be pressing the eject key on a slot-loading disc drive without a disc in it. The user may think there's a disc present and wonder why it doesn't come out when they hit the key. We show them that we know they hit the key, but that no disc is present to eject.

We should distinguish between notifications and confirmations since they're different in nature. We could go with the Mac OS X/GNOME/iOS approach (a large, centered confirmation), the Android/Chrome OS approach (a manipulable transient popup), or something else entirely. I'm drafting a Journal article further detailing the issue and some possible solutions, so look forward to that.

Otherwise, hit up the specification URL for a Google Doc with a bunch of research and some ideas we're drafting.

---

If we do go with the Chrome OS approach, there's a lot of work to do. But if we do it right, it could end up being very cool. So here are my thoughts around that:

1. Notifications and Confirmations have to exist on the same layer. That is, Confirmations should push notifications down out of the way as if they are put of the notification stack.

2. Confirmations should only show the relevant control, but expand to reveal the full indicator. This gives them a tie-in to their software-control location without making them over-bearing and awkward.

3. Indicator popovers should be designed at the same width and with a similar layout as notification bubbles so that confirmations seamlessly blend into the notification stream and don't appear like awkward menus popping open and closed.

Thoughts? --DanRabbit

Illustration of the indicator-as-confirmation idea: http://pix.toile-libre.org/upload/original/1337214983.png --shnatsel

Do the indicators have to pop out for confirmation? To some extent, users already get confirmation solely from the indicator icon. Examples: I unplug my charger, the battery indicator has no lightning bolt (and vice versa). I turn off my wifi, the networking indicator reflects that by not showing the wireless bands. As I turn my volume up and down, the sound icon gains more waves (I have no idea what to call those things :). In order to make this work, icons must have a way to show that the action was recognized, but action could not be taken (no disc to eject, the volume is already maxed). Maybe it could flash subtly or turn a different color momentarily? One down side to this no pop out approach is that it is not very extensible. If we wanted to confirm that the "Media Play" button was pressed, the sound indicator icon could not easily reflect that. ~CameronNemo

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.