Thursday, July 25, 2013

Being a forklift operator possibly leads to car accidents. An example of bad UI design.

I ran into this comment the other day on the Internets:
If you think that driving a car with reversed turn signal and wiper levers is bad, try driving a fork lift which slams into reverse every time you hit what would normally be the left turn signal.

That is not the scary part. I have known numerous forklift drivers that got so used to using the lever to switch from forward to reverse throughout the day, that at the end of their shift they would get in their stick shift car with it in first gear, start the car, turn on the left turn signal, look over their shoulder, release the clutch and drive into the car in front of them.

Life Lesson: Never park directly in front of a fork lift driver.
I'm sure there is a reason for the lever to be conveniently placed at that location, but, if the bigger picture is taken into account, this is a pretty good case of UI design that results in expensive damage to property. Car insurance providers should take a look at this scenario to see how common that combination actually is (assuming that comment isn't a troll disseminating bad information). If it turns out to be a legit issue, then raise car insurance rates for that specific combination to some astronomical cost (stick shift car + forklift operator = very high insurance rate, automatic car + forklift operator = normal rate). Or, better yet, fix forklifts so that it isn't a problem regardless of the type of car that a forklift operator drives.

The real takeaway for us developers: Just because a user interface streamlines one specific process doesn't mean that it won't cause other, more serious problems. A responsible, competent developer will take ownership of a problem and fix it. The irresponsible, incompetent developer will just ignore the problem and point the finger of blame toward anyone else but themselves.

Saturday, July 13, 2013

We've been doing multithreaded and asynchronous UI programming all wrong!

About a year ago, Microsoft released version 4.5 of the .Net Framework to the world. No one really cared much but every programmer out there should. Why? Lurking in the shadows of that release was THE solution to our multithreading woes. If you've ever done multithreaded programming, you know three things:

1) Multithreading is painful.
2) Multithreading is messy.
3) Multithreading is painful.

Multithreading is even harder in a GUI environment because most GUI libraries will crash (and crash the whole application too) if a programmer tries to do operations on the UI from another thread. So, the programmer ends up having to write a ton of plumbing to get back onto the UI thread after completing a multithreaded operation to do UI stuff. In addition, multithreaded programming requires thinking outside of how programs and programmers are really wired to think: That is, we think sequentially.

The solution that needs to be ported to every programming language we care about (including C/C++) is async/await. You don't need to know C# to really understand the importance of having these keywords at our disposal:

Easy Asynchrony with C#: No more callbacks!

Watch the video. Yes, it is painful to watch someone write code. But watch it anyway until you understand what async/await are about (the first 30 minutes should be sufficient). Once you see him switch to async/await and comprehend what's going on, your brain will have a happy moment. Well, my brain did anyway. But don't try to imagine what is going on behind the scenes to transform that code into a multithreading wonder yet, at the same time, have sequential, clean, and readable code because then your brain will just explode. My brain exploded trying to think about the behind-the-scenes stuff. Just accept that these keywords do magical things. The await/async keywords are pretty magical, but you know what? We shouldn't care. What we should care about is when our favorite programming languages are going to get these two keywords. If you think about how these keywords work, it really requires fundamental language changes, not some drop-in library where we're only slightly shielded from the painfulness.

I don't normally get excited about programming language keywords. But I've been doing multithreaded programming for a long time and know how hard it is for a lot of programmers to grasp even the basics because it requires a fundamental change to their thinking. The async/await keywords wrap up multithreading in a nice, neat package with a bow on it. Huge game changer. Every programming language that supports multithreading and I/O completion objects need to stop messing around with synchronization objects and adopt these keywords now.