October 02, 2007
Figure 1 There are clearly aspects of issue submission that would be equally relevant and intuitive in an email interface.
Figure 2 It’s not a precise mapping, and some fields are excluded. However, it’s close enough that email is still a first class citizen.
Beyond the Browser
One of the key requirements for creating any kind of issue tracker is making it easy to get data into the system. While the browser is the primary interface, I felt email also had to be a first class citizen for issue submission.The browser interface is the ideal input method, but it’s important to realize that many of the people potentially submitting issues would be more comfortable sending e-mails. Generally, e-mail is easier than visiting a web site in a browser, potentially logging in, navigating to the right location, and then submitting the issue. It’s not necessarily night and day easier, but it’s easier. The challenge, however, was making sure that the email experience was as natural and intuitive as the browser interface.
Figure 1 There are clearly aspects of issue submission that would be equally relevant and intuitive in an email interface.
It wasn’t hard to conceptualize, but it wasn’t necessarily obvious either. I logically mapped the different facets of a basic email to the relevant inputs in the browser interface and ended up with an almost perfect, and more importantly, intuitive, map. Submitting issues via e-mail isn’t quite as rich, but it doesn’t need to be. It’s setup to simply be a quick and natural way for someone to get an issue into the system.
Figure 2 It’s not a precise mapping, and some fields are excluded. However, it’s close enough that email is still a first class citizen.
- File Uploads = Attachments
- Project = To Field
- Assignee = CC Field
- Subject = Subject Line
- Description = Body
- Priority = Priority
I took some liberties with the flexibility. Most likely there will effectively be five priority options in the system, and email priorities only allow for three, so those won’t map exactly. However, I’m pretty confident that one of my two very simple ideas will work.
The other area where I took some liberty is assignment and additional notifications. Sometimes, it’s helpful to immediately get more than one person involved in the discussion, particularly on conceptual issues. As a result, I wanted to make sure that the carbon copy field could still be used. As a result, I have to differentiate between who is being notified and who the issue should actually be assigned to. So, to keep things simple, by default, the system will assign the issue to the first person in the CC list. Also, when an issue is received via e-mail, it’s important that the system doesn’t send out duplicate notifications.
Summary
These are all little things that work together to ensure that submitting an issue via email is as natural and seamless as it can be. It seems like an almost trivial detail, but it’s easy to forget that interaction design doesn’t stop at the browser. RSS, APIs, and email are all potential interaction points, and they each have facets that can be modified to ensure a consistent experience within the system. They’re a different type of interaction, but that doesn’t mean they should be afterthoughts. And finally, I haven’t implemented this yet. So, there will inevitably be some tweaks, but I thought the concept was worth sharing as is.
Hi. I’m Garrett Dimon, a freelance designer/developer in Dallas, TX. This is my site about people, design, and technology. I designed and built a bug and issue tracking application called Sifter. Still have questions? Feel free to .
Comments
Comments are here for discussion related to this article. If you have a comment or question not related to the article, please . Please try to keep things constructive and on-topic. Comments that are not constructive or on-topic will be deleted.
Duplicate Tickets, or Responding to tickets
October 02, 2007 at 12:34 PM by Josh WalshSimply curious… how are you, or have you even thought about it yet, going to handle responding to email notifications and duplicate issues?
I’m fairly certain that duplicates would simply be duplicated. There’s not much of a realistic tech-solution to that, at least not that’s worth doing.
I’m assuming you’re going to pipe email coming back into the correct ticket, but the formatting rules seem to always get confusing. Even 37 Signals couldn’t get that totally right with Highrise.
Just curious.
Shaking...
October 02, 2007 at 04:33 PM by Tim Van DammeGarret,
I’m still shaking from seeing your presentation about the tracker (PDF-version, that is). So much wisdom in a digital file, awesome!
You’re going for gold with this app, I promise!
E-mail priorities
October 03, 2007 at 07:12 AM by Nicholas H.Garret,
I too am astonished by your wisdom. And you read Tufte’s work! (A+)
I’m as excited about your tracker as I was for the iPhone. No kidding.
In the interest of making your tracker as good as possible, I thought you should know that there are five e-mail priorities.
They are numbered from 1 to 5, where 1 is the highest priority, 3 is no particular priority and 5 is the lowest priority.
Apple Mail only gives its users access to priorities 1, 3 and 5.
Cheers,
Nicholas
Feedback
October 03, 2007 at 07:42 AM by Garrett DimonJosh - Duplicate issues are handled by simply referencing an issue number in the comments of an issue. ex. “#123” would be automatically-linked to that issue. Then, it’s up to the openers and assignees to determine if any information needs to be added to the primary issue and/or which issue to close. I do have some more ideas I really want to explore there though.
Regarding replying to e-mail, I’m honestly planning on leaving that out for now. I’m going to initially handle it the same way Basecamp does by simply providing a link directly to the issue. I hope to eventually enable the conversation to happen purely by e-mail, but it’s not a phase 1 thing.
Tim - Thanks for the encouragement.
Nicholas - Thanks for pointing that out! That’s good to hear, and interestingly enough, I was going to treat the priorities as 1, 3, and 5 in Tracker. So you’d only be able to assign Highest, Normal, and Lowest priority via e-mail. Really, I’m not too worried about it, because priority will usually need to be reviewed anyways since some people will invariably have a tendency to always use the highest priority.
To / Cc
May 29, 2008 at 04:27 PM by Christian RomneyIt would make more sense to make the assignee be in the to: field. You could send the message to the tracker and the assignee and still be able to CC anyone who you might need to notify or who might be interested.
Assignee in To Field
June 16, 2008 at 12:01 PM by Brad FultsI agree that the To field should have the assignee and anyone else who should be CC’d on the ticket would go in the CC field.
Great work.