Category Archives: Rant

Bad UX and Stockholm Syndrome

When we’re thinking about the impact of good and bad UX on the experience of using software there are a large group of people who are often overlooked. They’re not the discretionary consumers, who may be put off completing a purchase by requiring an extra click or form field, but a those who are forced to use in-house developed software required to complete their day-to-day work.

These apps are often clunky, with awkward UX, interaction foibles and bugs. They’ve quite possibly been “”designed”” by programmers, rather than UX specialists. But people have no choice but to use them day-in and day-out. So how is this likely to affect their attitude to the application?

An interaction can be so bad, so awkward to execute, that it feels almost painful. Maybe not when performed in isolation, but when repeated over and over it can become mentally (and even physically) wearing.

The application has them captive, and sets about bending them to its will.

But then a strange thing happens. The users start to think it’s OK.

Maybe it doesn’t feel quite as bad as it used to. It’s not really so awkward that it works that way. In fact, it feels right to do it this way.

Actually, why would it be done any other way!?

Wait a second, what just happened?

Despite the terrible treatment meted out, and partly due to the captor showing some small kindness – giving the ability to do their job, however awkwardly – the hostages have fallen in love with the application, their cruel, heartless captor.
Continue reading Bad UX and Stockholm Syndrome

Heisenmemory

I am sick of non-deterministic memory management. So sick. This was the big promise of .NET wasn’t it, way back in the 00s? No more having to worry about reference counting, double-frees or leaks. Well all we’ve done is switched it for worrying about event handlers, garbage collector pauses and weak dictionaries.

If you don’t have to worry about memory in .NET applications, then why are there so many commercial tools for solving memory-related problems? I’m starting to yearn for the days of being able to put an instance on the stack for the length of a curly-bracketed scope, and knowing that after that, it’s gone.
Continue reading Heisenmemory

Dad Gaming

imageI have recently entered a new, strange and exciting phase of my gaming life: Dad Gaming.

To put this in context, I’ve been playing games for a long time. I Mutant Camel’d through primary school, Sonic’d through the student days, PaRappa’d through my early career and Mario’d into marriage.

But at all of those points I was playing with peers. Consenting adults, fully aware of gaming tropes and vernacular, able to hold down several buttons and a trigger simultaneously while loosing off a round of sniper fire.

Nowadays, my gaming partners are 2 girls under 10 and my outlook and attitude to gaming has completely changed. Vast swathes of the electronic landscape are off limits, and to be honest, I’m enjoying the change of scenery.

Continue reading Dad Gaming

C++: The oldest new kid on the block

TastyNobody could have failed to notice the recent resurgence of interest in the C++ programming language. In particular, the recent Build conference was the most we’ve seen Microsoft talking about C++ for several years. Why has a language that’s been languishing in the “prehistoric irrelevance” category for so long suddenly come back into vogue?
Continue reading C++: The oldest new kid on the block

London Underground UI Fail

I mentioned this on Twitter the other day, but I was so incensed I just had to scribble out a blog post too. It’s a classic case of replacing a traditional (in this case paper-based) “interface” with an electronic one, and in the process failing to translate the fundamental functionality that made the original system useful.

How can you screw-up creating an electronic version of an existing sign?
Continue reading London Underground UI Fail

Programming is like a bad analogy

The joy of programming is hard for anyone to precisely define. At least, it’s hard for programmers to define, and seeing as nobody else understands what the hell it is anyway, that’s pretty much the same thing. However a few people on the interweb have tried quite hard to describe just what the feeling of developing software is by comparing it to things in “the real world”.

A quick google reveals some of the funny, interesting and downright weird things that people have compared programming to. Let’s take a closer look at some of them…
Continue reading Programming is like a bad analogy

TwitterVision: How Twitter transformed TV

TwitterTVFor a long time now, TV executives have bemoaned the lack of “event TV”. Modern broadcast television is a fractured ghost of its previous self. People’s attention is no longer focused in a tight beam on 3 channels; we have millions of videos at a click on YouTube, full-length TV shows and films on iTunes, hundreds of channels on satellite and cable. That means there’s no longer a significant section of society sharing the experience of a television show and discussing it the next day at school/the office water-cooler.

But what they seem to have missed is that something very different, but equally significant, has replaced it: the instantaneously-shared TV experience, enabled by Twitter. With the omnipresence of laptops, broadband and Twitter, the sofa’s now connected. It’s possible to sit at home on your own and discuss, berate and dissect whatever’s on RIGHT NOW.
Continue reading TwitterVision: How Twitter transformed TV

The 7 signs your UI was created by a programmer

Do you suspect a programmer may have put together the terrible user interface on that “enterprise” software you’re forced to use every day? There are some give-away indicators. Look out for them in your software, hunt down the developer and force them to read a book about user interface design. If you’re suitably senior, force them to a) improve it, or even better b) get someone with real UI experience to fix it.

1. Exclamation marks in dialog box messages
Look, it’s probably the 50th time I’ve seen this message today. The fact that this application “Cannot connect to database!” is no longer a surprise. You may have noticed that most professional software uses a neutral tone for its communication with the user. Try that. Also:
1a. Double negatives in confirmation dialogs
“Are you sure you don’t want to lose your changes?” Err… what? No. I mean YES. Oh sh*t. Any dialog that requires you to stop and try to parse the question in order to work out if you’re about to destroy several hours of work is not doing its job. It’s getting in the way of you doing your job. In fact, convoluted messages are such a serious issue that Microsoft even tried to help developers to help their users by introducing a whole new kind of dialog box in Vista: the question/task dialog. Good luck with that.

