In my previous post, I described the process I would be taking to continue the development of Helthe. We concluded that the scope of the project that would offer the largest learning opportunity would be the error management piece. The past two days I have been working on design notes for the error details screen that follow partly Ryan Singer’s post on design process. I am editing them and sharing them with you.
What is error management?
One thing that I didn’t do is define what is error management. In the context of Helthe, error management is what allows the user to interact with the collected errors and work with them. The main application screen involved is the error details screen. On the application layer, it involves grouping similar errors together in a useful manner.
Why are they here?
The first thing I did is try to think of all the situation that would lead the user to this part of the system. I came up with the following:
- Most users will come because they got an alert from the system
- New Error Alert
- Error Assignment Alert
- Some users will come from the dashboard
- Some users were browsing all the project errors
What are the jobs(s)?
What does the error details screen help with? What is its job? What does it help the user with? This is probably the most important screen for the user. Helthe is supposed to give a lot of value to the user here so what are the jobs that the user expects help with.
I came to the conclusion that when a user comes to this screen, he is here for two different jobs:
- He got a new alert and wants to get further details so that he can properly evaluate its severity and possibly assign it to a team member
- He got assigned the error (or came on his own) and is here to solve it. He needs to have all the information required to reproduce it so that it can be fixed.
Defining the value for each job
The two jobs are very specific, but there is overlap. I’ll be attempting to define the needs of the user for each job so that product gives the best value possible in each case.
What does job #1 need?
Job #1 describes what is expected of the error details page when some one lands on it. A user that just received an alert needs a good summary with the important information readily available. While the summary needs to be useful to both jobs, users doing job #1 are the ones that need to be 100% satisfied by it.
So a user clicks on the alert email (from desktop or phone), he gets to the error details. What capabilities does he need to do his job? I have tried to order them in order of importance.
- He needs to be able to see the status of the error (Resolved or Unresolved)
- He needs to be able to determine the severity of the error
- He needs to be able to see the error text
- He needs to be able to determine if this error is new or if it is a regression
- He needs to be able to ignore the error because it can’t be fixed now
- He needs to be able to see if that error is assigned to anyone
- He needs to be able to assign the error to a team member
- He needs to know when it happened (First Seen/Last Seen)
This is quite a few items, but the user needs to be able to discern all of them easily at a glance even on a mobile device.
What does job #2 need?
So a user that is looking to solve an error, what does he need to do his job? A lot of what was described in Job #1 is useful initially, but he needs to have additional heavy-duty capabilities to actually resolve the error.
- He needs to know the URL and HTTP request method that caused the error
- He needs to know where the error happened (File and Line No)
- He needs to be able to view and navigate between similar errors
- He needs to be able to access specific error details
- Trace
- Environment Variables
- Application Context (e.g. User Logged In, Controller, Plugins)
- Browser Details
- He needs to be able to mark an error as resolved
- He needs to be able to comment on the error
Design in the works
I am working on the design of the page. I hope to be able to share the result and how this influenced it soon.
If you’ve liked what I have been writing and want to hear more, you can subscribe to my mailing list here! I have been writing a lot so I am still figuring out how to approach things for the list. You can also keep checking the blog every day if that’s your thing!