Death By a Hundred Paper Cuts
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
- Started by
- Completed by
- Martin Pitt
Whiteboard
Some people have already started collecting these little 'paper cuts' at https:/
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
