NOTE: Quick Guide software assignments are posted on the index page of the course website.  Click on ENGL 421Y -- Technical Writing Online to access the index page.

For the Quick Guide Project, worth 25 percent of your overall course grade, you will be responsible for writing and user-testing documentation for completion of a specific task within a specific software program. Programs for which we'll produce documentation are included within the
ITaP suite, and represent a wide variety of reasons for using, product features, associated projects, and users/user environments. Your documentation will provide textual and visual instructions suitable for
users of programs in the ITaP suite -- Purdue students, faculty, and/or staff. Keep in mind that our target audience represents a wide variety of users and user types, who may or may not be familiar with the
program and/or task that your documentation presents.

project rationale and goals

At some point in your academic or professional career, you will be asked to write up a set of technical instructions -- and you might have to write instructions for a product or process with which you have not
worked previously, or with which you have only a little familiarity. To compose such instructions effectively, you must consider issues of research, document design, audience, and usability. Whether you are
documenting software for unknown novice users working in an office, or machinery for co-workers in an industrial environment, you need to consider users' situations, skills, and needs; logically section steps
in the process; and provide rhetorically effective textual and visual elements.

Thus, your general goals for the documentation project are to:

• Write for specific audiences and purposes.
• Perform background and supplementary research related to a technical-writing task
• Learn principles of effective document design.
• Gain experience using technologies to produce documents.
• Negotiate successful collaboration with your project team.
• Manage a short- to medium-term writing project.

project activities

The Quick Guide Project involves a series of sequenced, "progressive" procedures that must be completed in a timely and productive manner to accurately reflect professional practices and standards, and to ensure that your "finished product" is of the highest quality possible.

Research, planning, and drafting your documentation. Through a blind drawing, you will be assigned a specific software
program that you will spend the next several days researching, using, documenting, and testing. Immediately after you are assigned a program, you will research the program and its users and identify a process
suitable for documentation -- taking detailed notes concerning key program and user aspects, then listing each
step to be documented and each step's result. Be sure to also identify and describe screenshots (screen captures) that will illustrate each step/result and reflect users and applicable documents/projects.

You will then write a memo containing document specifications, through which you describe the program/process, identify your target audience, and present written steps/results and screenshots in detail.
I will post to the course calendar a sample that doubles as a template and an example of what kinds of information your document specifications memo should present. Your completed document specifications will help you move to
this project's next step: producing a full draft of your documentation and planning for usability testing.

IMPORTANT: Your instructions, and the task(s) they present, should allow even novice users to successfully access/use your documentation. Keep in mind that depending on which program you've been assigned, it's
possible that your assigned tester has never used (or even heard of) it, much less completed the task that you've documented.

If you're really interested in working with a process that requires previous knowledge of a program/task, you'll need to identify a classmate who has sufficient exposure to your program/task to complete usability testing without assistance. Of course, you'll need to have sufficient exposure to this classmate's program/task to successfully
test his or her program/task. You'll also both need to let me know you'd like to work with each other before I make usability testing assignments!

Usability: audience analysis and documentation review.

At the same time you're working with your first full draft, you'll
begin working with a classmate who will serve as your tester for
usability testing. But before actual usability testing takes place, you
and your tester will need to take a few steps to learn more about your
tester's familiarity with the program/task, and to assess your draft's
readiness for live testing. First, you'll design a questionnaire that
-- ideally -- includes items that correspond to your documentation's
features and goals, while eliciting informative and useful responses
from your tester regarding his or her familiarity with, interest in,
possible reasons for accessing, and potential/actual applications of
the process for which you've created documentation. You may administer
the questionnaire as a survey that your tester fills out on his or her
own.

Meanwhile, your tester will read through your
documentation and offer feedback related to its overall
purpose/integrity, identification/recognition of general and specific
target audiences, appeals toward general and/or specific writing
situations, and implementation of prose-based items, images, document
design elements, and appeals toward specific writing situations and
target audiences -- a process known as documentation review.

NOTE: I would like for you to complete these activities during
the class session for which they've been scheduled, so that I can
observe how each team approaches pre-test information-gathering and
answer any questions that you might have.

