Tag Archives: App Challenge

Finalizing Error Management Design

How long does it take me to come up with a design? Well, as you can see in the gap in posts, the answer seems to be a week. I started the week with the totally wrong assumption that designing the error management page would take me two days tops.

Design is not a quick process

Early Bootstrap Mockup
Early Bootstrap Mockup

After two days, I hadn’t even wrapped my head around the direction I wanted to go with the design. I was still exploring patterns, how other products used them and which ones were relevant to Helthe.

While I had some hand drawn sketches to work with, transforming those sketches into mockups was not easy at all in the end. I am not a quick with CSS as I am with regular code.

False needs

In my previous post, I discussed the needs of the user. After some reflection, I concluded that there were three needs that were not needed currently. So I made some additional cuts to simplify things. Those were:

  • 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 be able to comment on the error.

All these features are collaborative in nature, but as I sketched and mocked them I had difficulty seeing their need in the current product state. I had a friend do a quick review of an early sketch and he also told me that they were not needed at the moment.

The main issue is that collaboration needs like commenting and assignment are only useful to the user if they integrate with the tools that the user is using. The user does not need another application to check for comments, assignments, etc. It needs to integrate with the tools the user is already using.

Could I be that tool? Maybe, but it seems premature to think so. It can be added to the product at a later date.

So I decided to cut the features till I could think of them in the context of the 3rd party integrations.

Navigation requires its own scope

This is something else I realized along the way. I was working on mocking up the navigation (like a breadcrumb), but I found it really hard to do so without having multiple pieces to put together.

You have to really think about the user flow and how users will be moving from screen to screen. With just the error screen, I had a really hard time visualizing it.

This might also be due to inexperience on my part, but I felt better moving it into its own scope to be dealt with later.

Current Design

View Error : Helthe
Near Final Mockup

As of this afternoon, this is the current design of the error management page. I want to share some of the design decisions that I took. As I mentioned in my notes previously, there’s two jobs that this screen needs to accomplish. Those were:

  1. 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.
  2. 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.


The header section is dedicated almost exclusively to the first job. At a quick glance, the user is able to see all the important information about the error.

The user can do the quick operations that I had highlighted in my notes and he also has access to the big picture details.

Using colours

The most important design challenge for me was that I wanted the user to be able to determine the error severity very quickly. Early on in the design process, I decided to use a colour scheme to communicate that.

When a user lands on the page, he immediately sees the coloured border next to the error text. The error text is the first thing the user will read, but the eye is quickly drawn to the coloured label right underneath the error text. That label tells the user the error type.

As I was iterating, I wanted to reinforce this colour scheme further and I thought that the tabs was a place to do it. This adds a reminder as the user is scanning down to the different sections. It also keeps the whole palette consistent for the page.

The result is that, when the user lands on the page, he will immediately know the severity of the error in question.




I renamed the ignore error button to snooze. That was suggested to me by a friend during an initial review. I liked the term a lot. Snooze implies a temporary respite before you become alerted again which is really what users want to do usually.

What I also liked was that snooze is based on rules which can be very open-ended. As the product involves, it could be a timeframe (a week), till the next deploy (once I track deploys) or indefinitely.

Overall, it’s a small detail, but one that I felt brought a lot of clarity to the user.

Recent activity

Sentry has this and I thought it was very important to incorporate it. When someone comes here, they need to know what has been happening quickly. Recent activity is a pattern that allows for this. On top of that, it is very flexible. Since anything can be an activity.

Bottom section

I did some work on the bottom section. The summary has roughly all the information you would need, but will probably need a bit more polish once I started wiring the application code. I am not 100% sure that the “reported at” timestamp should just be in the table.

I didn’t style the trace or any of the other tabs yet which might require a bit of time, but I am going to wait a see what the data and the output looks like to begin.

Off to the lower layers

Now that the majority of the design is wrapped off, I am moving on to the lower layers to finish off the error management scope.

Notes on error management design

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:

  1. 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
  2. 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!

A week later

A week ago, I was writing a post about getting back into the habit of things with building Helthe. I was leveraging my increased motivation since I got sick in October to participate in the Week of Hustle that was organized by Justin Jackson for our group JFDI. The goal was for us to get a small product built-in a week or finish something concrete on a product you had been working on. I chose the later.

How did I do on the roadmap

