What makes a good interface?

In this post we begin to tackle the question: What makes a good interface? We
do this in the context of Netpowder and by using a specific example with
before/after screenshots.

Last week I turned Netpowder from a
proof of concept to automating the depolyment of around 15 satellites. The
details involved a lot of shell scripting and setting up Jails on FreeBSD using
iocage. This if far from perfect but it’s good enough for now - I can
re-generated a satellite in about 30 seconds, if need be. It’s time to move on
to more pressing matters: the interface.

I still don’t know what Netpowder is or what it will be in a few months from
now, but I do know that it’s bad in multiple respects. The biggest bottleneck
right now is in terms of usability - once you have access to it, then what do
you do? How do you use and discover the interface? This will be the focus for me
these coming weeks, along with bugfixes and helping onboard trial users.

There are so many directions to go in in terms of interface - should we try to
move towards no shell, make the shell better, provide live feedback, provide
integration with git, represent files visually, etc. Where do you even begin?
They all sound interesting and useful, but they also conflict with each other in
what you are optimizing for.

So what do we do? One way is to begin by doing something simple and obvious:
making what we have now suck less. That’s at least a step in the right direction
- making a better interface, for whatever Netpowder turns out to be - so let’s
focus on that.

A bad welcome

Let’s look at the welcome experience from a user’s point of view.

First thing I see. Now what?

After typing a bad password. Apparently I am disconnected?

Ok that worked, but still, now what?

Making it better

Let’s try to fix it and turn each of those screens into a positive experience
with concrete feedback. First of all, it should tell you that you are supposed
to sign in with the access code you have been given.

Much better!

Let’s make the unauthenticated message a bit nicer, and let’s get rid of the
disconnect. This requires some changes in the server, but not a lot.

No more unfriendly disconnects, lets try again.

Finally, the message after you login, which points to further help.

Hm, I want some help, I think?

Let’s provide that help message too. Simple using the README file will do for
now.

Woah, that’s a lot of text. Oh well, at least I know where to go if I’m
stuck.

Conclusion

We started off with the general question: what makes a good interface? and, in
the face of uncertainty, we drilled down to a trivial but specific example,
making some very small changes to make a certain user flow suck less.

This might seem like an obvious thing to do - and it is - but all these details
add up. How many sites have you not been to where the flow just doesn’t make any
sense? How many error messages have you read which are just nonsensical? All it
takes is a little empathy with the end user and attention to the problem.