The Invisible Interface
This is something that I’ve thought about for some time so I thought I’d write a series on the topic of invisible interfaces. What is the invisible interface? When people think of a user interface, they think of something visual made up of windows and widgets. Even for a commandline program, it’s the arguments, the output and error messages. But what many people aren’t aware of are the choices the designer made and the logic the programmer codes that make decisions for you. An interface not only encompasses what the developer put into it, but also what the programmer specifically kept out. This benefits the user in a number of ways: a less cluttered interface, a simpler interaction paradigm and fewer steps to accomplish a task. Many of these things are too subtle to be noticed normally which is the beauty of it. Sometimes the best interface is the one you never know is there.
Let’s take for example the flush toilet. Yes, sorry if this example is a bit disgusting but I’ll try and keep it clean and it is a fitting example. Just bear with me here. So, where were we? Ah yes, the toilet. Simple interface. Push down on the lever, water is flushed down and it stops and refills the tank ready for the next flush. It doesn’t get much simpler than that (well, it can but more on that below). Notice how you don’t have to stop the flush. If the toilet is calibrated properly, it should have enough water to flush down whatever you may put in there.
Of course, from a performance/efficiency standpoint, it’s not optimal. You are flushing the same amount of water each time, whether there is liquid or solid matter to be disposed of. How does one work this new requirement (the need to save water) into the interface? In Europe (I have yet to see them stateside), there are toilets with a split button. Hit one side and a lesser amount of water is flushed whereas hitting the other side flushes down a full measure. There are usually markings to indicate 1 or 2 (one or two dots is what I’ve seen) so you can figure out which one is which. Now, the interface has become more complicated. Yes, in the grand scheme of things, it’s not rocket science, but humor me. Now a decision has been added. Do I hit the 1 or 2 button? The user is now required to give the device more information than they had to before. The question is, is complicating the interface worth the functional gain and also, is there a way to effect the same result without changing the interface at all?
How about auto-detecting the amount of water needed? Not only does this optimize the efficiency of the device, it also takes away a decision. Now, of course, whether this can be practically done is in question. It is unclear whether the technology to do this reliably exists and there are also issues of manufacturing, cost and maintenance that play into it. But the point is that from a pure interface standpoint, it would seem to be a better solution. It meets the new requirement while retaining the one button simplicity from before.
And to take it even further, it could sense when a flush is needed, alleviating the need of the button altogether. While these types of toilets are becoming more common in public restrooms, I haven’t heard of any demand for these in the home. Here, it’s possible that automatically doing something on the user’s behalf becomes unwelcome. I can imagine in your smaller bathroom at home, you are likely to trigger it accidentally by walking by it which can be startling. In a public setting, you probably don’t care if toilets are firing off left and right like the cannons in the 1812 Overture. On one hand, it could be just an issue of implementation; maybe the technology just isn’t accurate enough. On the other hand, it’s very possible that this is a feature (when to flush) that the user wants control over. Either way, it’s an issue that the designer must grapple with.
The point of all this is that there is some room for improvement in terms of simplifying interfaces when one strives to have their program/device do more for the user. The more your program does, the less the user has to. But one can also overstep their bounds to create something that may be seen as intrusive. It’s about defining the balance between what the user does and what the machine does, with an eye towards putting more on the machine’s side.
As I mentioned in the beginning, I’m intending this to be the start of a series. Don’t expect some well-thought out arc with this; it will probably just be an occasional article here and there. While part of me wouldn’t mind writing more about toilets (I haven’t even touched upon those wacky Japanese toilets1), in the next installments, I’ll try and come up with examples more relevant to computer/human interaction.
1: warning: linked page features bare asses
Category: User Interface 7 comments »
October 1st, 2008 at 5:42 am
Great post!
I think, for consistency, at least one toilet reference should appear in each piece in the series…..
October 1st, 2008 at 12:50 pm
Well, if that’s what people want, then I’ll have to consider it. Personally, I’m just content being able to work the words “bare asses” in a blog post.
October 2nd, 2008 at 1:56 am
Most toilets in Germany have two buttons. One for flushing and a second one for stopping. Some have one button and stop flushing when you press that second time, but those tend to work more unreliable. Another variant: One button that’s a kind of a toggle switch that you flip to one direction to flush. It toggles back once it’s done, but you can flip back sooner to stop flushing.
Seems there’s a market over here for water-saving toilets. The toilet vendors are creative.
By the way… I have never seen the variant you are describing, but hey…
October 2nd, 2008 at 1:10 pm
Thanks for that info. I’ve seen the two button toilets in Spain and the UK. I don’t remember whether or not they were in France and I have yet to go to Germany. It looks like I’m going to have to make a more extensive tour of Europe’s toilets.
Interesting about all the variations over there. So, if you don’t stop the water, does it run indefinitely? Also, is it obvious which toilet is which when you encounter one or do you have to fiddle with it to figure it out?
October 3rd, 2008 at 7:43 am
Good post.My thought on this problem is like this.
When we solve a problem through technology, do we probably not care a lot about the efficiency in the beginning, and make it a little too easy for the end user? Because, at a later point in time, we are forced to solve that problem of inefficiency, and by then we are used to very simplistic interfaces, that anything we have to do in extra, is considered a problem.
My 2 cents.
October 3rd, 2008 at 5:17 pm
Hi Suresh,
You raise an interesting point but my experience indicates that things tends to go the other way. Donald Knuth’s quote about premature optimization is appropriate here. Interfaces create legacies. Most of the time, you can improve performance without breaking everything that uses the product. Change the interface, and you risk making users re-learn the new interface or re-tool things that use it (such as a programming API). I think it’s more important to get the interface right earlier on than the efficiency.
In a future article, I’ll talk more about this but there’s a lot that can be done to improve performance without changing the interface. The user mostly cares about what is being done, not how your program or device does it. Those are the engineer’s problems and the better interface is the one that can hide all the little bumps and ugly bits in the implementation. It’s extra work but I think the mindset shouldn’t be that it’s a problem so much as a challenge.
December 7th, 2012 at 2:11 pm
Hello..the dots on the buttons of the toilet flush it’s for the blind to feel it and be able use it too. 😉