On that same day, I also posted a roadmap with what I was planning to do during the week. I thought it might be useful to review it and share my thoughts on it.

1. You sign up for an account.

I completed the sign up page and login page on the first day and that was great, but my fears ended up justified. I did not end up spending time on the design aspect of things and because of that I cannot show the work I did.

2. You can create a project with its own API key.

I had code ready for this already, but I made sure thing worked so this part was easy, but very necessary.

3. You get a PHP library (on GitHub) that you can add to your project for tracking application errors.

This probably should have been split in two since there was also the API code to fix, but I got it all done in the same day. Helthe now has a basic library up on Github which can be used by early adopters as I get all the integrations up and running.

4. Errors get sent back to Helthe and it determines if it is a new error or an existing error.

This was also an important feature to get to work. You don’t want users to get spammed with every error otherwise you are not better than a hacked solution. So I have all the errors grouped up by message currently. I plan on having something more elaborate in the future.

5. You receive an email whenever a new error is created.

I ended up spending two days on this when I expected to spend maybe a couple of hours. As I explained, I ran into problems left and right. From setting up Mandrill to getting emails to display properly, I never got a real break to get this done reasonably quickly. I did end up getting it done though and it looked  great!

6. Update my marketing site to reflect that we entered a stage where you can test.

There is a new small update in the FAQ about being passed my november 4th launch date, but that’s all I could get up without a design pass on the actual front end.

7. Refine my marketing message following a campfire talk with Andy Parkinson.

I am very happy with the changes to the marketing site in respect to this. I did a big blog post about it last night with the resulting text change.

Design should have been on the roadmap

This is a big one I think. I wish there was more to show on the Helthe website if I had planned for it. I didn’t really think of it at the time though. I figured I could do both, but, as I discovered doing the email design, it can be very time-consuming to do simple things even with frameworks.

Blogging has been a big winner

I managed to blog for 6 out of the 8 days and I have to say that felt great. Writing was easier because I was writing about what I was doing, but in the larger scheme of things it didn’t really affect viewership at all. That was expected because I wasn’t really writing to help readers, but for myself about myself (me! me! me!). It should be about them and not be.

That said, I do find that it was useful for rebuilding the habit, but it is still very time-consuming for me. I wonder if I will be able to be as prolific as I move towards writing useful content for readers or able to maintain the habit.

Overall this was a success

I feel very good about how the week turned out. I work very well when I feel accountable to someone, but it’s hard feeling accountable to anyone when you work alone with no clients. This helped tremendously.

With this, I am closer to having something to sell, but, while I worked and got stuff done, I am definitely not closer to getting the marketing piece working (like getting people to my site,etc). This can be discouraging, but there are so many pieces to this that I am glad I got some sorted out. Marketing is always a challenge when you have nothing much to leverage.

What’s next?

I have to figure out how I can turn this into a framework I can work with continuously. I hope to come back in a day or two with some ideas. Till then, you can keep checking up here or you can subscribe to my mailing list.

Why it is only PHP

Looking for an update on what I did yesterday? Well I did NOTHING. I felt quite bad about it, but if there’s something my gym habit has taught me is that you can’t be perfect every day. But today I was ready to get things done!

It is worth noting that it is the last day to work on your roadmap for Week of Hustle. Tomorrow, you have to ship things out so I was determined to get through the rest of it.

A week ago by the campfire

Last sunday following the publication of my roadmap, I had a discussion in the JFDI campfire chat room with Andy Parkinson about Helthe and what the service was. The important part of the conversation is found below.

Campfire ChatThe main takeaway that I took is that I needed to really double down on what it meant to the user to have a solution for PHP. The other popular languages at the moment tend to have one dominant framework (Django for Python and Rails for Ruby), but that’s not the case for PHP and that needs to be better explained.

PHP is 80% of the web

PHP is so prevalent for many reasons, but the important point is that PHP is represented by more than just a framework. It is used to run web dominant CMSes and E-Commerce platforms as well as various frameworks so it’s not realistic to expect one PHP library to be adequate for each. I definitely don’t believe it is. And that’s where I draw my line.

WordPress is the best example of that. I already did an exhaustive analysis of WordPress errors and how they are handled. A regular PHP library would only capture a fraction of the problems that could happen within a WordPress installation. It’s especially complex because WordPress is so defensive in its way of handling problems.

