My Biggest Fear for the Future of Human-Computer Interfaces

I recently had to install and configure an 18-node OpenStack cluster, a process which involved a lot of SSHing and text-editing in terminals. I thought about learning Vim, but I was afraid of the incredibly steep learning curve, so I made do with GNU nano. It’s not at all powerful, but it’s easy.

Eventually I realized, “This is my job. This is what I do every day. Why am I holding off on learning something now, thinking it will slow me down, and that I’ll have time to learn it later? It’s not like I’m anticipating a major career shift any time soon.”

With that in mind, I quit nano cold-turkey and moved to Vim. I won’t waste time explaining why it’s so great. There are already plenty of fantastic articles on that subject.

I’ll just say this: Vim is powerful because it opens up a new interface to interact with your entire computer. Especially on Unixes, there’s hardly anything you can’t do with a shell and a good text editor. Which means you have one consistent interface that exposes everything on your computer.

Think of that. How many poorly designed, mismatched UIs do you use on a daily basis? Right now I have Chrome, Steam, Spotify, Windows Explorer, and Visual Studio open. I see about fourteen different UI paradigms cobbled together here. And, if I click in the lower-left corner, I get a completely disorienting context switch into an entirely different paradigm (that of the dreaded Metro tiles). I’m at the mercy of all these hapless UI designers.

Each one of those programs has a UI that I had to learn, each with their own quirks and bugs. Granted, Spotify and Chrome are both shining examples of UI design. I think they’re about as good as it gets. Incidentally, web browsing and music organization are two things I will probably never do in a terminal.

Exceptions aside, it’s incredibly empowering to be able to operate your computer on your own terms. And that brings me to my biggest fear for the future of human-computer interfaces:

There is no terminal in the cloud, or on mobile.

“That’s good, right? CLIs are old and not at all user-friendly.”

No argument there. But imagine for a second what a UI would look like if it had all the capabilities of a CLI with none of the cruft.

  1. Again, it would provide one consistent interface between you and all your apps.
  2. On the other hand, it would allow you to operate your apps on your own terms. Going with the analogy, right now you can choose one of 17 different shells and 5 text editors. Apache doesn’t care what editor you used to configure it.
  3. It would glue together all your applications, connecting them together however you want. In a CLI, that’s accomplished with a single keystroke.

Compare that with current trends:

  1. Cloud applications are the future of computing. Yet, to copy a picture from Facebook to Gmail, I still have to download the image, save it to disk, and upload it to another server. Most people don’t have time to figure out how to do that.
  2. Mobile applications, the uh, other future of computing, are notorious for not working with each other. Particularly on iOS, where the filesystem is almost completely opaque. On Android, it might as well be.
  3. In both cases, each app has its own set of paradigms which do not relate to other apps at all.

The whole point of the internet is to connect things together through a common interface: HTTP and hyperlinks. These days, web apps have a single URL with a giant hashtag fragment appended. That breaks the interface. I can’t write a script against that; I’d have to simulate user clicks.

“No you wouldn’t, it’s probably calling a RESTful API!”

Yes, the one shining light of hope is that every web app now has a nice, friendly, documented, open API. No, there are still major problems:

  1. The main use of these APIs is still just identity. Great, I can connect my Facebook to my account on the pygmy llama forums I visit! Oh wait, all it does is save me the hassle of logging in all the time. I still can’t have these two “apps” communicate with each other in any meaningful way.
  2. Third-party clients are the other use-case. Great, I can choose between 3,000 different Twitter client apps! Oh wait, each one still only talks to Twitter and nothing else.
  3. In the few instances where apps do talk to each other, it’s only because the users bugged the developers enough for them to coordinate a common interface. The users can’t operate their computer on their own terms. They’re dependent on the developers to add this functionality.

Contrast this to command-line tools, where every program is designed from the ground up to work with other programs through common abstractions, most notably files and pipes, and where having a UI automatically entitles you to a scriptable API.

In short, open web APIs are good but not good enough. The question is, can we design an interface that has the power of a CLI with the user-friendliness of a GUI, and that is designed from the start for cloud and mobile environments?

If we don’t, we will eventually lose control of our own computers; we’ll be at the mercy of app developers.


Christ follower and indie game developer. Running, music, programming, games, art.

Tagged with: , , ,
Posted in Coding
4 comments on “My Biggest Fear for the Future of Human-Computer Interfaces
  1. wewewe says:

    YES! And this whole ‘move toward webapps because they rocks’ is anoying. When you had all-destkop apps they work briliantly and there was no issue with exchange data between them (mostly because of the common storage) nor with communication (OS interfaces). I’m still baffled by this whole push toward cloud as a saviour… srsly – do wee need saving? Does it solve any problems – no, and we can be left cold-turkey when some could company decides that they won’t provide beloved service because you know – Social+ is way better than old RSS…

    “Spotify and Chrome are both shining examples of UI design” srsly? They both don’t follow OS UI guidelines in any way, which is at best retarded… Chrome can be liveable but Spotify annoy me each time with it’s custom frame and controls. The worst part – when it’s maximized you still can resize and move it – argh!

    • Alex says:

      You need to see further into the future. Eventually, all programs will be accessible from any computer and all user specific data will be in the cloud. That’s why everyone is moving towards web apps; it gets the ball rolling.

  2. I was tweaking around with installing OpenStack for a possible project, then RHEV, but they were exploratory projects for my own consultancy. 18 node OpenStack cluster? Ehhh… where is this and do they need any contract work? =) Sounds fun.

    And yes, vim is the one true editor. Now that you’ve ditched nano, welcome to UNIX puberty.

    • et1337 says:

      It was definitely interesting, but I don’t know about fun. :) I’d rather write code for OpenStack than try to set it up again. I’d love to hook you up with a gig but I think we’re all OpenStack’d out at this point. :) I have another article queued with a bit more information about the setup, I’ll try and get that up tonight or tomorrow.

      I do feel like I’ve made it to Unix puberty at this point! It’s fun stumbling across all these ancient Unix truths.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Evan Todd. Christ follower and indie game developer. Running, music, programming, games, art.

My games

  • Lemma - TBA - first-person parkour
  • grepr - 2014 - 7DFPS game where you are the bullet
  • Snakes in a Tower - 2012 - silly 48 hour Global Game Jam project
  • A3P - 2010 - horrible third-person multiplayer

Other things I've worked on

  • Unannounced iOS/Android game - 2014 - top-down 3D shooter
  • Unannounced mobile VR title - 2014 - theater app
  • Skyward Slots - 2013 - server-based F2P iOS slot game