By Here at Honeybadger we're big fans of eating our own dog food. We were all contractors when we started Honeybadger, and still use our own software regularly to monitor our personal projects. One of the main benefits of this is that it's not difficult to see the product from our customer's perspectives; we are the customer!
One thing that we've wanted for some time is a better way to gather feedback from our clients when they encounter an error. Picture this scenario: You're hired to deliver an MVP in 2 months, and are half-way to your deadline. In the true spirit of agile development, you deployed a skeleton Rails app on day 2, and have been shipping ever since. Your client is a hands-on sort of person, and wants to help test each latest build as it's deployed. Naturally, you installed Honeybadger in order to monitor exceptions in your staging environment, which is great because you sound really smart when your client calls to explain that your code doesn't work.
But why must they call at all? Don't get me wrong, I'm all about user feedback.Honeybadger reports are indispensable, but it also helps to know what the _user's_intent was when they encountered an error. But an exception is not a case which warrants a phone call, at least not from the user. And sometimes it's difficult (if not impossible) to explain to the user what an exception is, much less what caused it.
So how did we build the best of both worlds?
Instead of a phone call from your client every time they find a bug, imagine that Honeybadger could display a form on the actual error page which is displayed when the error occurs:
Instead of picking up the phone or firing off an email, your client now has an immediate outlet to report what their intent was and what they experienced instead. Once submitting the feedback form, they can rest assured that you're on top of the issue.
If a different user encounters the same bug, they can also submit their own feedback. Back in Honeybadger, we display all of the feedback from your users inline in the comments section of your error reports:
This is something which I found invaluable immediately after shipping it. I literally deployed the feature, installed the new gem on a client project, and had several feedback submissions the same day; which is awesome, because it kept several emails from hitting my already crowded inbox \m/.
Oh, and if you do want to be notified when a user sends feedback, you can by enabling comment notifications in your project settings.
Installing the feedback form is simple — just add a single HTML comment to yourpublic/500.html file in Rails. For full instructions, check out the documentation.Not using Honeybadger yet? Start tracking errors today!
