Projects and Activities

Descriptions of major course projects are listed here.

Quick Guide Project

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.

Documentation review items

This "check-list" of items is meant to help you focus your energies during documentation review on certain key characteristics of successful software documentation. You'll probably recognize a number of these from what we've covered in class so far. You're not required to turn in a completed check-list -- but I would like you to incorporate it into the feedback that you give the writer regarding his or her documentation.
Keep in mind that you also need to consider additional program/task-specific considerations. I've identified the following items because they're crucial to any kind of software documentation -- and, of course, reflect what we've covered in class:
Product/task research
  • Does the documentation present a basic knowledge of the program and/or the task presented?
  • Does the documentation appear to accurately and ethically present information regarding the program and/or task?
  • Does the documentation present information about projects to which the user can apply the task that he or she is completing?
  • If applicable, does the documentation effectively present and/or explain differences between a newly-updated software program and previous versions of that program?
  • If applicable -- and if known -- does the documentation attempt to address limitations of already-existing documentation?
Audience analysis
  • Does the documentation specifically or implicitly refer to a target audience?
  • Does the documentation reflect an accurate and realistic assessment of its target audience?
  • Does the documentation acknowledge this target audience throughout the document, and/or within multiple documentation components (examples: introduction and written steps, or introduction and sample project, or introduction and transitions/explanations)
  • Does the documentation accurately reflect, and respond to, the intellectual, technological, professional, educational, and/or personal characteristics, interests, and goals of its target audience?
  • Does the documentation convey a tone that's appropriately professional, yet somewhat informal -- and always clear and direct?
  • If applicable, are sample projects representative of the program/task and accurately reflective of the documentation's target audience?
Writing and design
  • Is the documentation as a whole clear, direct, concise, and accurate in its written presentation of the documented program/task?
  • Does the documentation follow the conventions of software documentation (see sample documentation from Week 2 calendar)?
  • Are headings, sub-headings, body copy, and labels visually distinct from each other? Remember, headings and sub-headings need a sans serif typeface, such as Arial; and body copy is generally presented in a serif typeface, such as Times New Roman (though Arial is OK for body copy, especially in a web-based document such as a website, online help system, or PDF document).
  • Are the steps within the documentation clear, direct, concise, and accurate in their written presentation? Are all necessary steps included?
  • If the documentation presents two or more sub-tasks that comprise a larger task, does it incorporate sub-heads and separate numbering systems? Does it include transitions that connect related tasks, while signifying the need to separate these sub-tasks?
  • Does the documentation include an appropriately descriptive, action-based title that effectively identifies both the program and a specific task? If applicable, does the title also identify a specific project and/or target audience?
  • Does the documentation include a brief introduction that identifies the task(s) presented within? If applicable, does the introduction specifically identify expertise, programs, hardware/peripherals, files, and other items that the user needs -- and do so before the first step?
  • Do written steps specifically refer to accompanying screenshots?
  • Do screenshots to represent each time the user's screen changes in completing written steps?
  • Are screenshots presented below steps/results, thereby helping the document maintain a continuous downward reading flow?
  • Are screenshot images crisp -- and are they of appropriate size?
  • When necessary, are items within screenshots correctly and effectively labeled?
  • Do steps and/or results and their corresponding screenshots appear on the same page?
  • When necessary, does the documentation make effective use of notes and/or hints -- and are they clear, direct, concise, and accurate in their written presentation?
  • Are notes and hints clearly separate from actual steps?
  • Are steps the only items numbered?
  • When applicable, does the documentation make effective use of transitions between steps within a single task and/or sub-tasks within a larger task?
  • When applicable, are sidebars presented in a way that ensures that they're separate from the documentation's main body -- especially steps/results?
  • When applicable, does color direct appropriate levels of attention to items for which it's applied? Does it enhance the user's ability to complete the documented task?
  • If the documentation is presented within a brochure, are related items grouped within the same panel, or visually connected panels, as much as possible?
