Skip to main content

Of "User-Facing" Software

Posted by editor on July 23, 2007 at 1:29 PM PDT

You might have noticed my use of a new term, user-facing, in some of my editor's blogs. Since Josh made a big deal of distinguishing between client software and desktop software in his recent blog about upcoming Java GUI awesomeness, I thought I'd take a minute to discuss why I'm in search of a new term.

First, Josh is right: "desktop" is a wholly inadequate term for a lot of the things we mean by the term. Now that the GUI toolkits originally meant for desktop applications are running on phones -- like Swing on the SavaJe (or whatever its successors will be called) to Cocoa on the iPhone -- the idea of associating the API with its typical real-world environment has been completely broken. The concept had other flaws as well, such as application baggage (presumptions of installers and double-clickables) that didn't make sense for scenarios like applets and Java WebStart. So "desktop" just isn't a term that does a lot of good for its intended uses anymore.

Josh uses "client" to cast a broader net, to include non-PC runtime environments like phones, set-top boxes, etc., that would also offer a visual interface to the user. Good. But my problem with the idea of calling these "clients" is the implication that there is a corresponding "server" somewhere. Coming from the company that makes the net work, the one that put the dot in dot com, that's a perfectly understandable bias. But I think its still inaccurate.

There are lots of apps we use every day that aren't networked, "clients" that don't have a server. Even if they do, in the context of describing API's and programming practices, "client" doesn't capture the essence of what's involved. If I talk about an e-mail "client", sure, the concept of that application interacting with a server is useful. But if I say I'm a "client-side programmer" who worked on an e-mail app, you'll rightly assume that my focus and speciality is on the buttons, lists, tables, and other components that make up the GUI. Maybe I did the networking too, but at the moment that I stop talking about Swing and start talking about sockets, I've temporarily stopped being a "client" programmer and started being a "network" programmer, even though I'm still working on an e-mail "client".

Lately, in the context of describing the field of developing GUI's, I've started using the term user-facing, as in user-facing software, user-facing API's, etc. It's a mouthful, and I'm not entirely satisfied with it, but I think it has the advantage of accuracy across a broad range of technologies. A Swing programmer, a Flash author, and an Ajax JavaScript developer all have something important in common: their focus is on the code that presents information to the user and lets them interact with it through various facilities (buttons, menus, touch-screens, game controllers, speech recognition, etc.). The point is that these people are writing the code that the user is in direct, face-to-face contact with. Hence, "user-facing".

Also, it's a term that's biased and loaded in useful ways. A "client" is a balloon in a flow diagram on a whiteboard. Calling something "user facing" reminds us that there are real people working with our stuff, and reminds us that it had better not suck, you know, as if people mattered.

So, that's my case for a new term... maybe this one, and maybe another. But I'm consciously avoiding both "desktop" and "client" except in those cases where they are clearly accurate. When describing the broader concept of GUI code that is the user's point of access to a system, I'm trying to develop better terminology.

Related Topics >>