Usability: real-time user testing.
You might need to revise your documentation draft before usability testing, if the results of the
informational interview and/or documentation review indicate that pre-testing adjustments are necessary.

For the usability testing session, which will take
place on the class day for which this activity is scheduled, you'll monitor the overall
testing process, take notes regarding your tester's actions, and keep
track of the time it takes your tester to complete specific steps and
the entire process. Testers: since writers won't be able to actually see you test their documentation, you will need to supply this information! Immediately after usability testing, testers will share their observations and his or her
suggestions. You'll then write a short report detailing this feedback and discussing the modifications you will make to your documentation before production and submission of a polished copy for formal review.

Documentation revision, production, and submission.
Based on feedback from usability testing, you might need to further
revise your documentation before refining it into a polished copy.
You'll then apply appropriate production-related techniques so that
your documentation is rendered in the format in which users would
actually access it -- i.e. "correctly" (user-friendly, intuitive)
folded brochures with appropriately-sequenced panels, two-sided flyers
printed on both sides of a single sheet of paper, PDF files linked from
a web page and posted online, etc.

project deliverables

In addition to drafting, testing, and revising your documentation,
you will be required to complete and submit a series of related
documents at various stages of this project. You will post each
deliverable, as it's completed, as a distinctly-named PDF file
attachment to the same individual blog post.
In other words, you'll create a carefully-labeled individual blog post
within which deliverables can be easily assembled and accessed. You
will attach a PDF file for each required deliverable as soon as it's
completed, and by the due date specified for each deliverable -- not submitting all deliverables at once, at the conclusion of the project.

Do not post anything in addition to, or instead of, the deliverables listed below:

document specifications

You will use a preliminary draft (or even informal plans not yet
written down) of your documentation to write a report in which you
combine a detailed technical description including:

• all steps
• supplementary notes/hints
• screenshots
• troubleshooting section (if applicable)

with specifications outlining:

• related research activities
• proposed methods of creating a document (flyer, brochure, booklet,
  website, etc.) used for compilation and production of documentation
• plans for usability testing, and
• a timetable for completion of the following project components:
  first full draft, pre-testing interview, user testing, and submission
  of completed documentation.

Please refer to the model for document specifications -- posted to
the course calendar. You will submit your document specifications by posting them as a PDF attachment within an
individual blog post titled "Quick Guide Project deliverables". These
are due by midnight on Wednesday, January 23.

1st full draft of documentation -- to be used for documentation review and/or usability testing
Applying the document design and formatting principles discussed in
class and referring to your document specifications and notes on
process and visuals, you will compose a complete first draft of your
hard-copy documentation, which should include each of the following:

• Title
• Introduction (including description of needed programs, files, peripherals, and/or knowledge, if applicable)
• All necessary steps
• A screenshot depicting each step's result (and screenshots depicting step-completion, when needed)
• Notes and hints throughout documentation, when needed
• Troubleshooting section (if applicable)

The first draft should be posted to your blog by midnight on Sunday, January 27 (in time for documentation review in class on Monday, January 28).

tester questionnaire and interview transcript

Based on the documentation you've created, and the characteristics
of your target audience, you will develop a series of questions to ask
the person who will conduct usability testing for your documentation.
Record word-for-word your tester's responses to these questions. You will post your interview
questions and your interview transcript within two separate PDF files,
to be attached to the already-created blog post titled "Quick Guide
Project deliverables".

Post a copy of your questionnaire/survey to your blog by Sunday, January 27 at midnight. Complete your transcript ASAP after documentation review during Monday's class and post it to your blog by Monday, January 28 at midnight.

2nd full draft of documentation -- to be used for usability testing (if applicable)

If documentation review feedback determines that revisions are
necessary before documentation is used for usability testing, you'll
complete a 2nd full draft. If the draft used for documentation review
is deemed "OK" for use during usability testing, you don't need to
produce a 2nd full draft before usability testing. Post your 2nd draft
(if one is necessary here) as a PDF attachment to the already-created
blog post titled "Quick Guide Project deliverables".

If applicable, post this second draft to your blog by Tuesday, January 29, at midnight. Be sure to bring hard copies to class for Wednesday, January 30.

usability testing report

