Athabasca University's Digital Governance Committee recently got into a heated debate about whether and why we should support Zoom. It was a classic IT manageability vs user freedom debate and, as is often the way in such things, the suggested resolution was to strike up a working group/sub-committee of stakeholders to identify business requirements that the IT department could use to find an acceptable solution. This approach is eminently sensible, politically expedient, tried-and-tested, and profoundly inadequate.

As Henry Ford (probably never) said, "if I'd asked people what they wanted they would have said 'a better horse'".

A design approach that starts by gathering business requirements situates the problem in terms of the current solution, which is comprised of layers of solutions to problems caused by other solutions. For simple 'hygiene' tech that serves a hard, well-defined business function - leave reporting, accounting, etc - as long as you do properly capture the requirements and don't gloss over things that matter, that's normally fine, because you're just building cogs to make the existing machine work more smoothly. However, for very soft social technologies like meetings, with potentially infinite ways of using them (by which I mean purposes, techniques, ways of assembling them with other technologies, and so on), no list of requirements could even begin to scratch at the surface. The thing about soft technologies - meetings, writing, pencils, pedagogies, programmable computers, chisels, wheels, technologies of fire, groups, poetry, etc - is that they don't so much solve problems as they create opportunities. They create adjacent possible empty niches. In other words, they are defined by the gaps they leave, much more than the gaps they fill. What happens as a result of them is fundamentally non-deducible. 

Solving different problems, creating different possibles

Meetings are assemblies of vast ranges of technologies and other phenomena, and they serve a vast number of purposes. Meetings are not just one technology but a container for an indefinitely large number of them. They are, though, by and large, solutions to in-person problems, many of which are constrained by physics, physiology, psychology, and other factors that do not apply or that apply differently online. Most webmeeting systems are attempts to replicate the same solutions or (more often) to replicate other webmeeting systems that have already done so, but they are doomed to be pale shadows of the original because there are countless things they cannot replicate, or can only replicate poorly. Among the phenomena that are the default in in-person meetings are, for example:

