Jump to content

Sprints/UX2011/KMessageWidget: Difference between revisions

From KDE Community Wiki
Agateau (talk | contribs)
Agateau (talk | contribs)
No edit summary
Line 7: Line 7:
3. Find/replace panels
3. Find/replace panels


== Feedback ==
== Negative feedback ==


=== Negative feedback ===
The KMessageWidget should be used as a secondary indicator of failure: the first
 
The MessageWidget should be used as a second indicator of failure: the first
indicator is that the action the user expected to happen did not happen.
indicator is that the action the user expected to happen did not happen.


Example: User just filled a form, clicks "Submit".
Example: User fills a form, clicks "Submit".
* Expected feedback: form closes
* Expected feedback: form closes
* First indicator of failure: form stays there
* First indicator of failure: form stays there
* Second indicator of failure: a MessageWidget appears on top of the form
* Second indicator of failure: a KMessageWidget appears on top of the form


==== Placement of the MessageWidget ====
When used to provide negative feedback, KMessageWidget should be placed close to its context. In the case of a form, it should appear on top of the form entries.


MessageWidget should be placed close to its context. In the case of a form, it
KMessageWidget should get inserted in the existing layout. Space should not be
should appear on top of the form entries.
reserved for it, otherwise it becomes "dead space", ignored by the user.
KMessageWidget should also not appear as an overlay to prevent blocking access to elements the user needs to interact with to fix the failure.


MessageWidget should get inserted in the existing layout. Space should not be
== Positive feedback ==
reserved for it, otherwise it becomes "dead space", ignored by the user.
 
MessageWidget should not appear as an overlay to prevent blocking access to
KMessageWidget can be used for positive feedback but it shouldn't be overused.  
elements the user needs to interact with to fix the failure.


=== Positive feedback ===
Use KMessageWidget to:
* Confirm success of "critical" transactions
* Indicate completion of background tasks


Should be used sparingly: only to confirm success of high-risk transactions or
Do not use KMessageWidget to:
completion of background tasks.
* Indicate successful saving of a file


== Opportunistic interaction ==
== Opportunistic interaction ==
Opportunistic interaction is the situation where the application suggests to the user an action he could be interested in perform, either based on an action the user just triggered or an event which the application noticed.


Example use cases:
Example use cases:
Line 44: Line 46:
== Layouts ==
== Layouts ==


The MessageWidget should provide two possible shape: line and rectangle.
The KMessageWidget should provide two possible shape: line and rectangle.


=== Line ===
=== Line ===
Line 85: Line 87:
  +--------------------+
  +--------------------+


Queuing: MessageWidgets should not stack on each others. Assuming MessageWidget
Queuing: KMessageWidgets should not stack on each others. Assuming KMessageWidget
A is visible, if MessageWidget B is created, it should wait until A has been
A is visible, if KMessageWidget B is created, it should wait until A has been
visible for at least 3 seconds and replace it.
visible for at least 3 seconds and replace it.



Revision as of 07:41, 16 April 2011

Three kinds of uses:

1. Positive or negative feedback

2. Opportunistic interaction (example: Firefox "remember password" bar)

3. Find/replace panels

Negative feedback

The KMessageWidget should be used as a secondary indicator of failure: the first indicator is that the action the user expected to happen did not happen.

Example: User fills a form, clicks "Submit".

  • Expected feedback: form closes
  • First indicator of failure: form stays there
  • Second indicator of failure: a KMessageWidget appears on top of the form

When used to provide negative feedback, KMessageWidget should be placed close to its context. In the case of a form, it should appear on top of the form entries.

KMessageWidget should get inserted in the existing layout. Space should not be reserved for it, otherwise it becomes "dead space", ignored by the user. KMessageWidget should also not appear as an overlay to prevent blocking access to elements the user needs to interact with to fix the failure.

Positive feedback

KMessageWidget can be used for positive feedback but it shouldn't be overused.

Use KMessageWidget to:

  • Confirm success of "critical" transactions
  • Indicate completion of background tasks

Do not use KMessageWidget to:

  • Indicate successful saving of a file

Opportunistic interaction

Opportunistic interaction is the situation where the application suggests to the user an action he could be interested in perform, either based on an action the user just triggered or an event which the application noticed.

Example use cases:

  • A browser can propose remembering a recently entered password
  • A music collection can propose ripping a CD which just got inserted
  • A chat application may notify the user a "special friend" just connected

Layouts

The KMessageWidget should provide two possible shape: line and rectangle.

Line

+----------------------------------+
| Password is wrong                |
+----------------------------------+
+--------------------------------------------------------------------------+
| Remember password for site example.com? (Remember) (Do not remember) (X) |
+--------------------------------------------------------------------------+

The widget height should always be the height of one line of text (plus margins). If text is too long, it should be cropped like this:

+------------------------------------------------------------------+
| Remember password for... _more_ (Remember) (Do not remember) (X) |
+------------------------------------------------------------------+

Clicking on _more_ expands the widget to multiple lines:

+------------------------------------------------------------------+
| Remember password for site      (Remember) (Do not remember) (X) |
| example.com?                                                     |
+------------------------------------------------------------------+

Note: One should try to ensure the beginning of the message text makes it possible for the regular user to understand the message without clicking on the _more_ link. So avoid generic introductions like "Do you want FooApp to...".

Rectangle

Example usage: showing feedback at the bottom of a sidebar.

+--------------------+
| Do you want to (X) |
| rip this CD?       |
|                    |
|           (Rip CD) |
+--------------------+

Queuing: KMessageWidgets should not stack on each others. Assuming KMessageWidget A is visible, if KMessageWidget B is created, it should wait until A has been visible for at least 3 seconds and replace it.

Widget API

  • Properties
    • tone (negative, neutral, positive)
    • text
    • shape (line, rectangle)
    • showCloseButton
  • Methods
    • addAction(QAction*)
    • setMainWidget() low-level method to replace the existing text + buttons layout with a custom widget. Setting text and adding actions with addAction() should be preferred whenever possible.

To be refined

  • MessageBox-like Icon on the left?
  • Integration with KNotification?
  • Definition of a container to implement queuing rules?
  • Using a different widget for the "find/replace" use-case?