I'm needy... and I need you to get to the point faster.

Today, Apple and IBM announced a big deal to bring iOS devices to "the enterprise" using IBM services and analytics. They will jointly create more than 100 apps for the iPhone and iPad, focusing on everything from security to device management, with IBM giving 100,000 personnel to the effort.

All of that information can be found in Apple and IBM Team Up to Push iOS in the Enterprise by Arik Hesseldahl on Re/Code. That's also pretty much the only substantive content in that 800 word article, and it was buried eight paragraphs deep. There's a bit more about the effects on the stock market, but not enough to be useful to anyone in the market. This is sad. I can condense this article, and many others, into two sentences of actual content, the rest is just fluff and bullshit. I can't wait for the day when we get back to real reporting and away from this airy page-view stuff.

A good example of getting right at to the core of a topic: What We Talk About When We Talk About Iraq and Syria from Caerus Associates.

Rules of Thumb for HTTP Verbs

Web services are woderful things. But, have you ever found yourself designing a RESTful API and wondering which verb to use? Here are some general rules of thumb...

  • Are you providing the data and the logic? Use GET.
  • Are they providing the data and you're providing the logic? Use POST.
  • Are they just adding data to your collection? Use PUT.
  • Are they trying to delete data from your collection? You should check their damn permissions, if they're cool use DELETE.

You can even mix and match these verbs on the same endpoint. I use a lot of Node.js at work, and I prefer to use Express to map different logic to different verbs on an endpoint. Your preferences may change base don your platform, but those guidelines will stay the same.

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.