Draft - Ease of Use and Difficult to Learn

draft of work for GPACW 2015 addressing issues of ease of use - intuitive - and its relation to learning and augmentation.

pushing back against ease of use. gimme friction.

I have two aims here: one is to alert the conference to FedWiki, some of its operations, and a couple of its main minds. The second is to use this moment with the introduction of FedWiki to re-consider ease of use and how it might short-circuit learning.

Look around at the assumptions that the Most Important Thing is ease - effortlessness, intuitive (natural and inevitable - and so more authentic), as though something designed for complexity is somehow less trustworthy because more demanding of the user.

That is, we see in the ease of use idea - a marketing move as much as a design one - a parallel to the tl;dr. Short and easy to consume is Just Better than something worth reading. More trustworthy because (implicitly) free of nasty rhetoric.

Never mind the seeming paradox that apparent ease of use conceals the underlying complexity of the work, and it conceals the ideology at work behind the interface - a parallel to marketing, administrative, and political rhetoric used to accomplish the same thing.

Bernstein on Design

Podcast of Bernstein on TBX including comments on facility and east of use. podcast

Not intuitive but powerful B, from his podcast: Some software should be intuitive to use, but others aren't - and oughtn't. "Sometimes [the task] really is rocket science." Sometimes the task is really difficult and difficult to learn. There's no reason to think that tools for kind of task are going to be easy to use. It took years to learn how to use a book. "Sometimes things really are difficult."

Making a shopping list that you and others can use, for instance. Making a list might feel easy, but it's a cognitively difficult task we've become more or less practiced at. There's no reason to think that a piece of software is going to make the task easier w/o making it too rigid for practical use. Simplifying the software doesn't simplify the task. We might want it that way. We are often promised that. But it does't work that way. The homey, the mundane are hard stuff. Even a shopping list is a lot to do:

"We valorize usability, or onboarding. The first use [of a piece of software by a user] does the program demo, can we learn to use it right away? We have recently valorized extraordinary minimalism - programs stripped of all functionality so they are easy to use. But often we do need functionality, because we’ve got a lot to do."

Bernstein on the intuitive and unintuitive in TBX:

"When did it become my job to make software that is intuitive? Tinderbox isn’t software for opening doors or checking into hotels; it’s a professional tool for people who are undertaking extraordinarily complex research. (Other people use it for other things, and of course some of those researchers don’t regard their work as extraordinarily complex: it’s what they do.)"

"It’s not our job to make it easy. It’s our job to make it possible, if we can, or to bring it closer to the realm of possibility than it was before." blog

We need software designed for powerful augmentation rather than using intuitive first use as a design guide.

break

Fed wiki is a different animal, one that in its conception challenges current trends in east of use, seamlessness, and the intuitive interface. The underlying issue is that the demand to be seamless and intuitive means removing complexity that can be leveraged into learning.

Let's look at what Doug Englebart and others have to say about intuitiveness and augmentation.

In addressing these challenges, FedWiki harks back to NLS and Doug Englebart's ideas of augmentation.

With NLS, Englebart created a system that was not initially easy to use. The interface had to be learned - not just the computer interface but the new input devices: a mouse and chording keyboard, along with the sill-klunky querty keyboard. Along with the interface, so we would have to learn conceptual moves and strategies.

It's unlikely that many of these strategies would have occurred to users of the old system of pen and paper. I'm thinking here of Englebart's grocery list. On paper, we made the list and went with it. But when it's on the screen, we can think with it. We can consider re-arranging the items, categorizing them, re-ordering them - all of which generate new meanings from the list and new means and meanings of grocery shopping.

This little example suggests that the augmentation of the intellect comes in part if not in whole by way learning the software. Not because the software is difficult to learn but because we're also learning how to augment the task at the same time. Learning new software sets up the potential of augmentation.

Mike C observes that Englebart's grocery list illustrates an early idea of software openness that we might want to recover. post

The STC notes how Englebart demoed a "simple hypertext" that illustrated on how the computer could be incorporated into everyday life. page

Even the Daily Mail, on the occasion of the 2014 opera, sees the demo as recapturing the computer's connection to daily, even mundane, use. page

