Introduction and overview

I'm preparing a couple of upcoming presentations in the US and Netherlands in which I and others be talking about the design of social technologies such as the Landing. I have come up with a couple of small incremental insights that I think are worth sharing and that help in understanding what I mean when I talk about soft and hard technology design. This is as much to help me get my thoughts in order as to share a finished piece of work, so comments are welcome if you can disentangle what I mean from the following...

The first small insight is that the shape (structure) of systems in time and space leaves holes: systems are as much about what they exclude as what they include. A jigsaw is a poor analogy as it complete ignores dynamics and the temporal dimension, but I'll use it anyway to help visualise the kind of thing I mean:

The second insight (more a corollary really) is that, if systems do not do precisely what we want, then we have to fill those holes. We can either extend our system boundaries (difficult) or use other systems to fill the gaps. If the pieces we use to fill them overlap beyond the boundaries of the holes, that is usually a bad thing - confusing, inefficient and messy.

If the pieces are smaller then it is often easier to fill the holes, but harder to manage the soft and fuzzy boundaries of the pieces with which we fill them. The little gaps must be filled with soft technologies, human-mediated processes, in order to be made to fit.

We are therefore seeking a process of design that allows us to fill holes with other systems of just the right size, shape and consistency: not too hard, not too soft.

Goldilocks systems, if you like.

The shapes of systems

Systems are about bringing shape and structure to time and space. When we systematise things, we deliberately and intentionally draw boundaries in space-time that separate our systems from the rest of the world. In other words, by designing something we, at the same time, create a line between our creation and the nega-system in which it resides: that is to say, not everything outside the system, but the parts with which it can and may interact, interface or align with. In fact, if we had a large amount of time and energy, we could fully describe our system in negative terms of what it is not: the gaps in time and space that it leaves unfilled. Those gaps are important. They are, often enough, unfilled holes. If we have got our design even slightly wrong, they reveal themselves as at best irritations, at worst frustrations for the people that use them.

This is particularly true of harder technologies (those that contain more of the orchestration of phenomena that they harness embodied within them). Typically, such technologies are designed to fulfill a fairly specific purpose: a learning management system (LMS) is built to help create and present learning materials and activities, for example, in order to help other people within a particular limited range of contexts to learn something. The tighter the purpose, the harder the technology, the fewer choices it provides to its users. LMS authors perceive a softer system than LMS learners, on the whole, but both are deliberately constrained in their actions because that's how it is designed to work. Without such constraint, it would not be a very useful system, people would have to make more choices and work considerably harder to achieve much the same result. The harder the technology, the fewer choices are needed and the easier it is to use. Hard is easy. However, without the constraints, people would have considerably greater flexibility to do what they want.

Contrast this with a less purpose-specific technology such as email. Email's purpose is communication across time and space. That's about it. There are no obvious limits on what kind of communication, for what reason, for what ends, that email might be used for. That makes it an inherently softer technology - we can can use it for a potentially infinite range of purposes because its function is so simple yet so embracing. The orchestration of phenomena that it provides (such as the capacity to send a message over any distance to an individual or group, or the ability to include an image or sound, or the flexibility of the subject line to convey meaning) can be mediated by humans to achieve myriad different ends: a scheduling system, a coursework submission system, a filing system... whatever. It can even be used to send messages. As a thought experiment, I have long toyed with the idea that it could, with a lot of effort and a little compromise here and there, be made to do exactly what an LMS does. However, it would be so difficult and rely so much on humans doing things machines can do better, more reliably and in a more trustworthy fashion, that it would rarely be worthwhile. And that's the trouble with soft technologies: soft is hard.

Softening systems

So, a system (and all technologies are systems) has a 'shape' (metaphorically speaking) in space and time that leaves gaps and holes that delineate it. If we wish to change what that system does to enable it to do more, to go beyond its boundaries, we can do one of two things:

1. change the shape
2. combine it with other shapes

Changing shapes

Changing shape tends to be much more difficult than assembling pieces in most systems, at least partly because it requires us to think about the internal structure of our system and the effects of a single change on other pieces. There tends to be a lot to juggle. It is especially hard in a multi-user space, where designers must balance many often conflicting needs and provide something suitable for all. The bigger the system, the harder that becomes. It is also very hard to undo changes without affecting many people.

So, the tendency in larger more monolithic systems is for slow development cycles, limited capacity to adapt without major disruption and multiple compromises. When such systems do adapt, they typically need to cater for their entire history of their development, trapped by path dependencies of their own making into carrying the baggage of generations of versions. Though not quite archtypal monoliths (nor is the LMS), think of Microsoft Word, or Microsoft Windows, that have only recently begun to break free from their 30-years of legacy and still retain vestigial growths to support their ancestral inheritance.

