The nature of technologies

By Jon Dron
Nov 21, 2011

All technologies are assemblies that orchestrate phenomena to some purpose (Arthur, 2009). They may consist of, use or embody tools that may be physical or conceptual or both. There are as much technologies of prayer as there are of steam locomotion (Franklin, 1999).

Soft and hard technologies

For some (e.g. (Bessant & Francis, 2005)) hard technologies are physical while soft technologies are human-mediated processes. For others (e.g. (Norman, 1993)), hardness or softness concerns technologies’ effects upon us. For others (e.g. (Zhouying, 2004)) soft technologies are the human factors that are necessary adjuncts of hard tools.

I offer a consolidated definition: what makes a technology softer or harder is the degree to which the orchestration of phenomena is actively performed by a human or humans.

Harder technologies involve fewer human mediated processes because they embody them in tools and toolsets. Harder technologies tend to be more constraining and authoritarian while softer technologies tend towards creativity and flexibility. Thus, softness and hardness lies both in the effects of technologies and in their constitution..

Soft technologies are flexible and needy

Soft technologies are flexible, supporting creativity and change, because the gaps inside them have to be filled with processes constructed by people. They are needy and incomplete until people fill the holes.

Hard technologies are rigid and complete

Hard technologies contain within them the processes and methods to achieve the ends for which they were designed. This brings efficiency, scalability, replicability, freedom from error and speed.

Human processes can be hard too

People enact some hard technologies, such as legal systems or machine operating procedures. The orchestration of phenomena is enshrined in rules and processes that may not be overridden.

Expanding the adjacent possible softens the overall system

As complex systems evolve they expand the adjacent possible (Kauffman, 2000). This is equally true of technological systems (Johnson, 2010). Because old technologies are seldom if ever fully replaced (Kelly, 2010), new technologies expand the adjacent possible within an entire system even though a particular new technology may be hard. This will be little consolation to those forced to use that hard technology, however.

Aggregation makes technologies softer

When one technology is assembled with another, the adjacent possible that the first technology provides remains but is augmented with further adjacent possibilities. Aggregation, even of hard technologies, is a means of softening a technology. Consequently, automation does not necessarily make a technology harder: automated parts, when assembled, make a technology softer. Oddly, the more we assemble our technologies, the more needy and incomplete they become.

Replacement makes technologies harder

When we replace part of a technology with something harder that technology will become harder. Adjacent possibilities are taken away and replaced by something that offers fewer of them. Softer technologies can in principle replace harder ones, thus softening the whole assembly, but this rarely happens.

Soft is hard, hard is easy

Harder technologies make what they automate easier for humans using them, because no additional orchestration is needed, whereas softer technologies, demanding human orchestration, make things harder.

Hardness and softness is a continuum

Purely hard or soft technologies are rare. Technologies tend to be assembled from both soft and hard parts. leading to a soft-hard continuum

It depends on your point of view

Hardness and softness are not innate characteristics of objects and processes. The same objects and processes are different technologies when they are used for different purposes and orchestrate different phenomena. A sales terminal is soft to its programmer, hard to a sales assistant.

Unequal mutual influence

Hard technologies tend to influence soft technologies more than vice versa because soft technologies can adapt more quickly and easily than hard technologies. However, through assembly, soft technologies can bind together different hard technologies to make an overall system softer.

No innate preference

Pedagogies are technologies (Dron, 2009). Harder learning technologies may harmfully constrain the softer pedagogies with which they are assembled or harden a conflicting pedagogy. Softer technologies increase opportunities for failure, inefficiency and sluggishness, and may be difficult for learners who must not only learn the subject of study but must also become part of the technology through which they learn. Neither is ideal for all occasions.

Learning technology design

Structural constraints of hard technologies and inefficiencies of soft technologies deeply affect learning. We should therefore build systems that can be as soft or hard as needed. The most effective way to do this is to enable easy assembly of hard technology components. The challenge is how to do that effectively.

The elephant in the room

Soft technologies need skill and artistry. It ain’t just what you do, it’s the way that you do it. A bad technology, used well, can work brilliantly, while a good technology, used badly, can be useless. Most learning technology research concentrates on technology (including methods and pedagogies) not the talent and skill with which it is applied that is frequently more significant. The challenge is to devise research methods that capture this usefully.

References


Arthur, W. B. (2009). The Nature of Technology: what it is and how it evolves. New York, USA: Free Press.
Bessant, J., & Francis, D. (2005). Transferring soft technologies: exploring adaptive theory. International Journal of Technology Management & Sustainable Development, 4(2), 93-112.
Dron, J. (2009). Pedagogies as Educational technologies. Paper presented at E-Learn 2009, Vancouver, Canada.
Franklin, U. M. (1999). The Real World of Technology. Concord ON: House of Anansi Press.
Johnson, S. (2010). Where good ideas come from: the natural history of innovation. New York: Penguin.
Kauffman, S. (2000). Investigations. New York: Oxford University Press.