• the immense salience brought about by travelling to a location, especially when it involves significant effort (lost in webmeetings);
• the fact that it forces attention for a sustained period   (most webmeeting software and ways of using it makes inattention much easier);
• the social bonding that we have evolved to feel in the presence of others (not well catered for in webmeeting software);
• the focus and meaning that comes from the 'eventness' of the occasion (diluted in webmeetings);
• the ability to directly work together on an issue or artefact (limited in some ways in webmeetings, though potential exists for collaborative construction of digital artefacts);
• the inability to invisibly escape (easy in most webmeetings);
• the microexpressions, postures, movements, smells, etc that support communication (largely lost in webmeetings);
• the social bonding value of sharing food and drink (lost in webmeetings);
• the blurred boundaries of entering and leaving, the potential to leave together (usually lost in webmeetings);
• the bonding that occurs in having a shared physical experience, including adversities such as a room that is too hot, roadworks outside, wasps in the room, etc, as well as good things like the smell of good coffee or luxurious chairs (not remotely possible in webmeetings, apart from when the tech fails - but then the meeting fails too);
• the support for nuances of verbal interaction - knowing when it's OK to interrupt, being able to sigh, talk at once, etc, not to mention having immediate awareness of who is speaking (webmeetings mostly suck at this);
• the ability to cluster with others - to sit next to people you know (or don't know), for instance (rarely an option in most webmeetings, and nothing like as salient or rich in potential as its in-person counterpart even when allowed);
• the salience of being in a space, with all the values, history, power relationships, and so on that it embodies, from who sits where to which room is chosen (hardly a shadow of this in most webmeetings);
• the ability to stand up and walk around together (a motion-sickness-inducing experience in webmeetings);
• the problems and benefits of both over-crowding and excessive sparsity (very different in webmeetings);
• the means to seamlessly integrate and employ other technologies, including every digital technology as well as paper, dance, desks, chairs, whiteboards, pins, clothing, coffee, doors, etc, etc, etc. (webmeetings offer a tiny fraction of this);
• and so on.

A few of these might be replicated in current or future webmeeting software, though usually only in caricature. Most simply cannot be replicated at all, even if we could meet as virtual personas in Star Trek's holodecks. Of course there are also many things that we should be grateful are not replicated in online meetings: conspicuous body odour, badly designed meeting rooms, schedule conflicts, and so on, as well as the unwanted consequences of most of the phenomena above. These, too, are phenomena that the technologies of meetings are designed around.  In-person meetings are incredibly highly-evolved technologies, making use of technological and non-technological phenomena in immensely subtle ways, as well as having layers of counter-technology a kilometre deep, from social mores and manners to Roberts' rules, from meeting tables to pens and note-taking strategies. Much of the time we don't even notice that there are any technologies involved at all (as Danny Hillis quipped, 'technology' is anything invented after you were born).

Webmeetings, though, also have distinctive phenomena that can be exploited, such as:

• the ease of entering and leaving (so breaks are easier to take, they don't need to last a long time, people can dip in and out, etc);
• the automation of scheduling and note-taking;
• the means to record all that occurs;
• the means to directly share digital tools;
• the fact that people occupy different spaces (often with tools at their disposal that would be unavailable in a shared meeting space);
• the captions for the hard of hearing;
• the integrated backchannels of text chat.

These are different kinds of problem space with different adjacent possibles as well as different constraints. It therefore makes no sense to blindly attempt to replicate in-person meetings when the problems and opportunities are so different. We don't (or shouldn't) teach online in the same way we teach in the classroom, so why should be try to use meetings in the same way? For that matter, why have meetings at all?

Dealing with the hard stuff

Some constraints are quite easy to specify. If a matter under discussion needs to be kept private, say, that limits the range of options, albeit that, for such a soft technology as a meeting, privacy needs may vary considerably, and what works for one context may fail abysmally for another. Similarly for security, accessibility, learnability, compatibility, interoperability, cost, reliability, maintainability, longevity, and other basic hygiene concerns. There are normally hard constraints defining a baseline, but it is a fuzzy baseline that can be moved in different contexts for different people and different uses. No one wants unreliable, insecure, expensive, incompatible, unusable, buggy, privacy abusing software but most of us nonetheless use Microsoft products.

It is also not completely unreasonable to look for specific known business requirements that need to be met. However, there are enormous risks of duplicating solutions to non-existent problems. It is essential, therefore, to try to find ways of understanding the problems themselves, as much as possible in isolation from existing solutions. It would be a bad requirement to simply specify that people should be able to see and hear one another in real-time, for example: that is a technological solution based on the phenomena that in-person meetings use, not a requirement. It is certainly a very useful phenomenon that might be exploited in any number of ways (we know that because our ancestors have done it since before humans walked the planet) but it tells us little about why the phenomenon matters, or what it is about it that matters.

It would be better, perhaps, to ask people what is wrong with in-person meetings. It still situates the requirements in the current problem space, but it looks more closely at the source rather than the copy. It makes it easier to ask what purposes being able to see and hear one another during in-person meetings serve, what phenomena it provides, on what phenomena (including those provided by other technologies) it depends, and what depends on it. From that we may uncover the business requirements that seeing and hearing other people actually meet. However, it is incredibly tricky to ask such questions in the abstract: the problem space is vast, complex, diverse, and deeply bound up in what we are familiar with, not what is possible.

It might help to make the familiar unfamiliar, for instance, by holding in-person meetings wearing blindfolds, or silently, or to attempt to conduct a meeting using only sticky notes (approaches I have used in my own teaching about communication technologies, as it happens). This kind of exercise forcibly creates a new problem space so that people can wonder about what is lost, what is gained, reasons for doing things, and so on. If you do enough of that, you might start to uncover what matters, and (perhaps) some of the reasons we have meetings in the first place.

Exploring the adjacent possible

Perhaps most importantly, though, soft technologies are not just solutions to problems. Soft technologies are, first and foremost, creators of opportunities, the vast majority of which we will never begin to imagine. Soft technology design is therefore, and must be, a partnership between the person and the technology: it's not just about creating a tool for a task but about having a conversation with that tool, asking what it can do for us and wondering where it might lead us. What's interesting about the ubiquitous backchannel feature of webmeetings, for instance, is that it did not find its way into the software as a result of a needs assessment or analysis of business requirements. It was, instead, an early (and deeply imperfect) attempt at replicating what could be replicated of synchronous meetings before multimedia communication became possible. When designing early web conferencing systems, no one said 'we need a way of typing so that others can see it'. They looked at what could be done and said 'hey, we can use that'. The functionality persisted and has become nearly ubiquitous because it's easy to implement and obviously useful. It's an exaptation, though, not the product of a pre-planned intentional design process. It's a side-effect of something else we did - a poor solution to an existing problem - that created new phenomena we could co-opt for other purposes. New adjacent possible empty niches emerged from it.

One way to explore such niches would be to give people the chance to play with a wide range of existing ways of addressing the same problem space. A lot of people have turned their attention to these issues, so it makes sense to mine the creativity of the crowd. There are systems like Discord or MatterMost, that represent a different category of hybrid asynchronous/synchronous tool, for instance, blurring the temporal boundaries. There are spatial metaphor systems with isometric interfaces like Spatial, or Ovice, which can allow more intuitive clustering, perhaps contributing to a greater sense of the presence of others, while enabling novel approaches to (say) voting, and so on. There are immersive systems that more literally replicate spaces, like Mozilla Hubs or OpenSim. I hold out little hope for those, but they do have some non-literal features - especially in ways they allow impossible spaces to be created - that are quite interesting. There are instant messengers like Telegram or Signal, that offer ambient awareness as well as conventional meeting support (MS Teams, reflecting its Skype origins, has that too). There are games and game-like environments like Gather or Minecraft, that create new kinds of world as well as providing real-time conferencing features. And there are much smarter webmeeting systems like Around (that largely solves almost all audio problems, that - crucially - can make the meeting a part of a user's environment rather than a separate space for gathering, that rethinks text chat as a transient, person-focused act rather than a separate text-stream, that makes working together on a digital artefact a richly engaging process, that automatically sends a record to participants, and more).  And there's a wealth of research-based systems that we have built over the past few decades, including many of my own, that do things differently, or that use different metaphors. Computer-supported collaborative argumentation tools, for instance, or systems that leverage social navigation (I particularly love Viégas's and Donath's ChatCircles from the late 1990s, for instance), and so on. They all make new problems, and all have flaws of one kind or another, but thinking about how and why they are different helps to focus on what we are trying to do in the first place.

Perhaps the best of all ways to explore those adjacent possible empty niches is to make them: not to engineer it according to a specification, but to tinker and play. I've written about this before (e.g. here and, paywalled, here, summarized by Stefanie Panke here). Tinkering as a research methodology is a process of exploration not of what exists but of what does not. It's a journey into the adjacent possible, with each new creation or modification creating new adjacent possibles, a step by step means of reaching into and mapping the unknown. We don't all have the capacity (in skills, time, or patience) to create software from scratch, but we can assemble what we already have. We can, for instance, try to add plugins to existing systems: it is seldom necessary to write your own Wordpress plugin, for example, because tens of thousands of people have already done so. Or we can make use of frameworks to construct new systems: the Elgg system underpinning the Landing, for example, does require some expertise to build new components, but a lot can be achieved by assembling and/or modifying what others have built. Or, if standards are followed, we can assemble services as needed: there are standards like xcon, XMPP, Jabber, IRC, and so on that make this possible. And we don't need to create software or hardware at all in order to dream. Hand-drawn mockups can create new possibilities to explore. Small steps into the unknown are better than no steps at all.

Stop looking for solutions

Webmeetings that attempt to replicate their in-person inspirations are unlikely to ever afford the flexibility of in-person meetings, because they have fewer phenomena to orchestrate and we are never going to be as adept at using them. The gaps they leave for us to fill are smaller, and our capacity to fill those gaps is less well-developed. However, digital systems can provide a great many new and different phenomena that, with creativity and inspiration, may meet our needs much better. Without the constraints of physical spaces we can invent a new physics of the digital. As long as we treat the problem as one of replicating meetings then it makes little difference what we choose: Zoom, Teams, Webex, Connect, BBB, Jitsi, whatever - the feature set may vary, there may be differences in reliability, security, cost, etc but any of them will do the job. The problem is that it is the wrong job. We already pay for and use at least three major systems for synchronous meetings at AU, as well as a bunch of minor ones, and that is nothing like enough. Those that begin to depart from the replication model - Around being my current favourite - are a step in the right direction, while those that double down on it (notably most immersive environments) are probably a step in the wrong direction. It is not about going forward or backward, though: it is about going sideways.

It is not too tricky to experiment in this particular field. For most digital systems we create our decisions normally haunt us for years or decades, because we become locked in to them with our data. Synchronous technologies can, with provisos, be swapped around and changed at will. Sure, there can be issues with recording and transcripts, there can be a training burden, contracts can be expensive and hard to escape, and tech support may be a little more costly but, for the most part, if we don't like something then we can drop it and try something else. 

I don't have a solution to choosing or making the right piece of software for AU's needs, because there isn't one. There are countless possible solutions, none of which will suit everyone, many of which will provide parts that might be useful to most people, and all of which will have parts or aspects that won't. But I do know that the way to approach the problem is not to have meetings to determine business requirements. The solution is to find ways of discovering the adjacent possible, to seek inspiration, to look sideways and forwards instead of backwards. We don't need simple problem-solving for this kind of situation (or rather, it is quite inadequate on its own): we need to find ways to dream, ways to wonder, ways to engage in the act of creation, ways to play.