Usability
  • Does the document as a whole acknowledge the target audience's characteristics, purpose(s) for accessing the document, and meet its intellectual, vocational, personal, and/or creative needs?
  • Does the document allow users to effectively move back and forth between reading and completing the documented task?
  • Does the document allow users to smoothly proceed from the top/beginning of the document (and/or individual pages) to the bottom/end?
  • Does the document take into account certain user characteristics, such as limited literacy/aliteracy, ability to use written text and/or images, language issues, disabilities (learning and/or visual), and overall familiarity/comfortability with technology and/or documentation?
  • Does the document present all necessary steps and descriptions of results? Does it include additional information only when necessary, and without excessive details/explanations?
  • When encountering or addressing issues or tasks that go beyond the scope of documentation for a specific task, or a series of connected tasks, does the document direct users to hypothetical or actual documents that cover these items?
  • Do visual elements -- such as images, color, and page formatting -- enhance, without detracting from, the user's ability to access and use the documentation?

White Paper Project

The focus of Project 2 is the white paper, a common report genre in the professional world. White papers are used in business, industrial, and governmental contexts to sum up the gist of what’s known about a subject. During this project you will learn about

  • the white paper genre through collaborative creation of a white paper.
  • new writing and communication technologies that support technical writing in college and industry, with attention to open source and other freely available software or writing spaces (online networks, blogging, etc.)
  • collaboration, project management, and strategies for writing and revising.
  • producing a text for the web in HTML that integrates visual content, such as screenshots, tables, and flowcharts

IMPORTANT: White papers completed for this project will address issues related to open source technologies and/or the larger open-source movement.

At the beginning of this project, you will be placed by your instructor into a group with fellow students. Each of the major components of this project will be completed in collaboration with group members. Individuals must also keep a project log at their course blog following these guidelines. Everyone will also be asked to email a peer collaborative evaluation form (Word format) independently to the instructor when Project 2 is due.

Discussion

Learning about the genre of white papers. You'll spend some time in the early part of the project reading sample white papers and about new writing and communication technologies so that you can get comfortable with the genre and the general topic. You will see that although you may not be familiar with all of these new technologies (or things like "open source") yet, you'll learn about it quickly. In fact, you already know much more about it than you realize since this English 421Y website uses Drupal, which is itself open source software. (You may be viewing it in Firefox, also an open source project.) The point of the white paper genre is to represent the critically important information about a specific topic (such as a technology), not to argue, sell, or promote (though those may be ancillary purposes)

Rhetorical Situation: The primary audience for your writing will consist of peers and other technical writing experts interested in finding out how new writing technologies can help their organizations in college or the workplace. A subsidiary audience is other people interested in these new technologies (the early adopters in the public sphere), even entrepreneurs who may see (or desire) new applications for these technologies for business, education, and enterprise purposes. The purpose of your white paper writing should be to provide essential and accurate background information and sources on a specifci topic for interested readers so that they are well informed and ready to make up their minds about the value or usefulness of a technology.

Project Goals

This project emphasizes several important goals that all professional writers should bear in mind and that are consistent with those of the Professional Writing Program at Purdue.

Writing in Context

  • Write to the different levels of technical expertise of a range of audiences and stakeholders to foster technical understanding.
  • Understand the ethical implications of working within the nexus of technology and culture.

Project Management

  • Understand, develop and deploy various strategies for planning, researching, drafting, revising, and editing documents both individually and collaboratively.
  • Select and use appropriate technologies that effectively and ethically address professional situations and audiences.

Document Design
Make rhetorical design decisions about technical documents including

  • understanding and adapting to genre conventions and expectations of a range of audiences including both technical and non-technical audiences
  • understanding and implementing design principles of format and layout
  • ensuring the technical accuracy of visual content

Teamwork
Learn and apply strategies for successful teamwork, such as

  • working online with colleagues to determine roles and responsibilities
  • managing team conflicts constructively
  • responding constructively to peers' work
  • soliciting and using peer feedback effectively
  • achieving team goals

Research
Understand and use the research methods and strategies necessary to the production of professional documents, including

  • locating, evaluating, and using print and online information selectively for particular audiences and purposes
  • triangulating sources of evidence

Technology
Use and evaluate the writing technologies frequently used in the workplace, such as emailing, instant messaging, image editing, video editing, presentation design and delivery, HTML editing, Web browsing, content management, and desktop publishing technologies.

Deliverables

  1. Project proposal. Each group will do preliminary research, come up with an original topic, and submit their proposal as a "story" at our course website for class discussion and feedback.
  2. Project logs. Each group member will keep a weekly project log on their individual weblog. See the guidelines for project logs.
  3. Research posts. Each individual group member will, in coordination with the rest of the group, research in depth the group's topic and post their notes to their individual weblogs on the course website. For the research posts, everyone in the group should agree to use a common tag for the category (e.g., "Research on Google Docs")
  4. Annotated bibliography. At the end of the research phase, the group will assemble a short annotated bibliography (including 6 critical sources) and compile and post the bibliography to a member's blog and tagged so that it shows up with the group's project documents (e.g., tag = Group 3 White Paper Project)
  5. White paper drafts and revisions . The group is responsible for the timely creation of a total of four drafts of the white paper. The first draft of your white paper should be 2,000-3,000 words + the annotated bibliography. Following the first draft, you will receive further instructions for a revision assignment for creating the final draft. As you revise your white paper, you will work from global concerns (e.g., content development and organization) toward local concerns (proofreading and editing), with peer review focused on the major concerns at each stage of the revision. The final draft of your white paper should
    • Demonstrate a good knowledge of the white paper genre.
    • Be rhetorically sensitive to the needs of the primary and subsidiary audiences.
    • Be well argued and supported by research.
    • Be carefully and fully cited and include a references section, in addition to the annotated bibliography.
    • Contain a consistent voice and style throughout.
    • Be free of proofreading and editing problems.
    • Follow the stylistic conventions for professional writing and writing for the web as covered in the course readings and discussion.
    • Be presented in HTML format and include relevant visual content to teach as well as illustrate concepts and information.
  6. Peer Collaboration Evaluation Form. At the end of the project, each group member will provide a detailed evaluation of all of the group's members and submit the form to the instructor.

Deliverable due dates:

  • Project proposal: Monday, February 18
  • Annotated bibliography: Friday, February 22
  • Preliminary copy of Draft 1 for peer review on February 29: Wednesday, February 27
  • Draft 1 for instructor review: Friday, March 7
  • Draft 2: Monday, March 24 (due date has been changed!)
  • Draft 3: Two weeks after your graded Draft 2 has been returned
  • Draft 4: One week after your graded Draft 3 has been returned

 

Collaboration

Successful collaboration will be a critical component of this project. Follow guidelines for successful collaboration as described in our text (see and discussed in other course readings and messages. To summarize, you should

  • Work collaboratively with the rest of the group in researching and drafting a white paper, including participating in any online group meetings and providing deliverables in a timely manner in the requested format.
  • Follow good professional communication practices, especially in project and issue logs
  • CC all group members on any email communication regarding the project (including contacting the instructor, unless of a personal nature).
  • When assigned, provide detailed feedback to other groups on their projects/drafts.
  • Conduct oneself in a professional manner in all group communication and when giving feedback to other groups.

Grading

Your individual grade for this project will be based the work produced by your team and the quality of your contribution to the project, as determined by your project evaluation forms and project logs. Project 2 is worth 25% of your overall course grade.

White Paper Project: drafts

Here are the items that will need to be present within your white
paper. Remember, you will complete four drafts -- the first, which will
be responded to but not graded; the second, which will be graded as the
project "original"; and Drafts 3 and 4, which will be treated as your
two alloted revisions.

Major details

  • The assignment calls for 6-8 pages, single spaced block-style
    paragraphing -- but if the first draft has at least 4-5 pages, that's a
    good start. For these shorter drafts, make a couple of recommendations
    related to how to provide more, and more detailed, information!
  • The title should be descriptive and reflect both the writing situation and the white paper's target audience.
  • Headings should reflect content/writing situation presented within each section
  • Sections should include: intro/executive summary,
    history/background of issue discussed, research/analysis-based material
    supporting the main position, an overall interpretation/analysis of
    information presented throughout the white paper, a conclusion, and a
    bibliography section

Specific items to look for within drafts

  • A clearly-stated position or a strongly implied position (similar
    to direct and indirect thesis statements within academic essays)
  • An identifiable context or situation to which the topic/position is related
  • A clearly-defined organizational pattern that establishes overall reading flow and connections between ideas presented
  • Evidence that the white paper is appropriately tilted toward target audiences
  • Balance in research-based sources and sufficient analysis of source-based information
  • Effective incorporation of graphics and directly-quoted material (introduction, source, and analysis/interpretation)
  • Thoughtful, engaging prose style throughout (just because a
    document highlights research doesn't mean it's OK to be boring,
    artificially elevated in diction, abstract and/or unclear!)

White Paper Project: project proposal

White paper proposals should be 1,000 words, single-spaced, in length and incorporate/address the following items:

  • a working title for your white paper
  • a brief description of the subject matter to be covered
  • specific mention of the position your group plans to take within the white paper
  • a brief discussion of your target audience -- important because
    this will help you further narrow your topic *and* articulate your
    position
  • a brief analysis of how open-source technologies might affect your target audience
  • a discussion/analysis of possible sources for researching this topic
  • an overall assessment of how your white paper would contribute to a larger "discussion" of the subject matter covered

For those of you who would appreciate a bit of direction in
organizing these proposals, I would suggest a four-paragraph proposal
arranged in the following fashion:

  • Paragraph 1: brief description of subject matter and specific
    mention of your group's position -- with indirect mention of your
    envisioned target audience
  • Paragraph 2: more details related to your target audience, and a
    brief analysis of how open-source technologies might affect this target
    audience
  • Paragraph 3: discusssion/analysis of possible sources for
    researching this topic -- presented in a way that highlights research
    *and* ties together points made in the first two paragraphs
  • Paragraph 4: assessment of how your white paper would contribute to a larger "discussion."

Keep in mind that readers have a number of reasons for accessing
your white paper: learning about your subject matter, researching a
variety of positions taken on your topic, tracing "developments" in a
career field/technology/the open-source movement, making a decision
related to policy, economics, or personnel.

Technical Marketing Materials Project

For many of you, the courses you have taken at Purdue have prepared
you for a general career in technology, business, or industry. Out in
the workplace, you may have to learn new business models and methods--
as you've discovered while learning about software
development. For example, you might be hired by the automotive industry
in Detroit or by a major winery in California. It is once you get into
your careers that you will learn the particulars of the products and
services the companies you work for provide.

Similarly, product manufacturers create advertising campaigns and
various marketing materials for a wide variety of individuals,
businesses, and organizations. They must first study the product or
services and understand the target audience for those products and
services in order to create marketing strategies and documents.

In this project, you will have a chance to draw on your experience
with the white paper project to research products and target
audiences, derive marketing strategies, and create technical marketing
materials that can be useful for in-store promotions, conferences or
trade shows, or product/manufacturer websites.

The Technical Marketing Materials Project will involve two deliverables, as described below:

Project Proposal/Document Specifications

During the first stage of the project, each group will research a
particular product or service and prepare a 750 word proposal which
articulates the target audience and the strategies necessary for
targeting that audience. Review the Developing Marketing Materials: Document Specifications
guidelines (see link at the bottom of this page) for help in preparing step 1. Groups should address both
features (of the product or service) and the benefits for the
particular target market. The project proposal must be completed and
submitted before beginning the second stage of the project.

After completing your initial proposal, you will add information to
that proposal once you've made additional decisions regarding your
technical marketing document: document type (brochure, flyer, booklet,
postcard, etc.), document focus (product, manufacturer, audience,
retailer), target audience, and design features. These will constitute
your document specifications.

Technical Marketing Document

During the second stage of the project, each group will create a
hard-copy technical marketing document. Everyone is probably familiar
with one page flyers that companies often provide to advertise their
products and services. For this stage of the project, you may create a
flyer, brochure, booklet, or postcard. This document can be either
portrait or landscape orientation (horizontal or vertical), and may be
a fold out.

Required components within your technical marketing documents include:

  • A cover or front page containing a dominant visual element (an image, use of color, or use of typography)
  • Titles and subtitles, as well as a slogan if appropriate
  • Appropriate combinations of technical definitions/descriptions and marketing-style language
  • Technical specifications, to be placed in an appropriate location within the document, or on the back cover
  • Identifying elements related to the product, manufacturer, and intended target audience (text, images, and colors)
  • Contact information -- for the manufacturer, retailer, or both
  • Presentation in the exact format in which target audiences would
    access this document: hard copy/web page/PDF file, with brochures
    folded, booklets bound, two-sided documents presented as such, and
    documents smaller than print size trimmed to appropriate dimensions
  • Overall presentation in line with the ethos, or image, portrayed by
    the product and its manufacturer -- in other words, the document needs
    to look, read, and feel as if it's actually representing this product
    and this manufacturer!

Project Logs

As with Project 2, each group member is responsible for keeping a weekly project log.

Project Topics

Each group will create technical marketing materials for
technology-oriented products: software, hardware, peripherals, or
"gadgets" commonly used at home, in the workplace, in educational
settings, or within public/private locations such as libraries,
employment centers, community centers, government agencies, or
nonprofit organizations. You may also work with a product that involves
technology, but isn't necessarily itself a "technology-based product"
(i.e. "computer-related") "Technology" can be further defined/described
as any component or development that makes a product both distinctive
and usable -- so with this idea in mind, groups can also create
technical marketing materials for items such as household appliances,
vehicles, tools, lab or workshop equipment, and pharmaceuticals, among
others.

Unsure about what's involved in creating technical marketing
documents? Visit a computer/electronic retailer such as Best Buy and
pick up some booklets or brochures accompanying floor samples of
various products. HINT: Hewlett Packard (HP) is particularly strong in
this regard. We will discuss a wide range of technical marketing
documents in class.

NOTE: You will need to do more for this project than merely reproduce an already-existing document!

Project due dates

  • Project proposal: Wednesday, April 9
  • Document specifications: Monday, April 14
  • Technical marketing document draft for peer review: Tuesday, April 15 (for peer review on Wednesday, April 16)
  • Polished technical marketing document for formal review: Friday, April 18

Revision

Because the end of the semester is near, you'll
likely have only one chance to revise this project; I will return, via
e-mail, graded technical marketing documents by

Should you anticipate needing two revisions, I would highly recommend
submitting your technical marketing document a few days early -- so
that we have enough turn-around time between submission and return
cycles to fit two revisions!

Technical Marketing Materials Project: document specifications

A document specification is a concise statement of core goals,
values, and intent. It is used to provide direction for making good
decisions about the content, design, and media of marketing materials
or other documents (even for a website). Ideally, a specification
document should include information about the scope of the document's
content, the budget, the schedule, and technical aspects of producing
and distributing it.

Some questions to address in a specification document. In some cases, the questions focus on print-based documents. You
should try to answer all of the questions that are relevant to your
project and in as much detail as possible. Your responses should be
posted as a story to the course website.

Goals and Strategies

  • What is the mission of the product/manufacturer?
  • How will creating the document support this mission?
  • What are the two or three most important goals for the document?
  • Who is the primary audience for the document?
  • Is there a secondary (or subsidiary) audience?
  • What do you want the audience to think or do after having read the document?
  • How will you measure the success of your marketing document?
  • What format will the document take?
  • How will you distribute or deliver the document?

Production Issues

  • How many panels, slides, pages, or nodes will the document contain?
  • What special technical or functional challenges do you face? How will you solve them?
  • Do you have a budget for producing, printing, and distributing the document?
  • What is the production schedule for the document, including intermediate milestones and dates?
  • Who are the people or vendors on the development team and what are their responsibilities?
  • What provisions can you make now for future development of the documents by others?
  • If the document is meant to be printed, what size and type of paper
    should be used? What will a person need to know in order to make a high
    quality printed version?
  • What do you need to do to ensure that a person can access and print the document successfully? What file format should you use?