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.
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.
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.
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
In Progress / Assigned On Hold / Blocked Reopen Reopen Accept Enter Resolution Approve Resolution Enter Resolution New / Con rmed Confirm Email API Web Entry
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
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.