Death By a Hundred Paper Cuts

Registered by Rick Spencer on 2009-05-13

Project to dramatically improve the user experience of Ubuntu by:
 * The design team identifies 100 bugs that appear relatively easy to fix but that negatively impact the Ux
 * Channeling resources to fixing those bugs
 * Measuring and celebrating progress towards fixing those bugs
 * Tracking impact of the fixes in upstreams over successive versions

Blueprint information

Status:
Complete
Approver:
Martin Pitt
Priority:
Undefined
Drafter:
Ivanka Majic
Direction:
Needs approval
Assignee:
Ivanka Majic
Definition:
Obsolete
Series goal:
None
Implementation:
Not started
Milestone target:
None
Completed by
Martin Pitt on 2009-12-03

Related branches

Sprints

Whiteboard

Some people have already started collecting these little 'paper cuts' at https://wiki.ubuntu.com/LittleDetails

Xd, what a name

What does 'Xd, what a name' mean?

Thanks for the LittleDetails link - I hope Rick can help us come up with a way to decide which of these things turn out to be paper cuts and which aren't.

- Replace notepad icon in Nautilus: there is a little icon in Nautilus that looks like a piece of paper and a pencil. The tool tip is: "toggle between button and text-based location bar" - in usability testing people think it will let them write a document; we need a new icon.

- Highlight recently installed applications

- In Firefox the Back arrow is effectively disabled after the home button is used.

- The Offline page in Firefox needs work.

- If folder icon changed then change everywhere

- 'home' folder vs 'username' folder

 * what is a paper cut?
  * A design defect
  * noticeable, not necessiarily blocking, but could be
  * requires little technical effort to fix
 * Why fix them?
  * Fixing 100 small things is 100 fewer things to complain about
  * Act of improving those things will help teach the design team how best to support the dev process to fix and avoid issues
  * Aesthetic usability effect
  * Appearance of quality engineering
  * because we care
 * How - proposal, heart of the discussion
  * design team own list
  * design team gets input for list items
  * engineers can push back if fix is not in fact trivial
   * What's the definition of trivial?
    * time based?
    * low risk?
    * known solution?
  * track
   * progress
   * upstream uptake
   * stickiness over versions

(?)

Work Items