Kelly, K. (2010). What Technology Wants. New York: Viking.
Norman, D. A. (1993). Things that make us smart: defending human attributes in the age of the machine. Cambridge, MA: Perseus Publishing.
Zhouying, J. (2004). Technological progress in history: a survey of evolution and shift of research emphasis from 'hard-tech' to 'soft-tech' development.. International Journal of Technology Management & Sustainable Development, 3(2), 133-148.

Readings

Top 5 Reading for the time-poor

Jon Dron:
The neediness of soft technologies:

https://landing.athabascau.ca/pg/blog/read/65996/the-neediness-of-soft-technologies
Orchestrating soft and hard technologies:
http://www.slideshare.net/jondron/orchestrating-soft-and-hard-technologies-3059238
Learning analytics, soft and hard
http://www.slideshare.net/jondron/learning-analytics-soft-and-hard
Kevin Kelly:
Immortal technologies:
http://www.kk.org/thetechnium/archives/2006/02/immortal_techno.php
Why the impossible happens more often:

http://www.kk.org/thetechnium/archives/2011/08/why_the_impossi.php

Activity: Designing a soft technology


Provide at least one possible educational use for an unenhanced standard email client such as Thunderbird or Outlook Express that requires nothing more than that email client and its usual supporting infrastructure (network connection, operating system etc are fine, but no other distinct applications like web browsers, word processors, shared storage, listservs, schedulers or calendars). Provide this in a form that may be aggregated with grsshopper and shared with others on the MOOC.

The intention here is to focus on what phenomena are being orchestrated to what purpose in each case and (most importantly) how that orchestration occurs. The more complex, bizarre, interesting and ingenious the ways of using these better.

Here are two simple examples of the kind of thing I have in mind and an appropriate format. Neither is particularly good and both could definitely be improved or refined:

Use:
A scheduling system, e.g. for class meetings


Phenomena:
The email client's capability of sending messages to multiple people and for it to be used to reply to all, the ability to show a subject line, the ability to identify individuals to which it has been sent, the ability to find, store, sort and organise messages

Orchestration:
Participants should explicitly or tacitly agree on information that must be included - at least date and subject and perhaps type of meeting, and that may be included - time, place, details, agenda, RSVP etc. The cc list will be used to identify others invited. If a response is requested, invitees should respond. The subject line should contain the key information for ease of filing. Those attending should use their email folders and/or use the client's search facilities to maintain a record to identify when meetings will occur. The organiser should keep replies in a folder or use search/ordering to keep tabs on who is and is not attending. A recognisable form of regrets/apologies for non attendance should be used and/or confirmation of attendance - ideally, wording like 'accept' or 'regrets' will be added within the subject line itself, perhaps appended to the end of the subject line, so that the organiser can manage the attendee list more easily. The organiser should ideally explain all of this in the invitation.
(more sophisticated email clients could use vcal or ical attachments, integrate with built in calendars and so on, but that is outside scope, as is the use of a listserv)

Use:
An assignment submission and marking system.

Phenomena:
The email client's capability of sending and receiving messages, the ability to send to multiple individuals, the ability to show a subject line, the ability to identify individuals to whom mail has been sent and from whom mail has been sent, the ability to find, store, sort and organise messages, the ability to add MIME attachments, the ability to time-stamp a message.


Orchestration:
Students are sent an email explaining the assignment requirements, giving a final hand-in date/time, expected format, and other information relating to that assignment, as well as a description of the process (as follows). The message is cc'd to the tutor who moves it to a folder that will record the complete assignment process from start to finish, including any related correspondence.

Students are required to send a reply to the tutor to confirm that the message has been received (the tutor uses search and/or folders to match sent items with received responses and re-sends if none is received). At the hand-in date or before, students send their work (they may attach images or other files that can be displayed within the tutor's email client, as specified), and provide a subject line according to a specified format that includes their student number and the name of the assignment.

They send the work to the tutor, who sends a reply to confirm that it has been received. If students do not receive the reply then they resend, forwarding the original from their sent mail, thus providing some proof that it was sent when they claimed it was sent. The tutor stores the emails in a subfolder for unmarked work in the folder for that assignment and/or flags or stars the emails (or simply marks as unread) to track whether or not they have been marked. He or she opens a new email message, which will be used to store the aggregated marks and saves it to the drafts folder.

As he or she opens the emails and marks the work, he or she sends a response to the student providing feedback and a mark for the assignment. If work is sent after the hand-in date (discovered from the time stamp of the email), the tutor applies whatever penalty is required. The tutor moves marked email to a 'marked email' subfolder and/or unflags, unstars or just leaves the email to be automatically marked as read. Once the marking is finished, the tutor sends it as a self-addressed email with a subject line of 'marks for nnn assignment' which is then stored in the same folder as the student work itself.

Comments

Your Comment

You can preview your comment and continue editing until you are satisfied with it. Comment will not be posted on the until you have clicked 'Done'.



Enter email to receive replies: