Applied Research and Application Design

The Problem

A lot of applied, academic research focuses on designing and producing tools that not only answer research questions, but to be used by sponsors in some form to make their lives/work better. These apps often have a huge, glaring problem: they look and respond like shit. Worse han that, very few folks on the development team are willing to admit that these issues exist, much less make any steps forward to change them, and it's frustrating. And this problem isn't just in the UI/UX realm, it's often (even worse) in the backend.

In short: too much of applied, academic research in visualization doesn't care about user experience.

Now why is this a problem you ask? I don't know about you but I have pretty much lost all patience with technology. I expect to be able to look at an app and understand how the basics of the interface work in less than 30 seconds, and when I touch/click/type I expect the app to respond almost instantly. Obviously this is a shade harsh, maybe even unfair, and I do give web apps some leeway on response because they have to go through so many pipes, but I think this is a standard most people (should) have now.

The Solution

The solution to this (because, as they say, don't complain unless you have a solution) is simple: care, a lot, about the way you app looks and how people use it.

You're Not Ruthless Enough

In February, Chris Parker had a great post entitled You're Not Ruthless Enough, where he talked about writing good code. This post really hit home with me, and unfortunately I see these same issues in academic projects every day. The biggest problem is that developers of these projects really just aren't ruthless enough.

Be ruthless. Lose sleep over the fact that you could do better. Okay, maybe not that, but you get what I'm saying. At the very least don't settle for "good enough", or a quick fix. Find a good solution the first time and you won't be coming back to this issue a year, six months, or even a few days later.

Some Rules to Follow

  1. Communicate. It sounds really simple, but when someone suggests something, and especially when they find a bug, listen to them. Don't just shrug it off as "it's fine the way it is" because it probably isn't, otherwise the person talking to you wouldn't be.
  2. Don't go backward. Never let your app slow down, not even by a millisecond. If it does slow down, revert immediately and figure out what went wrong.
  3. Iterate. With each iteration you should try to make the code more readable or the interface friendlier, without breaking rule #1.
  4. Don't be afraid to start over. At some point most projects enter a state where continuing on will only make things worse, and the only way to move forward is to start from scratch.
  5. Have code reviews, but make them fun. Literally the best thing that ever happened at my last job was the day we found out we could link to GIFs in code review comments. Overnight it went from a dreaded, painful mess to a funny, lighthearted thing we all looked forward to (no, I'm not joking). These also keep you ruthless and prolongs the life of the project.
  6. Documentation is your friend. Your code should be documented, as should every interaction in your interface. That being said, 80% of the code and interface should be so obvious that they document themselves.
  7. Remember Nielsen's Heuristics. They're pretty good, and you can find them here. Some are harder to enforce than others, but most are simple and damn good design practices.
  8. Get user feedback. Whether it's through bug reports, email, or formal user studies, collect user feedback, I promise it will make you better.
  9. When in doubt, go back and re-read #1-#8.

Alright, I'm done ranting. Now go make good apps.