The SwitchBoard Strategy

I'd like to take some time to lay out the ideas I have for the SwitchBoard project. This is a specific idea that arose as part of the Disability-Driven Development concept. It's also a concrete step towards the more radical, long-term vision I explored in Peeking Into a Future. The path from "here to there" is long, uncertain, and complicated - so I want to dig into what exactly I'm doing, and how I think it will help us get there.

One of the most important things I've had to learn, in my own personal life, is how and where to be flexible. As much as I wish I could predict or plan for the future, the reality is that any time I try, I'm usually quite wrong. I've found much more success in knowing the overall direction I'm trying to go, and continuously check in to make sure I'm on track, and that what I'm doing is helping me make progress.

So a lot of this plan is speculative. It isn't the kind of detailed schedule or road map one might typically find in a software development project. That's admittedly quite different from the norm; but then, so is all of the Disability-Driven Development mindset.

To me, this difference is part of what makes the approach so special. I am personally not at all satisfied with what "tech" as an industry (or field in general) has been doing, in the past century or so that digital computing has really truly been a thing. Doing better than the existing systems will, inherently, require that we do something different.

A Recipe for Growing Technology

The typical approach to digital technology creation, as it stands today, draws heavily on industrial metaphors. We speak of building, of assembling, of planning and architecting and remodeling (although it's more popular to call that "refactoring" in the software scene). I contend that these analogies are actually quite ill-suited to the creation of software. It is, by and large, an unfortunate coincidence that so much software has been created in such a way - because it has given us a false impression that this is a good approach.

On the contrary, I think that this model lends itself to reinforcing several damaging aspects of white supremacy culture in particular. This makes sense, given the dominant players in the digital tech space today; but again, in order to do better, we need to do things differently.

SwitchBoard is a computer programming tool. However, unlike the programming tools and technologies that are in widespread use today, SwitchBoard is explicitly designed to offer new ways of thinking about how software gets created.

The actual "environment" of SwitchBoard is deliberately designed to facilitate experimentation, exploration, and play. Play is one of our most powerful skills for discovery and learning, and it is woefully underappreciated. I do not think creating software should be "work." I think that creativity is, inherently, incompatible with capitalism. Moreover, I think that creating things through play can be nourishing in and of itself. With SwitchBoard, we not only get a chance to enjoy being creative and playful, we also get a chance to make things that can actually benefit our lives as well.

Currently, software is mostly built using a selection of "programming languages." These technologies tend to painfully over-focus on typed text, demand rigid hierarchical organizational structures, and are almost exclusively tuned to expect English from the people using them. To break out of the ruts of what digital tech is today, we need new ways of making software.

Under the hood, SwitchBoard works on a novel concept of what software is and how it works. This idea is what I've come to call the "Recipe Model" of programming. The Recipe Model encourages thinking about software as a series of processes that combine ingredients and turn them into results. By describing our "recipes" in very clear and specific terms, we can represent anything a computer can do!

This works because of a principle that has been known for nearly a century, thanks to Alan Turing's idea of a Universal Computing Machine. All of our contemporary computer hardware, software, and science draws heavily on this notion.

However, in practice, things are not always so convenient or easy. It is in the realm of pragmatic concerns that today's digital technology most often fails us. Just because our computers have incredible capabilities, in a mathematical, theoretical sense, doesn't necessarily mean they can do what we want them to right now.

The Recipe Model is not simply another theoretical idea of how to make software. Instead, it is a deeply practical model, designed specifically to allow creative people to imagine, invent, and share ways to move beyond the limits of current software technologies.

In a way, the Recipe Model can be thought of as a kind of "universal adapter." If we can describe, in the Recipe system, what a program does in enough detail, we can then get it to interact with anything else that also has a Recipe description. Even if those things weren't created with the Recipe model in mind, we can often find ways to help them all get along.

The Recipe Model heavily focuses on the notions of autonomy and consent. Ideas of consent, trust, and safety are woven into every aspect of the Recipe system, including the very vocabulary it uses. Instead of "running a script" or "launching an app," we talk about giving consent to a Recipe to do its thing - because, in turn, we've chosen to trust that its results are something we want.

SwitchBoard combines playful exploration, a consent-oriented model of computing, and a mindset of learning how to welcome the participation of very different participants. These ingredients affect the actual programs that we make in SwitchBoard, but they also reflect a much larger set of principles - about how we make communities around software-creation as an activity.

It's possible for one person to use SwitchBoard, alone, like a tiny personal garden, creating new software. However, even a tiny garden exists within a larger ecosystem; and SwitchBoard is no different. I've chosen the core ideas of this project very deliberately, because I want to repeat those same patterns in the larger ecosystem of people who use it.

By exchanging recipes, swapping ideas, and exploring and playing together, we can build even more complex, sophisticated, and successful things - and we can extend the reach of our ideas far beyond one person at a computer keyboard.

First, though, we have to get some basics in place.

Initial Implementation

The first part of SwitchBoard's creation is already well under way. In this phase, I'm specifically using tools I am already familiar with. I've chosen to use the language C# for now, specifically, to build the first "draft" of SwitchBoard. This helps get things up and running relatively quickly, and also opens up a lot of early flexibility for the project, since there are lots of cool things I can directly use from a C# environment.

This means that, early on, the tool is going to have very limited appeal. Even though it's rapidly moving away from "typed text" style programming, it still is mostly going to make sense to people who are already familiar with existing programming approaches and technologies.

Someday, that will evolve; but for now, it's much more important to just have something that works. Because of the way the Recipe Model is designed, the system will eventually be able to do far more than just interact with C# code and libraries; but we'll get to that.

A New Way to Think About User Interfaces

With today's tools and technologies, creating user interfaces is messy, slow, and often difficult. Even the best tools available can have severe shortcomings in terms of accessibility. Very little software allows rich, complex customization of its user interface - if it allows any at all, beyond perhaps a "dark theme" toggle.

One of the specific things I'm exploring with the Recipe Model is a novel approach to user interface design. Currently, most approaches focus heavily on placing visual elements ("widgets") onto a screen, and proceed from this emphasis. In SwitchBoard, we go about things from the other direction.

To create a user interface in SwitchBoard, we start by thinking about what we want people to be able to do. In other words, we think in terms of affordances. This places the focus on who is using the software and what kind of relationship we want them to be able to have with the tech itself.

From there, we can think about accommodations. Any given affordance - such as "sending a message to another person" - might need to be provided in a number of different ways, depending on who is involved. This prioritizes access needs from the very beginning, and makes it much harder to accidentally forget or omit things like support for text/speech conversion, image descriptions, tactile cues and haptic feedback, and so on.

Most importantly, our programs are not created by trying to "assemble" pieces of "user interface stuff" into a coherent whole. By starting with the intent, and thinking carefully about access, we can create software that is not directly tied in to any one kind of user interface.

It will take time to get this system to the point where it can be demonstrated, but my goal is to show that this approach actually unlocks huge new possibilities in terms of making software accessible. Since we've described what the program does (in a series of Recipes) as well as how people use it (using affordances and accommodations), we can then attach any user interface that satisfies those requirements onto our program.

As a practical example, this means we could create a new app that keeps track of, say, a To Do list - and with no extra work, that app could be usable for sighted people with access to touchscreen devices, blind users via text/speech conversion systems (or hardware devices like Braille displays and input systems), paralyzed users via eye tracking systems, and so on.

Along the way, one of my goals is to actually recreate the SwitchBoard UI itself using this model. This will help test the ideas out, and also make the entire ecosystem that much more accessible and ready for more people to join the community.

Weaving In More Technologies

Starting in C# is a decision made for expedience. It helps me get going and build up a certain mass of working "stuff" fairly quickly. But it has limitations. Eventually, I want to expand well beyond just one programming language, building on the "universal adapter" concept that underlies the Recipe Model.

One of the first goals I established, when I began thinking about the Recipe Model, was to effectively get very different programming languages to be able to interact smoothly with each other.

To start off with, I'm looking into existing software libraries that can do things like embed a full web browser into a C# program. This will open up the possibility of using SwitchBoard to generate web pages, using the Recipe Model. By adding in existing libraries that can act as web servers, we could actually design and build an entire web service in SwitchBoard itself, which would be usable from any web browser!

As powerful as SwitchBoard's Recipe Model is, however, it does have some limits. In particular, the cost of being a universal adapter is that SwitchBoard has to do a lot of "translation" between different parts of a program. One way we can transcend this is to actually invert the usual way that SwitchBoard uses Recipes. Instead of just describing what some other code does, we can use a Recipe to generate new code.

This means that, given a bunch of Recipes that effectively operate a web site, we could actually generate code - in virtually any established language - based on those Recipes. So if we want to run our SwitchBoard web site on a Linux-powered device using a JavaScript back-end, all we'd need is a way to generate that code from the recipes themselves.

Creating these kinds of "generators" will be a crucial phase of SwitchBoard's development. It will also be an endeavor that will benefit from having lots of people involved, since it's a huge effort! I'm hoping to be able to start growing the community for SwitchBoard heavily during this phase.

Stitching together various kinds of programming technology will make it possible to do things that, currently, are very awkward or just plain impractical.

For example, with a good mixture of adapters and code generators, we could weave together a library written in Python, a set of command-line utilities, and a desktop-application interface - each running on entirely different operating systems!

One concrete idea I'm excited to explore here is to tie this back in with user interface creation. Imagine that, instead of tweaking a UI layout by adjusting numbers or dragging and dropping shapes and edges around, we wanted to just draw the layout on a piece of paper instead.

SwitchBoard could very realistically enable this kind of thing. We could capture a picture of the drawing via a webcam or scanner, use shape-recognition algorithms from an existing library (such as OpenCV), and feed the design into our affordance and accommodation framework to actually generate a working UI - all from a paper sketch!

Coordinating software across multiple platforms becomes much easier in this paradigm as well. Since we have a "universal adapter" to work with, in the form of the Recipe descriptions people create, we can build software that transcends the limits of operating system, and even type of device.

Running on servers, desktops and laptops is a good start, but there are plenty more places to explore. Mobile devices could also be supported using the SwitchBoard ecosystem, for example, given people to help build up the appropriate collection of recipes.

But we can also start exploring hardware that is usually very inaccessible. Embedded systems, such as the Arduino and "system on a chip" computers, could also be welcomed into the SwitchBoard world. And once the act of making programs for such specialty hardware is significantly more accessible, things get really interesting!

Imagine people being able to create, maintain, and share recipes that not only provide useful software, but also interact with hardware devices. I don't think SwitchBoard needs to stop at just making it easier to grow software; I think, in the long term, there is a very real possibility for SwitchBoard to influence the creation of actual physical things that can improve our lives as well.

By offering this creative power to the multiply-marginalized, we can produce genuine change in the way that various communities experience and interact with technology. There will be no need to wait for "big tech companies" to care about what real people need or want; we can just build it for ourselves, and for each other.

Networks and Communities

Part of SwitchBoard's "universal adaptor" concept includes the ability to coordinate programs across communication networks. I alluded before to the idea of a program, crafted using SwitchBoard, that has elements spread across numerous different hardware and operating system platforms. In the long term, what really excites me about this is that it offers some very strong potential for communities as well.

If we craft our recipes carefully, we can actually have many different electronic devices participate in larger systems together. But since all of this software - and maybe even hardware - is stuff that we created for ourselves, we can define how it works.

Since the Recipe model is deeply built on the notions of autonomy, consent, and voluntary trust, this will ripple outwards in everything that is created using the model itself. The resulting technologies will also reflect these principles. With tech grown this way, we can choose what our tech does. We can retain control of all our own data. We can enforce our own privacy. Rather than having to accept "Terms and Conditions" from massive, profiteering corporate entities, we can make things that satisfy us exactly as we want them to.

Imagine a local group of people that want to get involved in mutual aid operations for their area. They want a way to coordinate their efforts, to communicate among themselves, keep track of who has things to offer, and who has needs. They want a way to make sure their resources are used well, and they care that any data about who might be vulnerable in the community is kept safe and private.

Today, such a group might have to cobble together a plan from a bunch of existing bits of software, and might struggle with balancing their effectiveness with their privacy concerns.

But what if there were other groups, around the world, who had already grown some of their own solutions, and knew what worked well? What if this new mutual aid group could tap into the creative power of any number of other groups who wanted to share what they've made? What if the global community of SwitchBoard creators could just send the aspiring aid group a stack of recipes?

What else could we create, and share, with one another, if we didn't need to wait for exclusionary, elitist tech corporations and "open source" initiatives to care?

Bonus Ideas

SwitchBoard has been a profoundly inspiring project for me, personally. Far beyond just a grassroots change in how software gets made, I can see it also affecting every aspect of digital technology creation, as well as the invention of new devices that - for once - serve the needs and interests of the least-privileged in our world, instead of the most-comfortable.

My own personal focus, however, is going to be the realm of just making software. It's what I've been doing for basically all my life, it's what I'm good at, and it's where I can personally make the biggest contribution to the overall idea of Disability-Driven Development.

Within that space, I've also had a number of other ideas that I am excited to explore someday using SwitchBoard and the Recipe Model. I'll just drop a few teasers of some of those ideas:

• The Recipe Model opens up a lot of very fascinating possibilities for debugging software built in SwitchBoard. Imagine being able to pick a specific portion of a running program, and literally watch it process its data and do its work, without disrupting the overall program's behavior!

• We've all used software and been frustrated by it being slow, unresponsive, or just crashing or stalling out on us. SwitchBoard's approach to growing programs also lets us monitor them in unprecedented ways. Performance profiling tools are often hard to use and interpret in the context of text-heavy programming languages; imagine a system that can detect slowdowns, bottlenecks, and inefficiencies at any level of abstraction or scale, and not just by listing how long specific function calls take!

• I've only barely begun to scratch the surface of what the consent and voluntary-trust concepts could become. I'd love to dig more into this over time, and introduce entire new safety and security paradigms, enabled by the way that the Recipe Model bakes these principles into everything.

• A recurring daydream I've had is to see how far we can go with breaking programming free of "typing text on a computer." I've talked about a (very realistic) idea of drawing user interfaces on paper; but what if we could actually put a recipe into a physical object? What if, instead of connecting various recipes in our imaginations using a program like SwitchBoard, we could actually create programs by physically combining these "recipe blocks?" What if making useful new computer programs didn't even require a computer?

• Perhaps my fondest hope for the software creation side of all this is an "assistive programming" concept that I've been nicknaming "Sous Chef" (in honor of the "recipe" analogy). The Recipe Model is, by design, essentially a semantic-rich description of what computer programs do, as well as why. Since these descriptions of our programs are all made in a consistent, structured style, they are effectively a kind of regular data. In other words, we can feed our recipes into various algorithms that will actually preserve our intentions and goals.

  To put it into concrete details, Sous Chef would be a sort of "companion module" for SwitchBoard. Say we know we have a set of ingredients available, and what we want to make, but we don't quite know how to create it. By putting this information into Sous Chef, we could potentially generate chunks of a program that do what we want, along with specific, guided hints as to what else we need to figure out on our own. Reducing the mental effort of making software, in this way, both serves to unlock extra creative energy, as well as reducing the accessibility barriers for tech creation even further.

There is a huge amount of potential in all of this. I could literally spend the rest of my life exploring all the exciting ideas that I've had already, and yet I know this is only the beginning of what can be done. If you're also excited by this possible future, and able to do so, here's how you can support my work.

Before I close, I want to repeat that this whole thing works so much better with a community. If any of the ideas in this "strategy" are appealing to you, or seem like things you'd want to explore too, please get in touch with me - I'd love to create this new world of tech alongside you!