I don’t have an issue with that per say because it makes WordPress very user-friendly which is one of its core values. It does, however, put an increased burden on the programmer who is looking for the cause of problems. This can lead to dangerous practices like cowboy coding because it’s just so hard to know what is going on at times.

We meet again copywriting

With all these ideas swirling in my head, I set to work modifying my marketing site copy.

Now I have a confession to make, whenever I have to do copywriting, I want to go hide somewhere and forget about it. It’s one of the many skills I need to build, but it’s definitely the one that makes me feel the clumsiest. I feel like Fry (Futurama) trying to play the holophor for Leela.

You have well constructed ideas in your head, but you have to put them out there and hope they get shared properly.

Before Screenshot

I wanted to modify the section that discussed the more PHP centric benefits for the user to be more descriptive and explain some of the  issues I brought up earlier in the post. After 4 hours, I got a result I was satisfied with.

After Screenshot
After Screenshot

I do actually think it is an improvement over the old version. I didn’t add the logos because I couldn’t make them look good on the page with the responsive layout so I kept them out. I am curious to know if logos are something you would consider important so let me know in the comments.

I did a small modification to the FAQ to say that the deadline had passed, but I was still working on it.

This goes up tomorrow

I’ll be pushing all this out tomorrow, but will be keeping the work I did on the account creation and API disabled. I’ll be writing up my thoughts on the experience as well.

Keep up with my progress

I have been bad and haven’t sent emails everyday as I should, this is the next thing I want to spend time tackling. I’ll be sending a detailed recap at the end of the project to my mailing list. You can subscribe here. You will also get all the info when things are ready for testing.

An email adventure

The past two days I have been knee-deep in email! Yesterday, I started by writing some basic documentation for Helthe Monitor which was on my to-do after my previous post.

Hooking up Mandrill

As I mentioned in the roadmap, Mandrill is the transactional email service that I chose for this project. I did extensive research on all the providers (Sendgrid, Postmark, Mailgun, etc.) when I was working on the previous Helthe version. I chose them due to their excellent pricing overall and their free tier. On top of that, they’re a spin-off company of Mailchimp which has excellent knowledge of email infrastructure.

So having done this before, I figured this was going to be quite easy  to do. The coding part didn’t take very long since I had done it before, but Symfony wasn’t sending the emails to Mandrill. Symfony would say that the email was sent, but it never made it to Mandrill. The rest of the day was spent troubleshooting the issue unsuccessfully.

I ended up solving the issue today by using SSL for the SMTP, but I never quite figured out why it did not work unencrypted. Once that was done, I made sure emails were only sent for new errors and not every time an error is logged.

Holy email styling batman!

For the rest of the day, I decided to tackle styling my emails. As I said Monday, I wasn’t sure I would have time for it, but I decided to work on the emails today. I had never done email styling before, but, armed with this sweet post from customer.io, I thought I could get it to work quickly. It seemed that way at first. My first version looked great. You can see an example below.

But then I saw it in Gmail. It looked horrid (I didn’t put some robot email skull monster screenshot for nothing!). None of the stylings were showing and I didn’t know why. I looked up some stack overflow questions, but nothing useful came out of it. I decided to try out a white color scheme and things looked better in Gmail, but I wanted black dammit!

Screen Shot 2013-11-14 at 10.26.35 PM

Eventually, I mentioned my problems in the JFDI campfire chat room and Justin pointed me towards this great tool from Mailchimp (!!!) called the Automatic CSS Inliner Tool which converted all the styles into inline ones BECAUSE APPARENTLY IT MATTERS. I love you email, but as if having to use tables wasn’t insulting enough already.

As a final note, I plan on using the first one, but if you like second one more. Let me know!

2 days left

We’re down to two days left now. I did a pretty good dent on that roadmap already. I think the main goal is to fix up the marketing site as was originally planned. It’s outdated so I would like to update it. Fix up some of the copywriting to reflect some discussions I have had the past week.

If I have time, I will do more design work on the frontend of the application so that I can put some sweet sweet screenshots! Nothing says progress like screenshots!

Keep up with my progress

I have been bad and haven’t sent emails everyday as I should, but I’ll be sending updates (I swear!) by the end of the project to my mailing list. You can subscribe here and you will get all the info when things are ready for testing.


