Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Application Interface Design - Webmaster Jam Session - 2007

Garrett Dimon
September 21, 2007

Application Interface Design - Webmaster Jam Session - 2007

A super-deep dive into the process for designing a hosted bug and issue tracking application by exploring the evolution of the ideas from sketches to full-fidelity mockups.

Garrett Dimon

September 21, 2007
Tweet

More Decks by Garrett Dimon

Other Decks in Design

Transcript

  1. What’s the application do? 1. Track issues. 2. Track software

    development bugs. 3. Enables and encourages resolutions to the issues and bugs.
  2. Ground rules... 1. Stop me at any time for questions

    or discussion. 2. No formal usability testing. It’s based on my experience. 3. It’s not finished. There are mistakes. Things will change. 4. Let’s focus on “why” and “how”, not “what”. 5. Your mileage may vary.
  3. Peter Morville The design of good houses requires an understanding

    of both the construction materials and the behavior of real humans. “ ”
  4. Status Resolution Assignee Opener Creation Date Due Date Category Type

    Release Priority Severity Impact LOE (Estimated) LOE (Actual) Browser/OS Relationships Redundant with the resolving comment. Keep it. Captured implicitly. Captured implicitly. Always “yesterday”. Priority should dictate this. Keep it. Overkill. Handle with categories. Soon, but not yet. Keep it. Factor it into Priority. Factor it into Priority. Creates overhead and doesn’t belong. Creates overhead and doesn’t belong. Doesn’t apply to issues. Capture in comments.
  5. Paul Graham A few years ago I read an article

    in which a car magazine modified the “sports” model of some production car to get the fastest possible standing quarter mile. You know how they did it? They cut off all the crap the manufacturer had bolted onto the car to make it look fast. “ ” Foreword from Founders at Work
  6. Received / Uncon rmed Resolved / Retest Closed Open /

    In Progress / Assigned On Hold / Blocked Reopen Reopen Accept Enter Resolution Approve Resolution Enter Resolution New / Con rmed Confirm Email API Web Entry
  7. Resolved / Retest Closed Open On Hold / Blocked Reopen

    Reopen Enter Resolution Approve Resolution Enter Resolution Received / Uncon rmed Accept New / Con rmed Confirm A B C Email API Web Entry
  8. Resolved Closed Open On Hold / Blocked Reopen Reopen Enter

    Resolution Approve Resolution Enter Resolution D Email API Web Entry E
  9. Resolved Closed Open Reopen Reopen Enter Resolution Approve Resolution Email

    API Web Entry With each arrow, we’re doing one or more of the following 1. Comment 2. Update Status 3. Attach a File 4. Reassign 5. Update Priority/Category Comment Comment
  10. The word “Active” is subtle but important. The count is

    an informational and motivational reminder. “Empty” tabs receive a lower visual priority. Closed issues are out of the way in their own tab.
  11. n Smallest Effective Difference Edward Tufte Make all visual distinctions

    as subtle as possible, but still clear and effective.
  12. System (No context for tabs.) New Issue (Green = Open

    Issue) Project (Tabs organizing issues.) View Issue (Emphasis on issue status.)
  13. [email protected] A B C D E F A B C

    D E F C The browser isn’t the only interface to design for.
  14. http://garrettdimon.com/archives/2007/8/22/the_tracker_dashboard/ Subtle variances in typography create emphasis. Responsibility comes first.

    New Issues are one click away. Inactive projects still readily accessible. Overall status tells a story. Recent activity is the pulse.
  15. n Conway’s Law It is a consequence of the fact

    that two software modules A and B cannot interface correctly with each other unless the design and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.