2. No tab ordering defined\mouse only navigation
Because no-one’s ever going to use the keyboard to navigate the zillion controls in your data entry app, are they? This one actually surprises me, because I’d have thought that developers would’ve needed to navigate quickly through the application while they’re writing it. Well, that doesn’t seem to be the case. Pretty much all commercial apps are good counter examples. I don’t mean to hold up Microsoft Office as a paragon of UI virtue, but they definitely do the “alternate way of navigating everything” thing well. Everything you need can be reached by both keyboard and mouse. Unplug your mouse and try that with your favourite piece of in-house software and see how you get on.

groups3. Group boxes around everything
This is a bit of a WinForms specific one. The clue is in the name: group boxes are for grouping logically related controls, not for providing a kewl recessed border around every single one of the controls in your dialog. Don’t kid yourself that this is doing anything other than using up some valuable screen real estate. (See if you can spot another pet peeve in the example dialog, too).

icon_editor4. Icons created in the IDE
Look, Visual Studio’s a really good integrated development environment, but it ain’t no Photoshop. Don’t try and use it to create icons. And while you’re at it, please don’t make icons consisting solely of the name of your application (inevitably an acronym) in pixel font and primary colours. Oh, and don’t just steal various icons from another application, unless you’re going to steal the whole lot; one of the key visual aspects of a good UI is consistency. Mixing your hand-drawn 4-bit icons with the glorious 32-bit shiny ones you borrowed is going to be jarring. In fact, why not go the whole way and get someone who can actually draw to create your icons for you? After all, you wouldn’t have someone who wasn’t a programmer writing the code, would you…?

5. Data grids
Otherwise known as the “Excel is the pinnacle of user interface design” disease. Break the habit. Generally, the more types of controls that are embedded in your grid, the less likely that it’s the right kind of interface paradigm. Yeah, I’m looking at you, person embedding a calendar control, drop down box, graph, slider and checkbox in each row of a data grid. And whatever your 3rd-party grid provider of choice says, it’s not going to do screen redraw performance any good, either.

6. Not implemented message boxes
Ahh, the GUI equivalent of source code TODO comments. Of course, it’s an in-house software give-away; no commercial (desktop) software would be brazen enough to ship with bits of functionality dangling from the stumps of buttons and menu items. Would it? Feel free to provide counter-examples if you have them.

dialog_dialog7. Excessive use of dialog boxes
Warning: dialog boxes are considered harmful (to usability). They’re the equivalent of restraining your user by force and preventing her from moving until she answers your question. That might be OK for matters of life or death (i.e. data loss), but not otherwise. Every time you find yourself about to add a new message box, stop, take a deep breath and consider whether it’s really necessary.

So, if you’re a victim or one, many, or all of these user interface faux pas, all I can say is: sorry. I’ve been responsible for doing at least one of these things myself over the years. Consider this post repentance for my user interface sins.

Static libraries are Evil

In my opinion.

Why? Well, because it’s too easy to use them as an excuse for not defining your shared library interfaces properly.

The reason this is on my mind recently is that several hundred, yes, you heard that right, several hundred DLLs have been released by my group over the last, ooh, 10 years or so. They are all still in use. Each of them has burned into it a copy of the library that deals with interfacing with Excel. That means each of these has it’s own little internal copy of the current state-of-the-art. The problem with that is; the state-of-the-art moves on. And how do you go about updating the DLLs that are already in production? You have to re-release them. In an environment where thes DLLs are used for marking the profit and loss on a large derivatives trading book, that’s not a small undertaking. And it’s made worse if, say the DLL in question was last released with a different version of the compiler.

My approach would be to refactor this shared static library (.lib) into a stand-alone DLL.

At this point, people start saying “oh, but then you’ve got a single point of failure, if you release a broken version of that DLL, everything will stop working!”. Not exactly a compelling argument. If the functionality of the DLL is well defined, and there are well known entry points it should be easy to put together a comprehensive black-box test suite. In fact we already do that with all our other DLLs (COM servers). The fact that this shared library *isn’t* a DLL has meant that it’s fallen through the testing cracks; another good reason to refactor it.

The internal interface to the shared library is already relatively well defined. It has a set of header files that define all of the functions and classes that are consumed by others. It’s a relatively small step to compile it as a DLL, rather than a static library. The problem then becomes one of maintenance, dealing with the inevitable changes to the external interface in a backwardly compatible way.

And that’s the problem. It requires some effort. Elsewhere in our codebase we use COM as a magic cure-all for avoiding having to deal with versioning: interface immutability rules. All interfaces are public, no published interface ever changes, object identity is based purely on interfaces supported. If you haven’t got these crutches to rely on, then you have to enforce the rules yourself, which can be both logistically and technically difficult when you’re dealing with C++.

But it’s not impossible. And I really think it would be better than having hundreds of DLLs all containing subtley different versions of the same code, and being unable to change behaviour across the board without having to build, test and release them all.

Maybe you’ve got a different opinion?