Very productive day today. I have done a good dent in the roadmap. I didn’t get to write the essays I wanted to do. I should have time to tackle that tomorrow.

Working API

As I mentioned yesterday, my API code was full a bit of mess as I was working on building a custom Symfony Firewall for authenticating a user using an API key (either as a query or HTTP header). I had worked on having it decoupled so I could open-source the bundle for it eventually.

So all that was cleaned up and committed today. I then proceeded to fix my code so errors would be grouped together when multiple ones are submitted. Following that I got all errors submitted assigned to a project using the projects API key.

Helthe Monitor

As I was fixing my API code, I was also working on Monitor, the basic PHP library for Helthe. I got the initial commit up on Github. At the moment, it is a simple wrapper around Guzzle, a PHP library to build HTTP clients. A very useful library if you are looking to work with or build a service with HTTP requests. I still need to write the documentation which I neglected to do, but I plan on doing it tomorrow.

So things are moving along quite well, a lot of elements of the roadmap are far ahead. I don’t have a sexy  UI shot to show yet, but below is a database screenshot showing test errors.

Screen Shot 2013-11-12 at 11.27.56 PM

Keep up with my progress

As always, I’ll be sending updates of what is going on with the project to my mailing list. You can subscribe here!

That first commit

My first day is drawing to a close and I have committed a working signup page and login page. It’s not a bad outcome, but I feel I should be even further ahead.

Still fighting my enemy

I had a lot of code cleanup to do because I was in the middle of converting my code to be more DDD-friendly and SOLID before this started. This kind of premature optimization always ends up bogging me down.

It’s always a real challenge to balance learning how to do new things and being productive.

Tomorrow I plan on tackling the Helthe API code that is also in its own transitionary phase and get it in working order. I have a couple of small essays I would like to publish as well. We’ll see how all this goes!

Design worries

I don’t have a screenshot to share today because I am just using auto-generated HTML directly. It’s functional, but that’s it. I might try to take a look at making things prettier tomorrow as well if I finish early (ha!).

It dawns on me I should have probably put a line item for design. I am not a designer. I did a great job in a short time for my current marketing site, but I think this might end up being pretty time-consuming overall. I will probably just scramble to dress everything up and do a proper design pass after the week is over.

Keep up with my progress

As always, I’ll be sending updates of what is going on with the project to my mailing list. You can subscribe here!


I am spending my first day trying to stabilize my code since I was working on a few things before the Week of Hustle started. Our goal for today was to submit a roadmap to plan for the next few days.

What’s coming ahead

Here is the plan for the next week:

  1. You sign up for an account.
  2. You can create a project with its own API key.
  3. You get a PHP library (on GitHub) that you can add to your project for tracking application errors.
  4. Errors get sent back to Helthe and it determines if it is a new error or an existing error.
  5. You receive an email whenever a new error is created.
  6. Update my marketing site to reflect that we entered a stage where you can test.
  7. Refine my marketing message following a campfire talk with Andy Parkinson.

Technology Stack

For people wondering about what I have been using to build Helthe. Here is the list:

Symfony feels a bit limiting for pumping out something quickly like this, but I am not planning on changing. This is only a first step and Helthe is a service that will be maintained for years.

Keep up with my progress

I’ll be sending daily updates of what is going on with the project to my mailing list. You can subscribe here !

Getting back into it

It’s been a month and a half since my last blog post. Personal illness got in the way of things for most of October and I have been slowly getting back into it over the past week. My pre-order deadline for Helthe has come and gone and I have gone back to working on the project daily. Now, I am building back my blogging habit.

Welcome to the hustle

Just before getting sick, I joined  a community of bootstrappers called JFDI which is pretty great for people working alone in their basement like myself. We’re running an experiment this week called Week of Hustle where a group of us will try to build a small product in a week. You can also use this to finish a project that you have been stagnating on. That’s what I’ll be doing.

I had to answer some preliminary questions yesterday which I want to share.

  • What is your personal goal? Get Helthe into user testable stages and accepting early adopters.
  • Who is your audience? PHP Developers (like myself) who care about application errors and their impact on clients.
  • What pain are you trying to solve? In PHP, it’s really hard to find errors when things are not working. Often, you just get a white screen. If I can save developers 1 hour of debugging a month, the product pays itself.

