Wikis were designed with simplicity in mind: The writing space is minimal – a text field. The controls are pedestrian – Edit and Save. The formatting is fundamental – Type to enter text, hit return twice to create paragraphs. Use equal signs or hash signs for headings, slashes for emphasis, enclose links in double-brackets, or just paste in URLs. The tools are basic – Create and link new pages by using WikiWords.
The writing space is easy to read, and creating pages is simple so that you can focus on writing.
Navigation and page management is also stripped down – Use the PageIndex to see what's on the wiki, use RecentChanges to see what's new, and use the all-important PageHistory to look at previous versions of the page.
Wikis don't demand that you write in a particular way, but they don't give you any guidance on how to proceed, either. Wikis are very different writing spaces than weblogs and paper notebooks, and to make the most of them, you may need to learn some new moves, some of the new media literacy skills Kyle Steman mentions. Wiki users have developed some general practices for writing on wikis. This article will help you get started developing your own techniques, whether you use a wiki collaboratively or on your own.
Wiki articles develop over time and often by multiple hands. So the idea of a wiki is to keep things centrally located – all in one place. Notes, the developing draft, and discussion on the draft are all posted in one place. Everyone's on the same page, everything is always current, and additions and changes and deletions are played out on the page itself.
If you're working solo, the centrally located draft is a benefit. All your notes, considerations, and sections of developing drafts are all in one place. And what you're working on is always the most up-to-date material. You access it from any device, you can recover earlier drafts using the Page History, and that means that you can move in and out of drafting and refactoring easily, without shuffling through versions.
The WikiWord is central to using a wiki. WikiWords – more accurately, wiki phrases – are created in traditional wikis by using capital letters in the middle of the phrase or word, as in WikiWord, or CamelCase, or MyGreatIdea. The wiki treats a phrase in CamelCase (as this move is called) as a potential page name and a link to that page. That means that you, as the writer, treat a CamelCase word as a topic: A point of interest to be developed, a path to create, an idea, problem, issue, concept to think about. On any page, create a WikiWord to start a new page.
WikiWords are powerful because the WikiWord is both the title of the page and a link to that page. Once created, using the WikiWord anywhere on the wiki will link to that page, and that allows you to cross-reference any page from any other page.
Some wikis are not set up to use CamelCase WikiWords but require another way to indicate a WikiWord, such as double square brackets. While there are good reasons for this, there are better reasons for using CamelCase to designate WikiWords. If you're setting up your own wiki, use CamelCase to encourage you to keep your WikiWords concise.
Wiki writers have developed ways of working from notes-and-drafts-and-discussion-all-in-one-page to everyone's advantage. On a wiki, rather than thinking in terms of writing a draft, think of moving from a set of loosely connected notes towards a more formal document. In wiki terms, drafting is moving from ThreadMode to DocumentMode.
ThreadMode is a dialogue: It is open-ended, collective, dynamic, and informal; it can develop as a page or develop on a page, but it develops organically, without knowing where it's going.
ThreadMode is tentative rather than absolute; opinionated but not seeking closure; exploratory and so seeking light rather than winning ground. ThreadMode writing is grounded in specifics to make sense of abstractions. Its end is to help others understand and create, not to win. It's an attitude.
The tone of ThreadMode is not off-the-cuff, sermonic, or preachy. ThreadMode may be informal but it is public thinking: designed, considered, and polite. ThreadMode presents a position, a way of understanding, and presents it clearly and persuasively.
Rather than replying to a discussion entry, the writer can refactor the page to incorporate the suggested change, then delete the comment. ThreadMode slips delicately into DocumentMode.
If you're collaborating with others, keep ThreadMode going by phrasing contributions in first-person (using I) and signing them. Place comments and additions near the material they address rather than simply placing them at the end of the exchange.
Contribute in ThreadMode by
DocumentMode is more formal, more like an endpoint. It's expository, essayistic. It's a semi-formal synthesis of the ideas brought out in ThreadMode. To develop in DocumentMode, draw on ThreadMode material. Arrange it, summarize it, counter-point ideas, edit the sentences for clarity and tone. That is, refactor ThreadMode material.
If you're working with others, develop the DocumentMode text in third-person and remove the names of contributors. (Place the names of all the contributors at the bottom of the section.) Add WikiWords to the text where concepts seem to open to new pages. Cut material you've used (it's recoverable if necessary), and move material that still needs to be incorporated to a place on the page for notes, below the DoubleLine.
Contribute to DocumentMode by
Use a DoubleLine to distinguish between the stuff in ThreadMode and the stuff in DocumentMode. You could use formatting, sidebars, a suggestion, and approval area, but all of that slows things down. In keeping with the WikiWay – quick and simple – wiki writers use a DoubleLine near the bottom of the page, typically created by typing two sets of hyphens to create a horizontal rule. Material above the DoubleLine is in DocumentMode; material below is in ThreadMode. This doesn't mean Finished/Unfinished. It's more like palette and canvas, or raw material (ThreadMode) and developing work (DocumentMode). It means placing material that is more fully formed and ready for further work above the line, while adding notes, roughs, jottings, headings without content, fragments of lists . . . below the line.
In either mode, use WikiWords to indicate further options for development. Add a new WikiWord, or combine a few words already in the text to create one as a way to signal, "This is an alternative direction".
Use headings and lists in either mode to help you organize stuff as you work. Know that everything will change as you move from ThreadMode to DocumentMode.
Refactoring is how wiki writers move from ThreadMode to DocumentMode. They refactor. The term comes from computer programming, where it specifies re-working code to be more efficient and effective. Programmers will often rough out a procedure on the fly, without much planning, just to get something working, and to get a sense of what the procedure will entail. Later, as they work though the rest of the program, they return to the procedure to rethink it, make it more efficient, faster, requiring less processing power and less cognitive overhead for other programmers to understand, while retaining the same functionality. By refactoring, complex steps can become one or two elegant steps. A long chunk of documentation explaining the procedure becomes a single line. The procedure itself becomes modular, reusable elsewhere.
Composing on a wiki can take advantage of the same working practices. Abandon involved planning. Instead, rough something out that just sort of works. It doesn't have to be elegant; it doesn't have to work well; COMMA but it's enough of a start to refine. It will be wordy, with lots of noise that will have to be cut out. It will wander. But it's on the page where you and others can refactor it. It may be above the DoubleLine, or below, closer to ThreadMode or DocumentMode.
In refactoring writing, that 250 word proto-paragraph might become a single sentence, even a single clause – something more efficient and effective and elegant than the ThreadMode freewriting and wandering. But that's what DocumentMode is: Prose refactored to effective high efficiency. Writing with a high signal to noise ratio. Writing that relies on every comma, word, clause, phrase, sentence. Writing that is well-wrought to make reading closely worthwhile.
Wiki pages use headings to signal the organization of the page. Wiki writers use headings and lists to generate and roughly organize material in ThreadMode, and to guide refactoring into DocumentMode
Create headings to suggest where ThreadMode contributors might add ideas and directions they might take. Use headings to reorganize sprawling threads so writers can readily review what's developing. Use lists to quickly gather brief examples, points, possibilities, comments, ideas that will be developed in refactoring.
For refactoring, use headings to organize the page. Review the threads to discover an emerging pattern for the page. Gather material under the headings and refactor it to suit the head. If a pattern isn't working, create new headings, try a different pattern. Use alternative patterns to refactor further.
For instance, a ThreadMode might be made up of a set of arguments. As you read through them, some seem to be for the matter at hand and some against. In good refactoring, start with two heads: Pro and Con, or For and Against. Then as you collect the ThreadMode material under the heads, you can refine the headings to suit the developing material. Pro and Con might become Strengths, Weaknesses, Complications, Views to Consider Further. This might be called RefactoringByHeadings.
A proto-paragraph in ThreadMode might be refactored as a heading, saving 250 words for content rather than an unnecessary transition paragraph. Many paragraphs are lists in disguise and can be refactored into a bulleted list – one that is then ready for more development. Refactoring will signal whether the points need more development or not.
While headings have not been common in much expository and argumentative writing, they ought to be – for effectiveness and efficiency both in writing and reading. You can use headings as you draft and refactor, and cut them when you submit the final version.
Use external links to sources on the web to document your topics. Use WikiWords to link to related topics and documents elsewhere on the wiki: other topics, alternative pages, revised versions, a variety of lists of topics. Internal linking using WikiWords becomes more valuable over time, as you build an expanding set of topics and notes. The mechanics of linking is handled by the wiki so you can concentrate on making sense. This takes effort over time, but the payoff is worth it.
Wikis were designed to support collaborative work by not getting in the way of collaboration. But the writers - whether one or a thousand – have to incite and manage both the writing and interactions between writers. This is where ThreadMode and DocumentMode come into play to help direct attention and work. If you're collaborating, here's how to proceed.
Choose a leader for the project or the page. Everyone starts in ThreadMode. The leader might set the goals or start the page with a note at the top, but everyone is involved in sketching out ideas, responses, notes. Talk to each other on the page. Phrase ThreadMode exchanges in first-person.
After you've developed a mess of notes and directions, the leader can start drafting those ideas into DocumentMode: summarizing, combining, concatenating, rephrasing, collating. Everyone joins in. Phrase DocumentMode text in third-person. When you incorporate material from the thread, cut what you've used. When something needs more development or discussion, add a note to that effect, or move the point below the DoubleLine.
Then continue the ThreadMode discussion. This time, others can start to comment on the evolving DocumentMode text. Even better, others can start to edit, tighten, check, and add directly to the DocumentMode text. Use headings to signal the organization of the page. Signal topics for further and alternative development by creating WikiWords. If you have a point to add, just add it. Others will see it and may develop it further, refine it – or perhaps eliminate it.
If a discussion on a point breaks out, move the discussion below the DoubleLine to indicate that it's active.
Keep up the pace. Have everyone return to the page two or three times a day. Find out what's changed using the RecentChanges command. The more quickly things move, the more energy you gain to refactor threads into DocumentMode.
Continue until you've reached a stopping point. If there is more to develop, leave the notes below the DoubleLine.
Wikis were originally designed for collaboration, but they famously support one writer writing for multiple courses and projects. The wiki process for composing – ThreadMode to DocumentMode by way of refactoring – works well for one person working because it helps you keep track of where you are in the process: what you've done so far, and what you might do next. Use the wiki as a notebook. Keep class notes, ideas, notes for projects, and observations all in one place. They will be there when you want to develop them further. Use the PageIndex and RecentChanges and the search function to find things.
Create an index page for a major project, and keep links to your notes, sources, and drafts, on that page, like a table of contents.
Think of your wiki as a notebook, one you expand, re-organize, and refactor over time.
Source: Writing Commons, https://writingcommons.org/article/think-rhetorically/
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 3.0 License.