In many cases, where we are not the designers/makers, it can be virtually impossible to make significant changes. If I purchase a pre-built piece of proprietary software, for instance, I will rarely have the opportunity to change it beyond the customisations allowed by the maker. I will probably be caught in an upgrade cycle that will take away even more control, relying on a third party to make changes that may or may not suit me. That's bad. 

Assembly

Combining two technologies in order to make at least one softer is more promising and more flexible as a development methodology. If system A does not do X, then combine it with system B, that does. For example, if my learning management system does not have tools to (say) make a drag-and-drop match-the-picture quiz, then use a technology that does. The result is a softer overall system - more flexible, more controllable, more enabling of creativity.  However, successfully combining one shape with another assumes that we can make the two shapes fit together, without leaving holes and without adding overlaps. In real life, that tends to be difficult (though standards and standardized interfaces than help ease the pain). 

It's especially difficult if the systems we are combining are large, as the changes of them fitting together without holes or overlaps are very slim: it would be like taking two pieces of different jigsaws at random and hoping they would fit together.

If we make the pieces small enough, then it is possible to fit them together inside the gaps. Unfortunately, if the pieces are too small, that too is very difficult. Email is a delightfully small thing that can be made to fit many spaces in information systems but, because it is so soft and its hard parts so small, assembling it successfully with a larger technology often requires us to fill most of the holes with soft, human-mediated processes (though, again, intelligent use of interfaces and standards can improve things). For example, if my LMS insists on enforcing a strict submission date but I wish to give flexibility to my students, then I could ask students to mail me assignments that I will enter and mark manually. That kind of approach is difficult, slow, inefficient and prone to multiple errors all the way down the line. Soft, yes. But too soft. So, in the absence of alternatives, most of us toe the line and find ways to make compromises within the harder systems because, at least, they work reliably.

Aiming for the Goldilocks optimum

In a perfect world, we would be able to fit systems together that are not so large that they overlap, and not so small that they need more padding to fill the holes. And that is what we are aiming for with the Landing. The Landing is meant to be a hole-filler, a soft, malleable and controllable technology that can slip between and fill the gaps in other technologies at Athabasca University without being so soft that it takes more effort to use it than email. This design philosophy operates both at the whole-system level (it is built out of around 100 discrete plugins) and at the user-system level (its widget interface is all about assembly of small, functional, moderately hard systems).

We are not quite there yet.

Plugins for the system do quite often overlap, and some are too small, some are too big. Many of them have profound or subtle effects on others, so they are not quite independent systems slotted together so much as filters overlaid over one another, and you have to get them in the right order or weird things can happen.

At the user end if things, widgets are a great invention but they don't do everything, are only partially customisable, have to fit within fixed column limits, are only available in a limited range of contexts and only a few provide the means to connect to systems beyond the Landing.

Outside the widget space is a messy and over-chaotic or un-usefully structured space made of both tiny soft pieces and some big hard ones like blogs, wikis, bookmarks, groups, etc, together with their integrating and mostly inflexible interfaces. The Landing's social forms, its groups, networks and sets, are deeply intertwined and overlap in confusing and confused ways. It is really hard to get oriented because there is not much to kick against and the boundaries change wherever you find yourself. Either there is not enough structure, or the structures that are provided are not those that we need when trying to navigate around. It is too hard in the wrong places, and too soft in others. I speak as perhaps the heaviest user of the Landing and among its strongest proponents.

We are working on this. The next version of Elgg (the underlying framework) that we will add to the site provides far better usability across the whole system, with way more consistency, a better sense of context, clearer navigation and plenty of neat enhancements like auto-saving that make life more comfortable. However, the underlying deep problem is not soluble so easily: in making a space that can become so many things in so many ways to so many people, supporting so many social forms and that has no top-down structure to speak of, the best metaphor I can think of for navigating it is surfing a wave. It is certainly not much like finding your way with a map or orientating yourself by landmarks.

What we need, and what we are researching, is a more controllable, assemblable, customisable space that can be organized/can organize itself to provide the kinds of structures that people need, at the right scale, when they need them, in as painless a manner as possible. We'll be adding more and more tools to make that possible, from tabbed dashboards to smarter menus, to richer tagging, to more configurable group and personal widgets. We're hoping to get better search facilities too. 

The biggest challenge, though, is the big picture: the overall site organization. The last thing we need to do is to provide that organization ourselves as, because we would be systematizing structure, that would create more holes than I could count. On the other hand, we need to avoid chaos: systems that are too soft are difficult for almost all concerned. Through assembly, we can allow authors to have the softness and malleability needed to build spaces that are as hard or soft as necessary for their users, but they remain entangled and lost in a broader mess of different constructs. Now we need to provide the spaces in between so that they make sense as a whole - so the shapes fit together more easily and intuitively. Collective self-organization combined with a socially-oriented structural metaphor is, in brief, the main way we are thinking of going on that one, but that's another story for another time.