Not the first time military equipment has been used ... or misused ... for the everyday augmentation of the intellect. The Internet Apocrypha tells us email was immediately used for social exchange rather than confined to military and research tasks. Two of the first listservs were SciFi and Recipes. Social entertainment drives media.

More, Kittler rests part of his theory of media development on the idea. Read any of his works and it pops up regularly. Thomas Goldstrasz and Henrik Pantle provide an overview. War and misuse make for new media. Troops in WWI trenches used the military wireless to broadcast records and read out newspaper articles. The drive for an entertainment industry was born. page

But, really, $4m in 1968 dollars for a grocery list? Except it's not about the grocery list. It's about the augmentation.

Grounding the computer in the mundane is augmenting the everyday. Broadcasting your records and reading out local newspapers for distant neighbors augments the human ear. I'm going a little McLuhan here, but he's involved. So, yeah: $4m for a shopping list is just the start.

Seamfulness

We want seams. We need to see what's being stitched to what. We need to see the edges. Eliminate the seams and you won't know where you are. All becomes grey. Middle. Cut of the same cloth. But the world isn't cut of one cloth, and part of learning is learning to work with coats of many colors.

In this educational world, that coat is made up of many interfaces, applications, for many different processes, approaches, and ways of understanding.

Seamlessness is another way of privileging ease of use over understanding. Appropriate, as Mark B points out, in using an online booking site. Less so when doing the hard work of thinking and learning.

Learning new software sets up the potential of augmentation

When learning a new piece of software, we can become sensitized to our practices. Perhaps the software gets in the way of how we have learned to proceed. Perhaps it resists our easy movement forward. Perhaps we have to stop, shift attention to figure out how to do something we have assigned to motor memory. We can be frustrated or we can see that our way of doing something has become a habit, one that's being challenged by the new software.

But that's a good thing because it opens alternative ways of doing things, and even more, alternative things to do, alternative directions to proceed. That's work for the learner, but that means learning. It needs scaffodijg, sure, but that's very differemt thatn reducing the friction as ease of use.

Now look at augmentation.The idea is that the new learning is not just a new way of doing something but an augmented way of thinking. Not just new, not just better, but augmented. Augmentation starts by seeing habitual ways of thinking as habits - unconsidered, ways that have become naturalized. Ways that we confuse with natural, meaning unlearned and so not relearnable.

topics as titles

The question becomes, Given new affordances in FedWiki, how do we re-think what's possible in taking notes? That is, the topic, which was implicit in the WikiWord, is not necessary nor habitual in FedWiki. So what systems and strategies arise? What do we start to present as New Conventions of FedWiki?

An example in FedWiki. The traditional wiki tends to be organized by topics. I put this down in part to the WikiWord, which encourages topical titles. but it also is a function of indexing - topics make pages and specific info findable. And it may be a function of the kinds of projects that find their way to traditional wikis: encyclopedias, documentation ... And, certainly, it's in part a function of the shared singularity of the traditional wiki. the users - readers and contributors - coalesce around a set of commonplaces - topics - that they co-operatively define and refine in their shared creation. Makes sense. Those shared topics - commonplaces - provide the co-operative group with a shared set of terms, values, views. At the same time, there's a sense of how the topic constrains the group into a singular understanding rather than a plurality. Writers tended to create multiple topics to articulate the multiple perspectives. WhyWikiIsGood spawns WhyWikiSucks, which illustrates the heuristic value of topics.

But if the wiki base isn't shared but distributed, this need of topics as commonplaces changes. It might disappear. Commonplace might become something like ideoplaces. The title certainly takes on more functions. and less regularity.

We can see this happening in Teaching Machines when some posts that begin as subjects - example - spawn topics - example-as-gender.

So titles in FedWiki can become more attuned to the context in which they are being used, more attuned to the content of the node, more divergent throughout the wiki. They still help locate material but because that material can readily be mined for another's wiki, there are new reasons for titling. Do we want to point back to the source? Include the original title (better: title and first para, as in a reference) in the new node. FedWiki even distinguishes between including an inline link to the original and dragging the title and first para into the new node. Do we want to re-work the node while keeping the original title? Do so. Do we want not to? Fine. The history comes with the stuff we appropriate.

All of which is to say that FedWiki is all about modding and repurposing.

