Project Elegance/Notification Study: Difference between revisions

From KDE Community Wiki
(Add template to Notifications page)
 
No edit summary
 
(14 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This page provides a template for Project [[Elegance]] proposals.
{{Proposed_deletion|reason=this project seems dead, and didn't get a long way in the first place, by the looks of these pages}}


Parts marked with * are mandatory!
IN PROGRESS


= Summary/Abstract* =
= Summary =
Give a short intro to the problem/idea - 2 or 3 sentences. People should be able to have an idea of what you are trying to do and recognize your project by reading this.
 
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  
! Creation Date  
| Creation date of the proposal
| 28-September-2010
|-
|-
! Status
! Status
| Current status of the proposal
| Proposal
|-
|-
! Maintainers
! Maintainers
| The project maintainers and their contact information. Indicate Primary Lead/Contact person
| Celeste Lyn Paul (seele) - Design
Matthew Rogers (mattr) - Development
|-
|-
|}
|}


= Description* =
= Description & Related Work =
This is a detailed description of your proposal. Include as much detail as possible. The following questions should be answerable by anyone who reads this:
== 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).


* What is the problem this project tries to solve?
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.
* What is the scope of this project (how big or small is the effect?)
* Who are the primary users and how will they benefit?
* How is this solution better than other solutions (what we have now and how other projects solve the problem)
* How will it effect other parts of KDE?


== Related Work ==
=== KDE Notification Study ===
References to related research or other projects that will back up your proposal.
 
* If this is a list of links to publications, they should be referenced in the detailed description
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.
* Alternatively, this can be an annotated citation list (short 2-3 word summary of relevant conclusion of each paper), or a literature review summary itself (with relevant citations listed at the end)
 
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 ==
== Design ==
Discussion and details of the design of the proposal. This includes workflows, UI mockups, graphics, interface guidelines, interface proposals, usability testing and results, etc.


Detailed description of user requirements and needs will also go here, including any workflow or UI details specific to user groups.
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 [http://community.kde.org/images.community/b/b2/Notification_study_spec.pdf Notification Study Specification]


== Implementation ==
== Implementation ==
Discussion and details on implementation details.


= Affected Modules* =
Project repository: [git://git.kde.org/notificationsurvey.git]
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.
 
= Affected Modules =


===Primary Modules===
===Primary Modules===
{|
{| style="width: 100%"
|-  
|-  
! Name of module  
! scope="col" width="40%" | Name of module  
! Description of changes
! Description of changes
|-
|-
| KHotNewStuff
| Notification Survey Applet
| Default icon changed from favicon to khns
| Provides ability to collect survey data
|}
|}


===Secondary Modules===
===Secondary Modules===
{|
None.
|-
! Name of module
! Description of changes
|-
| KHangMan
| Icon on Get New Puzzles button should be updated to use khns icon
|}


= Project Timeline* =
= Project Timeline =
This section is the project plan for the proposal. It includes a project timeline (a record of when certain milestones are met, or expected to be met), information on who is working on what, changes in status including an indication of final implementation and release.


These items may be low-level implementation details or high-level project goals (such as "Complete User Survey of KHNS Use").


== TODO ==
== TODO ==
Line 74: Line 83:
! Milestone name
! Milestone name
! Milestone description
! Milestone description
! Assigned to
! style="white-space:nowrap" | Assigned to
! Status
! Status
|-
|-
| Update KHNS Class
| Notification Study Software
| Update KHNS class to call khns icon
| Create survey UI for the notification survey
| Jeremy Whiting
| mattr
| In Progress
| In Progress
|}
|}


== Completed ==
== Completed ==
{|
{| style="width: 100%"
|-
|-
! Milestone name
! Milestone name
! Milestone description
! Milestone description
! Assigned to
! Assigned to
| Status
! Status
|-
|-
| Create KHNS Icon
| Need a dedicated icon for KHNS
| Nuno Pinhero
| Completed (12-Nov-2009)
|}
|}




{{Note|Please use the talk page to discuss this proposal.}}
{{Note|Please use the talk page to discuss this proposal.}}

Latest revision as of 14:18, 9 March 2016

Proposed for Deletion

This page has been proposed for deletion for the following reason:

this project seems dead, and didn't get a long way in the first place, by the looks of these pages

Please use the discussion section of this page to voice your opinion on this.

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

Primary Modules

Name of module Description of changes
Notification Survey Applet Provides ability to collect survey data

Secondary Modules

None.

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


Note

Please use the talk page to discuss this proposal.