Do you love your users?

Alan Rusbridger, the editor of The Guardian newspaper, was recently asked by a UK home affairs committee investigating the Snowden leaks, “Do you love this country?” This is not a question I will answer, but I do find myself asking a similar question of software developers – “Do you love your users?” Or, put another way, “Why do you hate your users?”

As the developer of Archi, the free ArchiMate modelling tool, I’ve put in many hours of my time, and much soul-searching, trying to create an application that works simply and elegantly, hiding complexity from the user and, above all, not crashing. I’ve thought deeply about what users want and what they probably don’t want, and I’ve listened to, and responded to, user feedback. So my answer to the question, “Do you love your users?” is unequivocally, “Yes!”

I’d like to illustrate this with an example of the process of thinking about usability in my software, and finish with an example of “user hatred” in another piece of software.

Show me the love…

I just implemented a new feature in Archi – to let the user define the line colour of a selected object in a diagram. This wasn’t too difficult, I just followed the standard presentation in the Properties pane. But then it got a bit more complicated when I added an additional option to derive the selected object’s line colour from its fill colour. Again, this wasn’t too hard, but it did present a usability challenge – one option negates the other. If the latter option is selected in the application’s global preferences, then any user line colours are ignored. So how would this look in the object’s Properties pane?

Archi Properties pane

Why are they disabled?

The problem is that the line colour selector buttons are always disabled. Whatever you do, they remain disabled since the global preference is set to derive line colours from the object’s fill colour. So why on earth are the buttons there? Perhaps the user needs to do something special to the selected object to enable them? Search in the user manual? Perhaps phone the help-desk? As it stands, this is a perfect example of the software designer hating their users. It’s the equivalent of inviting someone to dinner and then hiding the food in the cupboard.

So let’s show some love and try and solve the problem. Let’s kindly explain to the user that if they want to set their own line colour, they should have not been so stupid to have set it in the application’s preferences in the first place:

Archi Properties pane - better

Hmm…why should I?

Well, why should the user have to do that? They can’t even remember where the preferences are, let alone which preference to look for. Out with the manual again!

Perhaps the better solution is to not only explain why the feature is disabled, but also to offer a link that will open the preferences dialog window and take the user to the preference that will solve the problem:

Archi Properties pane - much better

A bit better, but…

Clicking the link takes the user to the Preferences dialog window:

Archi Preferences dialog

Preferences dialog – set it here

This is not a perfect solution, since the user has to think about whether to disable or enable the option. However, it’s a lot better than before. But wait…

…why not just completely hide the colour buttons in the Properties pane when the feature is not available? This way you wouldn’t even need to show an explanatory text and link. Well, I thought about this and this creates a different problem – the user might never know that the line colour feature exists. By greying out the buttons I’m providing a hint to the user that the feature is available under some circumstances. The additional explanatory text and link then takes the user to the preferences dialog so that they can see for themselves how and why this is an option – coaching and coaxing the user.

Even this solution sucks. There are just too many buttons cluttering up the screen. Back to the drawing board.

This is better:

A better solution

A better solution

Here I’ve combined all buttons into one control – the colour selector, as before, and the “Default” and “Preferences” into a drop-down menu available from the right of the selector. I even re-used the control for the Font selector. Nice.

And now for something completely different…

That is a small example of the process I go through when demonstrating the love I have for Archi’s users. But what about software developers who seem to hate their users? I give you Protégé, an open source ontology editor from Stanford University. Here’s the opening screen on Windows:

Protege - WTF?

Protege – WTF?

This just broke Software Rule #1 – Don’t Throw Shit at the User.

Ok, how about simply opening a file in the current editor window? Here’s the result:

Protégé - oh dear...

Protégé – oh dear…

Protégé also has a menu item called “Refresh User Interface“. Really? You don’t get a dog and bark yourself. Come on, this is supposed to be Stanford Frickin’ University.

You know what? I think the Protégé developers hate their users.

We are all Journalists