modding and repurposing

Modding and repurposing doesn't demand stylistic regular but boy does it help.

Mike C's request for a fedwiki style guide is embedded in sharing:

"If you want to get included in the main Wikity feed, you should read the Wikity Style Guide and abide by most of it. We're not style fascists, but since this is one big wiki to readers we owe them a somewhat consistent experience." page

I wouldn't call it a "consistent experience" - that can't be guaranteed by any means - so much as "expectations of regularity across pages". Or, another way, "Make the style consistent and it will start to appear neutral. We won't notice it anymore. Place the emphasis on the difference of content, not formatting style." Or "Make the style transparent and the content will stand out." But no matter. The idea is to write to be shared - and to make sharing easier, use the bare bones of a style guide in constructing content.

Set that aside and let's look at modding and repurposing even poorly formatted content.

You fork the page, or start a new one and drag stuff into the new page. ...

consider as augmentation - the interface as instrument, as in Imogen Heap's gloves. Here, the gloves become an instrument and using the interface is the essence of making the music. This is the kind of connection between interface and work I'm thinking of.

scrap

https://youtu.be/mme0T6XOWQs

https://youtu.be/mme0T6XOWQs

http://www.buzzsprout.com/29188/213217-5-mark-bernstein.mp3?client_source=small_player Bernstein podcast interview

Pattern Language

In "Wiki as Pattern Language," Ward and Mehaffy review how pattern languages were developed by architect Christopher Alexander as a way to address increasingly complex problems w/o being restricted to existing formal structures. Complex problems needed new solutions, and to create those solutions meant re-thinking the problem space. [link here]

In rhetoric, we use patterns. We call them the topoi, and use them as an architect might use design patterns to explore the problem space.

We might helpfully view patterns as heuristic - a method for invention.

The connection seems to be more than accidental. About the same time that Alexander was developing his pattern language, Young, Becker, and Pike were developing tagmemics - a systematization for invention that draws on the vernacular and places it in a system that can bootstrap invention. And Kuhn was re-thinkikng the scientific paradigm, and the Beatles were re-thinking concept albums with Sgt Pepper, and Frank Zappa re-making rock music, just 10 years after its birth ... But that's out the realm.

Ward points to the connection in a number of places: "Alexander observed that something similar does happen in human language - and indeed, in the design processes of vernacular cultures, where “patterns” were identifiable elements of design. This formed the basis of a new design method that mimicked the features (and recaptured the usefulness) of previous vernacular methods." And "In essence, pattern languages are clusters of elements that form a solution to a problem, and that tend to recur in a pattern-like way." and "Cunningham was intrigued by the capacity of language, in its very ambiguity and economy, to serve more ably as a useful working model for problem-solving. A problem is, by definition, not pre-decomposed into simple functional units, but as Alexander noted, has many overlapping and ambiguous connections. Language mirrors this capacity, and therein lies its usefulness." And "This generation refers to the capacity to reproduce the essence of a functioning structure without having to specify all of its characteristics."

With this statement, Ward invokes the generative capacity of natural language based on double-articulation: "the genetic process is able to generate, and regenerate, an intricately complex structure from a relatively simple set of language-like instructions."

The heuristic capacity of language is here - in its double-articulation, and in the logic of analogy, like meets like, the wiki and a pattern language share, or make use of, the same capacity of double-articulation to generate possible solutions - to explore the problem space.

Openness and Difficult to Learn What makes difficult software difficult is openness. Openness means we have to draw in guides - constraints - from outside the software to make significant, meaningful decisions. So, in fedwiki, the interface doesn't cue me into how to link. I have to draw on social guides, define my purposes. TBX doesn't tell me when to use an adornment or how to organize a set of notes to help me make sense of them. I have to draw on the content actual and rhetorical concepts and strategies. DevonThink will suggest how to organize, but I need to know what I mean by the category terms that I have set up.

By comparison, the ISRS database is not open. It demands certain kinds of answers in certain places. ISRS is not easy to learn because the larger system it reifies is not simple. But it does provide guides for choices. Ditto Taskstream. It tells you what to put where. Reifies a communicative framework as The Only Framework Possible. It's a software bully. Not like TBX, dt, fedwiki.