|
English 349 & Technology 349, Technical Writing II:
Information
Design and Management
MW 3-4:15, 408 Stevenson
Fall, 2006
Jim Kalmbach
421H Stevenson
Office: 438-7648 E-mail: kalmbach@ilstu.edu
Office Hours: MWF 1-2 and by appointment.
Class Website: http://www.english.ilstu.edu/kalmbach/349/
Class listserv: ENG349-SP05-01-l@ilstu.edu
Subscribe or unsubscribe to the class
listserv
Course blog: http://eng349.cas.ilstu.edu (likely not in service the first day)
Course Overview
In this class, we will examine technical writing as a
form of information design and management that focuses on creating real documents
for real organizations and real readers. We will explore the idea
of documents as "artifacts
in use," that is things that people use in specific
social contexts for specific purposes and resulting in specific actions. The
class will also have a major emphasis on the process of managing long projects.
We will work through a detailed, scenario-based process of analysis, prototyping,
testing, drafting, reviewing, and rollout.
You major task in this class will be to plan and execute a single long organizational
document for real readers. The nature of this document should be related to your
major and your career goals. It can take any form of organizational communication
that is consistent with that major and those goals, including paper or web-based
documentation, reports, manuals, proposals, etc.
Texts
Barker, Thomas. Writing Software Documentation. Allyn & Bacon,
2002.
Sadly, no really good all-purpose, advanced technical writing textbook exists.
Even though not all of you will create documentation-based projects, Baker's
book has an excellent introduction to the scenario, prototype-based model
that we will follow in class regardless of what project your create. Thus while
the book's practical scope may be too narrow for some of you, its conceptual
framework will benefit everyone. If, however, I assign a section that seems particularly
distant from your specific project, we can negotiate an alternative
reading.
Gee, James. (2004). What Video Games Have to Teach Us About Learning and Literacy. New York: Palgrave Macmillan.
We will read Gee's book because all technical writing (even reports and proposals)
are, at their hearts, about learning and literacy. This does not mean that I
equate reading technical writing with playing video games, it does mean that
I believe the model of learning Gee develops has as much to tell us about effective
technical communication as it does about the process of
learning to play video games.
I will ask you write a response to each reading assignment. You can either
post the responses to our class blog or turn them in directly to me.
Course Requirements
During English 349, you will complete a single major class
project, a variety of support documents, and a small collaborative
project involving Gee's book and ethnographies (details
to be announced).
Major Class Project
This class is structured around planning and implementing
a major writing project. We will spend the first
half of the semester planning this project (including initial
prototyping and prototype evaluation) and the second half
drafting, testing, redrafting and evaluating the project.
Because the major project is the heart of the class, it
is critical that you choose your project wisely. Your project
should focus on organizational writing in professional
contexts, but the project should also be appropriate for
your goals after you graduate. Many English majors and
ACS majors produce documentation or procedural manuals
for specific organizations or audiences. Economics
majors have done similar technical writing projects, but
they have also have written a variety of reports, proposals.
Your project can be designed to be printed; it can designed to be used
online; or it can be designed for the web. What matters is that you have a clear
organizational audience and a clear organizational purpose for your project.
The project can also document work you have done in another class (for example,
a software development project), however, you should be documenting a project
you have completed or have nearly completed not one you are starting at the same
time as your start 349. My experience has been that attempting to complete the
process of document development that we are going to follow while simultaneously
following a different development process in an ACS class can be incredibly stressful:
your head could well explode!
Your project must be substantial and ambitious, though what
is meant by “substantial and ambitious” is negotiable
and will vary depending on where you are in your academic
career. A good rule of thumb is that if your goal is to get
an A in the class, your project should run at least thirty
single-spaced pages (though projects in the 30-100 page range
are more common). Alternatively, you can also propose a project
consisting of a library of smaller documents which taken
together represent a substantial and ambitious effort. Such
libraries often make excellent projects. Do not, however, stress
out over the exact length. We will negotiate the ambition of your project through
the planning process. If I sign off on your plan, I am saying that I believe
the scope of your project is ambitious enough to be successful.
In choosing your project, I encourage you to look for a
real organization that has a real problem which you can solve
using the central skills/knowledge that you are developing
in your major as an advanced undergraduate or as a graduate
student. My goal for
each of you is that you end this course with a project that
you can hand to a recruiter and say, “This is an example
of the quality of work that I am capable of doing.”
Everyone must solicit
the help of a technical advisor to review their project.
This advisor should be someone familiar both with the technical
details of your project and with the rhetorical context you
are writing to. That is, your technical advisor should understand
both what you are writing about and the people you are writing
to. I will ask your technical
advisor to review both your final project plan and a late
draft of your project. Your technical advisor should not be a peer. If you ask
a teacher, be sure it someone you know well and who will give you good and timely
feedback.
The Project Process
Our project process will roughly follow the one outlined`in Barker, p 174. We will do initial planning and design
work including an ethnography of your organization, an information
plan, project plan, prototype and prototype testing.
As part of this process, you will complete a series
of support documents (or deliverables) and assemble those
documents into a project management notebook. You will need
to include all of your support documents so start saving
them now. The exact
nature of these support documents is likely to change as
the class evolves. However, I currently plan for you to
complete the following project processes and support documents:
Project Planning (I will specify deadlines
for this part of the course.)
- Project pre-proposal (an informal memo about your project
ideas)
- Organizational/Publication Ethnography. (A close, situated
examination of the organization, publication, or website
you are writing for.)
- Information Plan (Your first pass at planning.
Includes use scenarios and analysis. Its primary
purpose is to establish that you have a valid topic before
you invest a lot of resources into it. Many students
switch projects at this point.)
- Document prototype and validation. (You design a small
piece of your project and validate it with prospective users/readers.)
- Content Specs (Your complete project plan.)
- Oral presentation of your content specs to the class for
feedback.
- Feedback from technical advisor on the appropriateness
of your project plan.
Project Development (You will set
your own deadlines for this part of the class as part of
your content specifications.)
- Alpha Draft Your first draft. It should focus on text.
- Beta draft Your second draft. It should have all design
elements present.
- Project Peer Review
- Technical Advisor Review
- Project Validation/Testing
- Final Oral Presentation
- Project Notebook
- Project wrap up report
Class Blog
We will have a class blog site that we will use it in largely informal ways:
to communicate with each other and to share information during class. Outside
of class, your main uses of the blog will be to store your reading responses,
to update me in the second half of the semester with weekly progress reports,
and to
manage the process of project peer review.
Grading
I will weigh the components of the class in the following
manner:
- Project Planning 25%
At the conclusion of the first part of the course (around
the middle of the semester), you will turn in your project
notebook with all of your planning documents and your technical
advisor feedback. I will comment and give you a grade on
your planning efforts.
- Project Development and Review 20%
One fifth of your grade will be based on how well you
manage the project development and review process.
- Major Class Project 30%
- Small Group Project 10%
- Attendance and Participation 15%
Includes reading responses, blogging, and in class projects.
When evaluating individual projects, my bottom-line criteria
for an A is as follows: Is the project ready to be used easily
and effectively by your intended reader(s) with at most a
light edit or is further revision of the organization, formatting
or style needed? When we disagree about whether your document
is reader-ready in this sense, I will most often turn to your
technical review to resolve the issue.
When reading your projects, I value the following characteristics
of good technical writing in the following order:
- Organization: Is your project clearly and appropriately
organized for your audience and your purpose?
- Ambition: Is this an ambitious project for a 300-level
class? Will it solve a significant problem?
- Content: Have you supplied your readers with the information
they need to use your document effectively? Is that information
accurate and up to date?
- Formatting: Is your project visually effective? Does
the formatting make it easy for your reader to read and
understand your text? Does the formatting reinforce your
purpose?
- Style: Is the writing style appropriate, clear, straightforward
and free of needless jargon?
- Correctness: Is the project relatively free of mechanical
problems? Have you used a spell checker and proofread carefully?
|
