Mostly a rant on a few bad experiences that could have been prevented in real life if engineers did a good job instead of a good enough job. We have no oath to "Do no harm!" So, we take license to ship whatever. This is bad for humans.
- Wow look new technology, pumping up tires is way better now
- Not so much, they added software to the process, oops
- Pumps and deflates automatically to read pressure
- What could go wrong?
I'll show you what went wrong…
- Wow look software to manange dental practices cool
- Helps patient care?
- We ship "good enough" software
- We target the Web cause it runs everywhere
- What could go wrong?
Let me tell you about how to waterboard dental patients, while you work around the UI bug that prevents dental assistants from inputing data.
- Everying is so modern now at the dentist, what is missing?
- I can't spit
- I can't sit up
- No one is helping me while I choke
- Feels more like torture than I remember it
Hey we need to ship this project now, what can we shave off?
- A feature or two that is just too time consuming
- Automated tests cause that takes effort and is not easy
Oh let's add some new features now that beta is in production
- No time for tests
- Code gets messy
- OK to ship with edge cases
We get used to shipping software with known issues, our bad.
We can do better, right?
- Add tests at the start, during and/or at the end of sprint
- Capure requirments and edge cases better in wiki, surface the 'Why' our trackers mostly have the "How"
- Definition of Done (acceptance criteria) to include known edge cases
- Identify must have for release
- Include path for users to recover from unsupported edge cases
- For error conditions that are relevant to the user, never silently fail.
- Logs, dashboard in splunk
- Post client errors, log and add to a dashboard
- Use Ember.onerror
- Standard error responses
An example from ember-jsonapi-resources addon:
Ultimately, it depends on you to analyze and respect your user's situation, mental model, and cognitive load.
I do have a few universal suggestions though.
- Don't use
window.alert. Avoid modals. - Display errors in context.
- Don't stuff everything into a growl, out of context with where the problem is.
- Dismissing errors
- Don't hide messages after a time without a way to retrieve them.
- Do automatically hide messages as the user moves on with their life.
- Offer inline retry and help.
- You can spend engineering time to think of all the edge cases, or support time to field the rare errors.
