<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Writing&gt;Technical Writing&gt;Minimalism</title>	<link>http://tc.eserver.org/dir/Articles/Writing/Technical-Writing/Minimalism</link>
	<description>A listing of the most recently indexed works about Articles and Writing and Technical Writing and Minimalism in the field of technical communication (and technical writing).</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Articles&gt;Writing&gt;Technical Writing&gt;Minimalism</title>
		<link>http://tc.eserver.org/dir/Articles/Writing/Technical-Writing/Minimalism</link>
	</image>
	<item>
		<title>Duct Tape Technical Writers</title>
		<link>http://tc.eserver.org/35219.html</link>
		<guid>http://tc.eserver.org/35219.html</guid>
		<description>In reality, the user just wants a brief, clear explanation of a concept or task. The user will glance and skim — reading behaviors hardly worthy of the elitist grammarian who argues the finer points of “which” versus “that” in restrictive clauses.</description>
	</item>
	<item>
		<title>Sometimes, Simple is the Way to Go</title>
		<link>http://tc.eserver.org/35125.html</link>
		<guid>http://tc.eserver.org/35125.html</guid>
		<description>I’m advocating boiling the documentation down to the essentials. Remove any superfluous material. Tell the user how to do things with a piece of software or a gadget, not what that something can do. You might wind up with documentation that’s just a set of procedures connected together by linking material and cross references. Don’t bog them down with what’s not necessary for them to get things done in a fast and efficient way.</description>
	</item>
	<item>
		<title>Cut, Cut, Cut your Content and Procedures</title>
		<link>http://tc.eserver.org/34804.html</link>
		<guid>http://tc.eserver.org/34804.html</guid>
		<description>Sure. We’ve been reducing word count in procedures for some time. It’s time to do more, however. As noted in an earlier post, we have to think mobile. Think small screens and small devices. Screen real estate will be at a premium.</description>
	</item>
	<item>
		<title>Plain English</title>
		<link>http://tc.eserver.org/33329.html</link>
		<guid>http://tc.eserver.org/33329.html</guid>
		<description>According to Plain English Campaign (www.plainenglish.co.uk), plain English is &quot;… something that the intended audience can read, understand and act upon the first time they read it. Plain English takes into account design and layout as well as language.&quot; Many organisations have found that plain English brings commercial advantages.</description>
	</item>
	<item>
		<title>Reducing Complexity in Documentation</title>
		<link>http://tc.eserver.org/30561.html</link>
		<guid>http://tc.eserver.org/30561.html</guid>
		<description>With more emphasis being placed on customer satisfaction, technical writers need to focus on information strategies that will lead to happier customers. The complexity of the information is one common complaint of customers. Writers need to understand what customers think is complex. Then, writers need to develop strategies to combat these complexities.</description>
	</item>
	<item>
		<title>Get Rid of the Babble</title>
		<link>http://tc.eserver.org/30362.html</link>
		<guid>http://tc.eserver.org/30362.html</guid>
		<description>Try to rid your writing, especially business writing, of unnecessary words. They take up space, look impressive only to naive readers, and say nothing.</description>
	</item>
	<item>
		<title>Style That Economizes Mental Energy</title>
		<link>http://tc.eserver.org/29888.html</link>
		<guid>http://tc.eserver.org/29888.html</guid>
		<description>Perhaps the most important feature of good writing style for scientific and technical communication is economy: writing that reduces the mental labor of the reader or user. I describe the principle of &quot;conservation of mental energy&quot; as developed by Herbert Spencer and extended by later studies in readability and psycholinguistics. Stylistic techniques that make reading easier have powerful application to the prose crafting that sci/tech communicators do every day. The idea of conserving mental energy, or being &quot;efficient&quot; in communication, gives us a touchstone for thinking about good style and a rationale for explaining why it&apos;s valuable.</description>
	</item>
	<item>
		<title>The Nurnberg Funnel by John M. Carroll</title>
		<link>http://tc.eserver.org/29396.html</link>
		<guid>http://tc.eserver.org/29396.html</guid>
		<description>In the Nurnberg Funnel: Designing Minimalist Instruction, John Carroll presents some helpful ideas based on some useful research on how the initial self-instruction (often called &apos;tutorials&apos;) should be developed and written.</description>
	</item>
	<item>
		<title>Simplified Technical English: STC Should Take the Lead</title>
		<link>http://tc.eserver.org/27986.html</link>
		<guid>http://tc.eserver.org/27986.html</guid>
		<description>Proposes that STC become involved in brainstorming ideas about Simplified Technical English, thus leading the way for clear, correct documentation.</description>
	</item>
	<item>
		<title>Conciseness is Key to Good Technical Documentation</title>
		<link>http://tc.eserver.org/27488.html</link>
		<guid>http://tc.eserver.org/27488.html</guid>
		<description>One of the most important and difficult parts of technical documentation concerns writing in a concise manner. Technical writing is different than writing fiction or magazine articles, where a mood may be set or--in some cases--where space must be filled. (People seldom buy thin books.)</description>
	</item>
	<item>
		<title>High Tech Humor</title>
		<link>http://tc.eserver.org/25990.html</link>
		<guid>http://tc.eserver.org/25990.html</guid>
		<description>The remarkable growth of the information technology industry has created a tremendous opportunity for people with skill putting words on paper. Technical writers, once a rare and highly skilled position, are now as common as fruit flies—though they take up a lot more space. Yet the pay is pretty good considering how little work they actually do, so young English-major weenies desperate for employment continue to swarm around IT companies, hoping for a bit of rotting fru—er, looking for a plum position.</description>
	</item>
	<item>
		<title>Adopting Minimalism in a Corporate Environment</title>
		<link>http://tc.eserver.org/25126.html</link>
		<guid>http://tc.eserver.org/25126.html</guid>
		<description>Minimalism is more a methodology or set of principles than a set of measurable qualities. In order for your writers to move to a minimalist approach to documentation, you must be able to explain what you mean by the term and what you expect from your writers.</description>
	</item>
	<item>
		<title>Downsizing Documentation: Meeting the Challenge</title>
		<link>http://tc.eserver.org/24890.html</link>
		<guid>http://tc.eserver.org/24890.html</guid>
		<description>The redesign of the Microsoft Windows operating system along with a shrinking page count and Help file-size allocation, presented Windows User Education with a unique opportunity. We not only redesigned our entire documentation model, we also changed and improved our authoring tools. And, along the way, we changed how we did our work.</description>
	</item>
	<item>
		<title>The Zen of Minimalism: Designing a Top-of-Class Manual for Beginners and Advanced Users</title>
		<link>http://tc.eserver.org/24120.html</link>
		<guid>http://tc.eserver.org/24120.html</guid>
		<description>Can using minimalist documentation improve accuracy and learning speed for beginners as well as for advanced users? I tested this question using Microsoft Access for Windows 95 ® and three different third-party manuals explaining this product. Then I set up three main tasks for the user in a usability test. For each task, I provided the task description in blue type, and then copied the appropriate documentation in black. Documentation for each of the three tasks was reprinted from a different book.</description>
	</item>
	<item>
		<title>A Critical Assessment of the Minimalist Approach to Documentation</title>
		<link>http://tc.eserver.org/24090.html</link>
		<guid>http://tc.eserver.org/24090.html</guid>
		<description>Carroll&apos;s (1991) minimal manual has been considered an important advance in teaching first-time users the basics of computer programs. Unfortunately, it is not very clear what minimalism really means. Practitioners, for example, will find it difficult to create their own minimal manual because the principles of minimalism have not been described in enough detail (see Horn, 1992; Tripp, 1990). It is also not yet settled that a minimalist approach is the most effective one because critical experiments have hardly been conducted. This study therefore closely examines the minimalist principles and claims. This paper describes the basic ideas of minimalism, its design principles and how they can be operationalized. A parallel is drawn between a minimalist and constructivist perspective on learning and instruction. Like minimalism, constructivism places a high value on experience-based learning in context-rich environments. Like minimalism, it stresses the need to capitalize on the learner&apos;s prior knowledge as much as possible. And like minimalism, constructivists urge learners to follow their own plans and goals, to make inferences, and to abstract principles from what they experience (see Duffy &amp; Jonassen, 1991, 1992). An experiment is reported that examines the claims of minimalism. Strong and significant gains on several factors were found, all favoring the minimal manual over a control (conventional) manual. The discussion points to several issues that minimalism has yet to address.</description>
	</item>
	<item>
		<title>Deadwood  Phrases</title>
		<link>http://tc.eserver.org/21682.html</link>
		<guid>http://tc.eserver.org/21682.html</guid>
		<description>Deadwood phrases are found in all types of writing. In technical writing they are to be avoided at all costs as documentation needs to be  crisp, concise and accurate.</description>
	</item>
	<item>
		<title>Removing Unnecessary Words</title>
		<link>http://tc.eserver.org/21389.html</link>
		<guid>http://tc.eserver.org/21389.html</guid>
		<description>Using an extended example, this article shows how it is possible to reduce the number of words in a text and at the same time increase readability.</description>
	</item>
	<item>
		<title>Needless to Say</title>
		<link>http://tc.eserver.org/19731.html</link>
		<guid>http://tc.eserver.org/19731.html</guid>
		<description>The needless repetition of words and the repeating of ideas is everywhere - in newspapers, books, magazines, e-mails, television, and even in conversation. They’re called redundancies and the English language is full of them. In fact, research shows that about 50 percent of English is redundant.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Writing/Technical-Writing/Minimalism.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>