Even if I am an experienced computer scientist, even if I am an experienced web application developer, I have, more often that I’d like, a hard time to understand web application’s front-end. It happens that, in addition to being an experienced computer scientist, I also have AD/HD with a medical treatment. I’m not sure this is the root cause of my problems, but it really feels like it.

It turns out that, during my life, I noticed I was having troubles understanding my environement. Any time the room I’m in is cluttered up with lots of things, I get tired very fast. I don’t like places with a lot of things around. It has consequences: I keep my place as empty as possible. I don’t like bying new things and I often compulsively tidy the appartment.

And when interacting with websites and other softwares, I noticed that I close them faster than other people when I can’t find what’ I’m looking for.

This made me very sensitive about UX. I never develop a software without thinking how to make the features as easy to use as possible for the user. Because I am a user, eventually. And quite a demanding one. My position is: if you need to write a manual to explain the user how to use your software, you failed.

Ok, I admit, that is quite an extreme position. Not every single feature of a software can be made intuitively usable. You sometimes need documentation. But the important word in the last sentence is: sometimes. When your software need a manual or worse: an internet search, to be usable on even basic feature, then, there’s a problem.

This is an example of bad design: editing nodes of a vectorial drawing under GIMP requires you to remember key combinations. I hit that wall last week when trying to create an asset for my FreshRSS android application.

Remove a segment from a path: While pressing Shift+Ctrl key combination, point to a segment. Pointer turns to -. Click to delete the segment.

No. You. Never. Do. That.

The user interface gives you absolutely no clue has to how to remove or edit node in the path tool. the only thing you intuitively succeed to do is to create new nodes, which is frustrating.

As much as possible, the software must always give you hints of what you have to do to get what you want, or let you achieve by a short exploration of the interface.

You don’t believe it’s possible? Well, casual gaming does that every day. Video games are actually where you can find the best examples of how the interface implies what you must do to get what you want. You never find a 200 hundred pages manual provided with a video game (anymore).

It’s called affordance.

I agree. Sometimes, you just can’t leverage the complexity of the feature. And it’s ok. But sometimes, it’s really just lazyness. Or maybe something else ?

Recently, Matrix/Riot gave me a spectacular example of how a simple problem can be solved with a complex solution resulting in a desastrous user experience.

The problem

Matrix is a project for developing a communication protocol for decentralised and secure communication. In a way, it can be seen as a competitor for Telegram, for instance.

So, to achieve security, of course, it offers end-to-end encryption of communications. But there’s a problem with that: for every device you use to log into your Matrix account, the application must generate a new pair of encryption keys. These key must stay in control of the user only to provide a secure communication system.

Telegram solves this in a radical way: encryption keys are tied to the deviced you started the communication with. Meaning:

encryption in chat groups is not available
you loose the device, you loose chat history and any access to the chan…

On Matrix, the e2e encryption is actually usable only on smartphones since this is the only device on which you can always stay connected day and night. On a computed, you can’t. Meaning each time you disconnect, you loose your encryption keys (if you didn’t backed them up). And you also loose any access to every messages you wrote with them.

The bad design

With the last Riot update, the team introduced a feature to backup and restore encryption keys directly on the server. That is nice… If done correctly. And guess what: it was not done correctly.

First problem: the front-end requires you to choose a password to activate the feature. I suppose to secure the encryption of the encryption keys.

Why!?

I get the secure part of “an open network for secure, decentralized communication”. But not everyone has the same threat model. Here, the application behaves like every user was whistleblower hunted by its government. One size fits all. No. PLease, don’t do that. Give the user a choice and explain the consequences.

Ok, first hassle. But it doesn’t stop here. Because the application continues to generate a new encryption key each time you log in making the solution quite useless. Sure, you can recover messages you encrypted with old keys but the number of keys you store on the server just linearly grows.

I guess this is because the front offers to restore your keys after you logged in.

A solution

Was it possible to make it not difficult from a user experience standpoint?

Yes it was!

Of course, I’m not saying the simple solution was easy to implement. I’m saying that, if it was all you had to propose, you shouldn’t have released it. Because, as is, it’s unusable (and likely to blow up your memory with endlessly new generated encryption keys).

I would I’ve done it?

First, you don’t force the user to set a different password thant the account’s. You can give the choice, but if the user wants it simple, make it simple. Not choosing a different password give the possibility to automatically unlock the encryption keys when the user logs in.

Just to note: I understand the problem of making the encryption keys to match the devices I use. Of course, I expect Riot not to keep record of device’s fingerprints. So as soon as you erase the cookies in your browser (like I do), there’s no way to detect from which device you are loggin in.

But there’s still a simple way to do it: you ask the user. Are you logging in from a known device? Is it new? Would you like to save it and name it? So, the user could choose the device in a nice list:

mobile
work
home
outside…

And you let the user choose before generating a new encryption key. Most users are not deamers in the need of buying new phones every 2 to 3 days, dammit!

And, finally, you make make optionnal the encryption key verification system. Not every user is likely to be subject to an identity theft… Besides, this, too, is poorly designed:

How come you expect me to have a single idea of what I’m verifying!? Do you really think I remember every device ID that the people I talk to use!?

Conclusion

I’ve seen this debate a lot in the past. Security evengelist stating this or that is not secure. Not secure from which point of view? The usage I do of messaging system does not require a high level of security. I am not (yet) persecuted by my government or some kind of criminal organisation. I don’t need that level of security. This is not my threat model. But since the developers decided for every user, my user experience becomes bad. Because I am being imposed features that I don’t need.

Stop trying to frantically add features. YAGNI. Think about user experience. Build enjoyable software.

Please.