Middle Class Software

The middle class is where most of society resides. It's where most political campaigns take aim, and if they don't, they'll look as though they don't care. Why doesn't software do the same thing? It's funny how software can take control over every aspect of our lives, and yet, we're not all that concerned with accessible software. I don't mean accessible from a standards perspective for users with disabilities — that's an entirely different problem. In this context, I'm referring to software that's inaccessible even to those that fortunate enough not to be disabled. It's a problem, I think, that there is a ton of good code produced in various open source communities, and it doesn't get the kind of audience that it should. The reasons aren't plentiful, but not straightforward, because if they were, we would simply address these issues. But I'm sure that if we could try to identify the middle class software user, your typical every day user that might want to use your software, we could take steps in making the world of computing more appealing.

Why do I care if someone finds my software inaccessible to the normal, every day, middle class person? I find this to be an interesting question with plausible answers at both ends. First, let's make mention of that fact that when we're talking about software for a particular class of user, in this case the middle, we're of course targeting a specific domain. For example, graphics editing software, virtualization software, banking software — each have their own middle class of user. On the one hand, if I'm the leader in my market and nobody else even comes close to competing with me, I feel less compelled to make my software more usable, and approachable. On the other hand, maybe I'm not a leader in my market, and I have to think about keeping existing users. Therefore, changing things up to try and grab a hold of users I don't yet have, probably doesn't make much sense.

There are plenty of reasons to not care about the lay user and what they think or do not think about your software. But the one thing all software projects have in common is that they have to have users. Whether your project is strictly internal to an organization, whether you're developing off-the-shelf enterprise components, or whether you're scratching an itch with an open source project — you need users. Users may not drive the initial creation of software — though they sometimes do. They most certainly drive the continued evolution of it.

This is exactly why software developers need to care about what Joe Blo thinks of their software. How approachable is it, what's the cost in time money and effort to setup the environment before I'm even able to install the software? If middle class Joe Blo can't do it, big deal right? We'll just make sure it's documented really well. We'll make note of the requisite experience required in setting up similar systems — all will be well. Don't get me wrong, the middle class aren't a bunch of dolts — they're almost certainly computer literate to varying degrees and they probably have setup complicated systems before. But that doesn't mean that they enjoyed the experience nor does it mean they'd be willing to do it again.

The problem with discounting Joe Blo as a viable user of your software, is that you're missing out on valuable data. If he hasn't interacted with your system before, and is therefore unfamiliar with it, you get to watch him evolve over time. You get to hear Joe's complaints. You hear questions asked that you never would have thought to ask on your own. And you get all of this valuable information because Joe more or less likes your software. He didn't need a big down payment in time or effort or hardware requirements. He was able to dive in, and he posed the questions and concerns that he did because he cared enough about the software to do so. If your software is truly inaccessible to the middle class, then you'll never hear these questions because you've given the user zero chance to formulate them.

Another issue with inaccessible software, one I fear will come back to hit us in the future, is education. Kids now grow up computer literate, even those who have zero interest in entering the field later in life. They don't have much choice. It's like growing up in Canada — even if you hate hockey, you have a working knowledge of the sport out of necessity. And chances are, no matter what kids end up doing when they grow up, they're lives will be impacted by the accessibility of software. How easy is it for them to install it, learn it, and make effective use of it? There's always the question of relevance, of course. Installing something on your iPhone is easy to do. Apple has done a frighteningly good job at making software accessible.

Students, or in general, the parts of the global population that have a thirst to learn, need cheap hardware. That is becoming less and less of an issue today for consumers and educators. The real problem is finding a wide enough range of software that'll run on these devices. We need an approach that'll get software in every domain able to run on these cost-effective devices. Why not build that software?

The challenge is due in part to attitudes and the morale of software development teams. Opening the gates that'll allow the masses to operate cheap hardware means building accessibility from the ground up. Obviously, to interface directly with the hardware and to tinker with the operating system kernel, you're going to not only need to know what you're doing, but you're going to need a lot of experience under your belt. Moving up from this level, though, is where we really need thought put into accessibility. Think programming languages. In particular, I think of Python. It was among my earliest exposure to programming and I think it hammered-home the idea of readable code. Approachable code — I didn't run off in the other direction, and I've no doubt other folks have had such Pythonic experiences.

What this all boils down to is software usability. Or, user experience. I think this thought exercise amounts to broadening the usability scope. We have to think of things that aren't necessarily user interface related — concepts such as "approachability". Affordability goes beyond the price tag of the software itself, in the eyes of the user, to include the cost of time and effort in learning the software so as to make effective use of it. It wouldn't be all that difficult to lower the barrier to entry for middle class users, at least not if we acknowledge their existence.