Of "User-Facing" Software
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".
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.