Following usability testing, you will write a short report -- in
memo format, 1-2 pages in length -- that details testing conditions,
testing procedures established/followed by both you and your tester,
observations you made during testing, your tester's feedback, and your
plans for revising your documentation. Post your usability testing
report as a PDF attachment to the already-created blog post titled
"Quick Guide Project deliverables" by Friday, February 1 at midnight.

polished documentation

Based on usability testing, as well as the resulting usability
testing report, you will revise your documentation and print/produce it
in the format in which your target audience will access it. Examples
include, but are not limited to:

• hard-copy two-sided flyers printed on both sides of the page;
• hard-copy brochures and other "folding" documents folded;
• hard-copy booklets folded and stapled;
• electronic PDF documents saved as PDF files and posted for electronic access
• electronic web pages or websites saved as HTML files and posted for electronic access.

Of course, since we meet entirely online, you'll actually submit a PDF version of the document described above., you will Post your completed project as an attachment to the already-created blog
post titled "Quick Guide Project deliverables" by midnight on Monday, February 4.

project grading procedure

After I receive completed documentation projects, I will read
through -- and then use -- each student's quick guide. During both
phases of project grading, I will assume one of two roles:

• the role of someone who is unfamiliar with the task/software program, or
• the role of someone who is familiar with the task/program but who
  would like to incorporate the task/program into a specific project, or
  who is looking for different/new ways of using the task/program.

In either case, I will follow instructions exactly as
they are presented. If circumstances warrant it, I might also assume
the role of a user who prefers "winging it" to using prepared
documentation. With these issues in mind, I will grade documentation based on the following criteria:

Overall rhetorical issues

• meets or exceeds professional standards in all project phases:
  research, planning, drafting, testing, revision, production,
  submission, and overall project management
• within your assigned program, selection and presentation of a task
  that reflects and addresses the needs of one or more segments of our
  target audience: students, faculty, and/or staff who use the ITaP suite;
• consistent and well-reasoned demonstration of awareness --
  throughout the project and its associated activities/deliverables -- of
  general and specific characteristics of our overall target audience, as
  well as one or more segments of this audience;
• consistent and well-reasoned demonstration of awareness --
  throughout the project and its associated activities/deliverables -- of
  the kinds of documents/projects to which your documentation might be
  applied
• consistent and well-reasoned demonstration of awareness --
  throughout the project and its associated activities/deliverables -- of
  the rhetorical, genre-related, and technology-related issues we've
  covered in class

Documentation-specific issues

• a descriptive, yet concise, action-based title that emphasizes a
  specific task related to a specific software program and version.
  Example: Importing Text and Images into an Adobe InDesign CS2 Document;
• a short introductory paragraph in which you identify the process,
  describe specifics related to relevant projects, directly or indirectly
  identify your target audience, and give your audience a sense of the
  process's level of difficulty. If certain programs, files, items,
  and/or knowledge must be in the user's possession before completing the
  first step, you must include a disclaimer to that effect -- before
  presenting the first step!
• clear, concise written instructions with supplementary explanations where needed -- and only where needed
• strict and consistent compliance with various commonly-accepted
  "conventions" of documentation-writing (we'll discuss these in class)
• accurate, consistent, correctly-placed screenshots and/or other visuals
• clear, sharp, visuals, with legible text (if visual includes text)
• functional, attractive, usable document design
• hard copy version printed in color, PDF files rendered in
  appropriate electronic format -- and documents of both types must be
  presented in the format in which target audiences will access them
• overall quality, usefulness, usability, and relevance of your
  documentation in relation to your target audience and to the
  program/task presented

IMPORTANT: Each deliverable -- not just the polished version
of your software documentation -- must be completed and submitted (and
posted to your blog) on the specified due date for each item, in order
for your overall project to earn a grade.

revisions

You will be allowed to revise this project twice. The first revision will be due no later than 10 days after your graded original documentation has been returned. The second revision will be due no later than one week after your first revision has been returned.

Be sure to record the date(s) on which I return your original
project and/or first revision. Revisions submitted up to 12 hours after
the specified interval -- 10 days for first revisions, and one week
for second revisions -- will be graded, but not receive any comments.
Revisions submitted after noon on the day after the deadline will not
be graded, and will not be eligible for further revision.