Plasma/Active/mail: Difference between revisions

From KDE Community Wiki
< Plasma‎ | Active
No edit summary
(Major revision after Heiko's comments and additions)
Line 1: Line 1:
C=core (basic features; program does not work without)
= Requirements and Supported User Actions for KMail Active =


A=alternate (performance features)
== Requirements ==
 
C=core/basic features; program does not work without
 
P=performance features: Not absolutely necessary, but create the impression of a good product


Z=buzz features, not expected by default
Z=buzz features, not expected by default
Line 7: Line 11:
E=exotic (not really needed?)
E=exotic (not really needed?)


Safety / Capabilities
=== Safety / Capabilities ===
*(C) Support multiple accounts
*(C) Support multiple accounts
*(C) Support standard protocols (IMAP, POP3, SMTP)
*(C) Support standard protocols (IMAP, POP3, SMTP)
*(?) Supports authentication via NTLM (Microsoft Windows) and GSSAPI (Kerberos)
*(?) Supports authentication via NTLM (Microsoft Windows) and GSSAPI (Kerberos) <span style="color:blue">Thomas: We should support these only if are essential for many business users.</spam>
*(?) Supports plain text and secure logins, using SSL and TLS.  
*(C) Supports plain text and secure logins, using SSL and TLS.  
*(C → A) Native support for inline OpenPGP, PGP/MIME, and S/MIME encryption
*(P) Native support for inline OpenPGP, PGP/MIME, and S/MIME encryption
*(A) Filter spam (Integration with popular spam checkers, e.g. SpamAssassin, Bogofilter, etc.)
*(P) Filter spam (Integration with popular spam checkers, e.g. SpamAssassin, Bogofilter, etc.)
*(A) Provide user defined rules
*(P) Provide user defined rules
*(E) Provide synchronization features (e.g. owncloud)
*(E) Provide synchronization features (e.g. owncloud)
Receive / Read
=== Receive / Read ===
*(C) Notification for new messages
*(C) Notification for new messages
*(C) Show text emails  
*(C) Show text emails  
*(A) Show html emails  
*(P) Show html emails  
*(Z) Show extended html stuff (background)  
*(Z) Show extended html stuff (background)  
*(A) Replace text smilies with emoticons  
*(P) Replace text smilies with emoticons  
*(A) Convert html 2 text (ability to display plain text only from an HTML mail)
*(P) Convert html 2 text (ability to display plain text only from an HTML mail)
*(C) Handle long lists of receivers (collapse/expand, cut, …)
*(C) Handle long lists of receivers (collapse/expand, cut, …)
*(A) Show details (email header)
*(P) Show details (email header)
Send / Compose
=== Send / Compose ===
*(C) Create new text mail
*(C) Create new text mail
*(A) Create new html mail
*(P) Create new html mail
*(C) Select To/CC/BCC
*(C) Select To/CC/BCC
*(C) Reply to Sender/All (What is reply to list?)
*(C) Reply to Sender/All (What is reply to list?)<span style="color:blue">list=mailing list. Not important for most business users, very important for people heavily involved in open source. I'll add a new P requirement for it ;)</span>
*(P) Reply to mailing list
*(C) Forward message
*(C) Forward message
*(A) Send as urgent
*(P) Send as urgent
*(A) Request disposition notification
*(P) Request disposition notification
*(C → A) Insert signature
*(P) Insert signature
*(C → A) Attach file(s)
*(P) Attach file(s)
*(Z) Compress attachments
*(Z) Compress attachments
*(C → Z) Check spelling  (as-you-type and on demand)
*(P) Check spelling  (as-you-type and on demand)<span style="color:blue">Thomas: I'd consider it a performance feature. It's not essential, but pretty much expected nowadays I guess.</span>
Organize / View
=== Organize / View ===
*(C) Integration of international character sets
*(C) Integration of international character sets
*(C → A) Mark item (read/unread, important, tag (SLC)…)  
*(P) Mark item (read/unread, important, tag (SLC)…)  
*(Z) Link item (task, appointment, notes)
*(Z) Link item (task, appointment, notes)
*(Z) Add sender(s) to contacts  
*(Z) Add sender(s) to contacts  
*(A) Create folders; Move items to folders
*(P) Create folders; Move items to folders
*(A) Search for items (find specific old mail)
*(P) Search for items (find specific old mail)
*(C) Show tree of folders
*(C) Show tree of folders
*(C) Move to trash
*(C) Move to trash
*(Z → A) Create/Apply filters
*(P) Create/Apply filters
*(C) Sort items by property (time, sender, receiver...)
*(C) Sort items by property (time, sender, receiver...)
*(E) Import/Export emails
*(E) Import/Export emails
Configure
=== Configuration ===
*(C) Create/Modify signature  
*(C) Create/Modify signature  
*(Z) Provide alternate views (compact list, ...)
*(Z) Provide alternate views (compact list, ...)
*tbd.  
*tbd.  
Usability
=== Usability ===
*(C) Make reading/writing efficient (minimize actions/clicks to start a function)
*(C) Make reading/writing efficient (minimize actions/clicks to start a function)
*(C) Provide adequate feedback
*(C) Provide adequate feedback
Line 59: Line 64:
*(C) Provide support (tooltips on demand)
*(C) Provide support (tooltips on demand)
*(C) Implement controls according system standard and organize workflow conform to user expectations
*(C) Implement controls according system standard and organize workflow conform to user expectations
*(A) Provide individualization features
*(P) Provide individualization features
*(E) Let users control the processing (speed, direction, etc.)
*(E) Let users control the processing (speed, direction, etc.)
User Experience
=== User Experience ===
*(?) Use standard themes
*(?) Use standard themes <span style="color:blue">Thomas: If you mean that the UI adapts to the general theme used by the system than yes, absolutely, but I think we get that for free</span>
*(?) Design fancy dialogs
*(?) Design fancy dialogs <span style="color:blue">Thomas: If by that you mean "Make the UI look different to the rest of the system" then I'm against it</span>
*tbd.
*tbd.
<hr>
= Usecases =


== Mail ==
== User Actions ==


=== Core ===
=== Common ===
main usecases that deserve a prominent place in the UI
Actions that are part of regular usage of Kmail Active (if they are available), and thus should be presented prominently in the UI


* read up on new/important emails and decide what to do with them quickly
* read up on new/important emails and decide what to do with them quickly
Line 81: Line 84:
** select to/cc/bcc
** select to/cc/bcc
** spellcheck (instant)
** spellcheck (instant)
** attach file
* switch accounts
** insert signature
* open favorite folder
** encrypt/sign (only if PGP/SMIME is configured)
* multiple accounts


=== Alternate ===
=== Uncommon ===
other usecases we want to enable
Actions which are not performed every day, but more often than rarely. Should be accessible when needed, but may take a few steps to execute


* find specific old mail to look up some information
* find specific old mail to look up some information
** browse the folder hierarchy
** Add a folder to favorite folders
* manage email  
* manage email  
** move to any folder
** move to any folder
** tag (SLC)
** tag (SLC)
During email creation:
* send as urgent
* send as urgent
* request disposition notification
* request disposition notification
* attach file
* switch signature insertion on/off
* encrypt/sign (only if PGP/SMIME is configured)
=== Rare ===
Actions that are performed only occasionally or only once at initial setup. Can be in separate UIs
* setup / configure
**account(s)
**encryption
**signature
**spellchecker


=== Exotic ===
* create / manage filters
rare usecases that we might want to support if they don't interfere with the overall interaction design.
* create / manage / apply filters
* import / export mail
* import / export mail
== Other ==


=== SLC ===
=== SLC ===
Action that can be performed via SLC and thus do not need to be part of the main UI
* PIM interaction  
* PIM interaction  
** add to address book  
** add to address book  
Line 110: Line 125:
** connect to Activity
** connect to Activity
*print mail ??
*print mail ??
* tag
* tag
 
=== Settings ===
* setup / configure
**account(s)
**encryption
**signature
**spellchecker
 
== unclassified ==
 
* automatic archiving
* folder based workflows

Revision as of 17:02, 25 May 2013

Requirements and Supported User Actions for KMail Active

Requirements

C=core/basic features; program does not work without

P=performance features: Not absolutely necessary, but create the impression of a good product

Z=buzz features, not expected by default

E=exotic (not really needed?)

Safety / Capabilities

  • (C) Support multiple accounts
  • (C) Support standard protocols (IMAP, POP3, SMTP)
  • (?) Supports authentication via NTLM (Microsoft Windows) and GSSAPI (Kerberos) Thomas: We should support these only if are essential for many business users.</spam>
  • (C) Supports plain text and secure logins, using SSL and TLS.
  • (P) Native support for inline OpenPGP, PGP/MIME, and S/MIME encryption
  • (P) Filter spam (Integration with popular spam checkers, e.g. SpamAssassin, Bogofilter, etc.)
  • (P) Provide user defined rules
  • (E) Provide synchronization features (e.g. owncloud)

Receive / Read

  • (C) Notification for new messages
  • (C) Show text emails
  • (P) Show html emails
  • (Z) Show extended html stuff (background)
  • (P) Replace text smilies with emoticons
  • (P) Convert html 2 text (ability to display plain text only from an HTML mail)
  • (C) Handle long lists of receivers (collapse/expand, cut, …)
  • (P) Show details (email header)

Send / Compose

  • (C) Create new text mail
  • (P) Create new html mail
  • (C) Select To/CC/BCC
  • (C) Reply to Sender/All (What is reply to list?)list=mailing list. Not important for most business users, very important for people heavily involved in open source. I'll add a new P requirement for it ;)
  • (P) Reply to mailing list
  • (C) Forward message
  • (P) Send as urgent
  • (P) Request disposition notification
  • (P) Insert signature
  • (P) Attach file(s)
  • (Z) Compress attachments
  • (P) Check spelling (as-you-type and on demand)Thomas: I'd consider it a performance feature. It's not essential, but pretty much expected nowadays I guess.

Organize / View

  • (C) Integration of international character sets
  • (P) Mark item (read/unread, important, tag (SLC)…)
  • (Z) Link item (task, appointment, notes)
  • (Z) Add sender(s) to contacts
  • (P) Create folders; Move items to folders
  • (P) Search for items (find specific old mail)
  • (C) Show tree of folders
  • (C) Move to trash
  • (P) Create/Apply filters
  • (C) Sort items by property (time, sender, receiver...)
  • (E) Import/Export emails

Configuration

  • (C) Create/Modify signature
  • (Z) Provide alternate views (compact list, ...)
  • tbd.

Usability

  • (C) Make reading/writing efficient (minimize actions/clicks to start a function)
  • (C) Provide adequate feedback
  • (C) Check user input and let user confirm when necessary
  • (C) Provide support (tooltips on demand)
  • (C) Implement controls according system standard and organize workflow conform to user expectations
  • (P) Provide individualization features
  • (E) Let users control the processing (speed, direction, etc.)

User Experience

  • (?) Use standard themes Thomas: If you mean that the UI adapts to the general theme used by the system than yes, absolutely, but I think we get that for free
  • (?) Design fancy dialogs Thomas: If by that you mean "Make the UI look different to the rest of the system" then I'm against it
  • tbd.

User Actions

Common

Actions that are part of regular usage of Kmail Active (if they are available), and thus should be presented prominently in the UI

  • read up on new/important emails and decide what to do with them quickly
    • reply to sender/all/list
    • forward
    • move to trash / a favorite folder
    • mark as important/unread
  • write new emails from scratch
    • select to/cc/bcc
    • spellcheck (instant)
  • switch accounts
  • open favorite folder

Uncommon

Actions which are not performed every day, but more often than rarely. Should be accessible when needed, but may take a few steps to execute

  • find specific old mail to look up some information
    • browse the folder hierarchy
    • Add a folder to favorite folders
  • manage email
    • move to any folder
    • tag (SLC)


During email creation:

  • send as urgent
  • request disposition notification
  • attach file
  • switch signature insertion on/off
  • encrypt/sign (only if PGP/SMIME is configured)

Rare

Actions that are performed only occasionally or only once at initial setup. Can be in separate UIs

  • setup / configure
    • account(s)
    • encryption
    • signature
    • spellchecker
  • create / manage filters
  • import / export mail

SLC

Action that can be performed via SLC and thus do not need to be part of the main UI

  • PIM interaction
    • add to address book
    • create event from mail
    • create task from mail
    • connect to Activity
  • print mail ??
  • tag