It seems that the US Senate wants to redefine the term “journalist” with the so-called “Shield Law”.

Of course, this means excluding Julian Assange as a “journalist”:

Whatever they say, with the power of the internet at our disposal, we are all journalists.

we are all journalists

Coders seek the truth

Why do you debug your code? Because you seek the truth.

What is the truth? Code that works.

It’s impossible for a coder not to want to seek the truth, otherwise why would they waste time writing code that doesn’t work? Code must work. That’s the point of it. Thus, coders seek the truth. When we debug and trace, and spend days in search of the cause of a bug in our code, we are seeking the truth.

It therefore becomes ingrained in the coder to seek the truth at all levels. Perhaps this explains why we have whistle blowers and hackers that want to expose wrongdoing – Aaron Swartz, Julian Assange, Edward Snowden, and many others. When you spend your time seeking the truth in code, why would you not seek it elsewhere?

These people are not “hacking”, nor “whistle-blowing”, they are debugging. They’ve found an issue, and filed a bug report with reproducible test cases.

This begs the question – if coders seek the truth, what about non-coders? For example, certain so-called “managers”, or “directors”. These people get to the top of the greasy pole by obfuscation and lies. They operate behind closed doors, wheeling and dealing, bigging themselves up, putting their name to work that others have done, and continue to protect themselves by concealing the truth.

In terms of coding, they publish phony APIs that serve as a bogus front to private, undocumented methods and frameworks. Consequently, the organisational program becomes hampered by bugs, and any attempt to debug it by those suffering the consequences leads to accusations of “whistle blowing”, or “trouble making”.

If the organisation we belong to can’t be debugged because we’re being fed phony data, we leave.

After all, we seek the truth.

what is truth

We can be Heroes, for ever and ever

Julian Assange
Bradley Chelsea Manning
Aaron Swartz
Kim Dotcom
Edward Snowden

We can all play our part, however small. Every act, however small, adds up to a war of attrition. For example:

Use Mega to store your files
Use the latest TOR and TOR Browser
Don’t use GMail or Skype
Use PGP for email
Encrypt everything!


Gamification and Vacuous Neologisms

I read a post this morning by Nigel Green – Four G’s: Gartner, Gamification Getting Things Done & Game Theory

A nice post, fair enough. But the part that made me choke on my cornflakes* was this quote from Gartner’s Steve Prentice:

We all do Gamification already. Gamification is when we create a To Do List and enjoy the satisfaction of ticking items off and finally completing the list. It gives us focus and goals to achieve.

No, no, no, no, no! When I tick a task off of my To Do list it’s because I damn well made myself do it in spite of not wanting to. It’s called “discipline”. Do I need another word for this?

What’s the value in using another word for something I already do? When I’m on my daily jog I set myself small goals to make it more interesting, such as “run to the next lamp-post”. “Gamification!” goes the cry. Setting goals and achieving them is now “Gamification”. Groan. So what added value does this re-branding provide? To me, none. To a consultant, an academic, or an author, possibly a whole lot – opportunities for workshops, for consultancy, perhaps a paper, or a trend-setting “How To” book.

A quick Googling of the neologism led me to this article from How Stuff Works:

McGonigal believes that if people worldwide could play more, not less, in the right game scenario, their experience could help solve some of the world’s biggest problems like hunger, poverty and global conflict.

My heart sinks.

And this:

In his 2010 book “Game-Based Marketing,” co-authored with writer Joselin Linder, Zichermann defines a related term he coined: funware. Funware describes the everyday activities we’re already engaging in that we consider a game. Zichermann explains that business should look for ways to apply funware in their marketing. Funware, he says, is the core component in applying gamification to business.

My heart sinks even further. This is the kind of nonsense Douglas Adams would have included in the “B” Ark.

But, sadly, I need to get back to work, there’s a bug I need to fix. Damn, if only I had some Funware to fix it.

(* Disclaimer – I don’t actually eat cornflakes for breakfast, preferring instead that prince of foods, the muffin)