Project Elegance/Notification Study: Difference between revisions
(Add survey applet information) |
m (fix the header) |
||
Line 104: | Line 104: | ||
! Milestone description | ! Milestone description | ||
! Assigned to | ! Assigned to | ||
! Status | |||
|- | |- | ||
|} | |} |
Revision as of 03:06, 2 October 2010
IN PROGRESS
Summary
Notifications are an important feature that help users maintain awareness of multiple systems, but also the root of a major annoyance on the desktop. The proposed Elegance project describes a small user study to help collect data and understand what types of notifications are better than others.
This software will listen for social communication notifications through DBUS. For a small percentage of these types of notifications the notification study software will ask the user to submit a diary entry. This diary entry is supported by an on-screen survey that will pop up. After a period of time, this data will be sent to the project maintainers to analyze learn more about notifications.
Creation Date | 28-September-2010 |
---|---|
Status | Proposal |
Maintainers | Celeste Lyn Paul (seele) - Design
Matthew Rogers (mattr) - Development |
Description & Related Work
Introduction
A notification is a useful service provided by the desktop system to help users maintain awareness of events and information while they work. A notification can be visual, auditory, or haptic feedback that gains the user's attention, the capacity of a user's concentration for an activity and awareness of external events, and informs them of a new event or information. This information commonly comes in the form of a message displayed on the screen in a variety of ways, either by itself or in combination with an auditory or haptic cue. Notifications on a desktop system inform users of useful information such as receiving a new email message, the critical status of a laptop battery, the availability of security or software updates, or that a meeting is scheduled in 15 minutes.
Because information delivered by a notification is not usually a part of the user's primary task, often the notification must interrupt the user from their current task to gain their attention and deliver the new information. An interruption may become a disruption, a delay in the continuity of the primary task, depending on the time away from the task, the complexity of the primary or interruptive task, information delivered in the interruption, and a number of other factors. Interruptions that become disruptions may have a negative impact on the user because interruptions can affect user performance on their primary task and user satisfaction of the notification experience as a whole.
Factors the research literature has identified as having an impact on notification use and acceptance vary. Examples of these factors range from details about the message the notifications is about (application, author, length of message), the display of the notification (size of display, method for displaying, content of notification), to what the user is doing (current task, number of applications open, other distractions).
Knowing when a user can be interrupted is a complicated task. We can't determine usefulness for notifications by rules such as, "all notifications from Author X" or "all notifications from Application Y". There is no single factor that indicates whether the notification is useful or not. The literature has found that two and three combined factors can make reasonable predictions if a notification is useful, but implementing software rules for that many degrees of freedom becomes too complex.
KDE Notification Study
This Elegance project aims to take a small peek into this notification design problem. One of the things we want to learn is what types of notifications are more useful than others. We will do this by collecting data about users' notification experiences in an attempt to identify pairs of factors that indicate more positive experiences over negative ones. An example relationship we might fight would be that notifications for messages from certain authors may be useful only when the user isn't in a mentally intensive task, such as debugging. Another example relationship might be that notifications of certain Facebook and Twitter messages might be interesting if the user if he had recently responded to a message from the user sending the message.
By knowing these "useful factors", we may be able to improve notifications through both system behavior and user interface.
Scope
There are a variety of events users can be notified of. We will focus only on notifications from social communication. These types of notifications are most common and most relevant to users.
Also, for Phase 1 of this study, we will only look at small groups of people at a time, such as developers on a single project. This will help us refine our study software and analysis methods for a larger study.
Design
The proposed study is a computer-supported diary study. A diary study is a research method that hopes to capture information about events that happen sporadically over a long period of time. Users "keep a diary" of events that are being researched, and those events can later be analyzed by researchers. A diary study is used most often when a traditional laboratory study cannot produce useful and relevant data. However, a drawback to diary studies is that they can be biased towards the extremes. Users may have a tendency to record very good and very bad events, but not the events in the middle. This leaves a lot of data unrecorded.
Our solution is to "support" users in their diary by creating software that will ask them to create a diary entry for random events. The Notification Study software will do three things:
- Watch DBUS and log notification messages from all social communication apps
- Watch DBUS and launch the Diary Survey for a small percent of social communication notifications
- For each Diary Survey, record a screenshot of the user's desktop
More detailed information can be found in the Notification Study Specification
Implementation
Project repository: [[1]]
Affected Modules*
Which parts of KDE's software are affected? Which should definitely be part of the implementation process? Provide a short description here and then list out the primary and secondary modules in detail. This may be related to scope: if so, be sure to explain.
Primary Modules
Name of module | Description of changes |
---|---|
Notification Survey Applet | Provides ability to collect survey data |
Secondary Modules
Name of module | Description of changes |
---|---|
KHangMan | Icon on Get New Puzzles button should be updated to use khns icon |
Project Timeline*
TODO
Milestone name | Milestone description | Assigned to | Status |
---|---|---|---|
Notification Study Software | Create survey UI for the notification survey | mattr | In Progress |
Completed
Milestone name | Milestone description | Assigned to | Status |
---|