While things have been very good this past week, being sick and not working for a month is a pretty daunting hurdle to get over. This will get me back into the flow of things even more and help me get me over my #1 enemy.

Code is my enemy

The weakness is your love of creation. You love to write clean, tested, scalable, extensible, beautiful code.

Jason Cohen

I love coding. I think myself a craftsman more than anything else and I want to be proud of what I built. This is great, but it also causes some serious problem. I am not shipping in a timely manner. This is exacerbated by working alone and setting your own rules and timelines.

So because I have a limited timeframe, I will be forced to limit my scope heavily. I will have daily goals to meet and be accountable for to help me focus and not get sidetracked.

This isn’t a new weakness or something I have just come aware of. I would say I have struggled with it since I started a year and a half ago, but it’s one I keep working on (like my blogging habit).

Speaking of blogging habit

I’ll be blogging everyday during this. Shorter posts (like this one) and maybe multiple times a day about various Helthe topics (roadmap, ideal customer, design, etc) relevant to the work I am doing this week. So stay tuned!

Want to follow my progress? I’ll be sending daily updates of what is going on with the project to my mailing list. You can subscribe here !

A plugin for a rainy day

Moving ahead from our last post, I want to present the beta version of the Helthe WordPress Error Monitoring plugin (available here). The overall goal of the plugin is to offer relevant error monitoring for your production WordPress site.

A debugging tale

When debugging WordPress (or any other programming problem for that matter), what do you usually do? You start using your badass Google-fu to find a solution and, when that fails, you post on support forums, WordPress Answers (Stack Overflow) or another medium, but I am getting ahead of myself.

Before that you need to know what to look for and that’s usually where the problem lies especially with WordPress. Unless you’re dealing with a fatal error (White Screen of Death), WordPress is generally pretty silent about issues. This is by design.

Great experience for the users. Hell for supporting them.

This is plugin is a serious attempt at helping you with that. I have already done a good effort to capture a lot of the known errors (and some new ones as well), but having you use it will help me find additional ways to help you (and find bugs) when you need it the most.

What are you getting?

I don’t plan on doing a feature by feature explanation, but I wanted to highlight a few things that I hope you will find useful.

Leveraging existing plugins

The first thing I did is consolidate some of the good stuff from the Core Control plugin and Deprecated Log Notices which do not seem to be actively worked on anymore. Those were the two plugins I knew that helped for specific problems (let me know if you know others!).

With this, you’ll know if you’re using deprecated functions or calling functions wrong. However, the more interesting element is tracking errors from the HTTP API. Without diving to deep into it, the HTTP API is used by WordPress to handle communications with other web services. This includes wp-cron and errors with the API can be one of the reasons why your cron tasks (like schedule posts) do not run.

Termination Errors

This has the potential to be very useful. Have you ever had AJAX errors with WordPress? Those can be really annoying to solve since you can’t see the output. Well now, anytime WordPress terminates with an error, it will get logged in your error log. I haven’t seen anything like this before so I am hoping that this turns out to be very useful for you.

Image Editor Errors

Another common problem you can encounter is the image editor not working because you’re missing libraries for example. This is a scenario where you really won’t know unless you spend quite a bit of time poking around.

Admin Bar Support

Wondering if there were errors when your page rendered, you’ll be able to see all the errors that were logged by the plugin in the admin bar. This is just for site administrators.

And more!

There’s quite a few more things already under the hood and, as far as I know, there’s nothing another error plugin does that isn’t covered with this current beta version. I am not satisfied yet though. The same way you think of Akismet as your default spam solution, I  want this to be a must-have for any serious WordPress professional.

I can’t do that without your help and feedback. Try it out and create issues whenever you have a production (or even development) problem that wasn’t caught by the plugin and caused you serious pain.

This is available to you for free

You won’t need to sign up for anything and you will get all the errors logged in the PHP error log. I think for this to be truly great for the community, all the features need to be available to everyone.

Where do Helthe fit in this?

Right now the plugin only writes to the PHP error log. When Helthe gets closer to the beta phase, there will be an option to add an API key that will let errors be sent to the service. The purpose of Helthe is to make error monitoring and management more convenient for you so if you’re ok with looking through your error logs then you won’t need anything else to be functional.

As always, feel free to leave a comment below or discuss on Hacker News.

P.S. If you’d like to keep up to date with my progress with Helthe, leave your email below!