Summer 2021 — UC IrvineInformation & Computer Sciences ICS 139WDavid G. Kay

Changing the System
 

Nothing endures but change.

--Heraclitus (c.540-c.480 B.C.)

Plus ça change, plus c'est la même chose.
(The more things change, the more they remain the same.)

--Alphonse Karr, Les Guêpes (1849)

Give us serenity to accept what cannot be changed,
courage to change what should be changed, and
wisdom to distinguish the one from the other.

--Reinhold Niebuhr (1934)


For this assignment, you will pick some software system you're familiar with, a system that you think could be changed for the better. You'll write about that system from a variety of perspectives for a variety of audiences: discussing your your system and your proposed changes informally with your colleagues, introducing new users to the system, and proposing changes to whoever has the authority to make the changes.

Imagine, for example, that you have a job with the "EEE Team" at UCI (the Office of Information Technology's Academic Web Technologies group). Periodically you will have to instruct new users (perhaps students, perhaps TAs or faculty) on how to use Canvas. You might write an introductory document, explaining to your selected audience the kinds of tasks Canvas can do for them. Later in that document, or in another document, you might give a tutorial providing the details of carrying out those tasks (the specific commands to use), perhaps with a set of examples the reader would follow.

In addition, you might think that Canvas could be improved in various ways (such as additional featurers or improvements to the user interface). You might discuss these improvements with your colleagues. They may know a way to achieve what you want in the current version, or they may suggest refinements to the changes you're thinking about.

Probably you would have to convince someone (your boss, or a committee in charge of deciding what software enhancements are most important) that your changes would be worth implementing. You would make your case both in a written memo and in an oral presentation.

For this assignment, you will choose some software that you're familiar with and do each of these things. As you develop each of these different documents, focus on how the audience for each document is different—they have different experience, different needs, and so on, which means that how you write for each will be different, too.

Stage I—choosing a system: First, you must decide what system you will use for this assignment. Your system may be conventional application software; it may also be an embedded system (like a "smart refrigerator" or a self-driving car) or a web site with substantial navigation or interaction. By Tuesday, June 29, write a brief, informal note to post in your group's discussion board. It should name the system, describe it if it's not something everyone's familiar with, and sketch out the kind of changes you're thinking of proposing. Within 48 hours, you will receive comments or suggestions from each of your group-mates [and you will comment on each of your group-mates' postings]. In another day or so, you will also receive a comment from the TA.

Stage II—introduction for novices: You will write an introduction to the system for novice users, of three to four pages. This document should give a high-level description of the system and its capabilities, describing what tasks the system will perform and giving the necessary background. It should answer the question, for the novice audience, "Why should I want to use this system?" It might go onto to point out the system's significant limitations or shortcomings. (The tone should be positive. You want people to be able to use the system, and a gripe session doesn't set the right tone. But a novice might expect the system to do more than it actually does, and if the shortcoming might be significant to some novice user, that user should know before investing a lot of time and effort.)

This introduction should not get into the tedious minor details of which keys to press or which menu items to choose for a given task; a recitation of all those details is sometimes necessary, but for this assignment it would not be very interesting and would extend this assignment far beyond four pages in any case. You may use screen shots or other illlustrations but that doesn't decrease the expected number of pages of text.

A good draft of this is due on July 5 for peer review; your peer reviews are due July 7; the final version is due July 9.

Stage III—proposal for change: You will write a proposal for changing this system, of five to six pages plus a brief single-page cover letter. Address this proposal to whatever decision-making authority is appropriate for your software: perhaps the company that publishes it, perhaps an individual or committee in your own organization. Try to find out the actual name of the actual person or group who actually has the authority to make the changes you suggest, and write your proposal with that person or group in mind. Your goal should be to produce a proposal you can actually send.

A draft of your proposal is due for peer review on July 12; you will receive four of your classmates' drafts to review, due in 48 hours (on July 14). A revision based on the peer reviews is due on July 16. You will receive back a draft score and comments. The final written version of your proposal is due on July 21.

Stage IV— proposal presentation: If your written proposal for change generates some interest, the decision-maker may ask you to make a presentation in person (or, in these days of COVID, via Zoom). An oral presentation accompanied by PowerPoint-style visual aids is customary in these situations; you will prepare a Zoom recording no longer than five minutes of yourself delivering this kind of presentation. [When we say PowerPoint, we include similar tools on other platforms, such as Keynote or Google Sheets.] You will submit a draft of these slides (without your narration) as a PDF file for peer review on July 12; you will receive four of your classmates' drafts to review, due in 48 hours (on July 14). A revision based on your peer reviews is due on July 16 (the same time as your proposal but in a separate place on Canvas). You will receive back comments and a score for the draft slides. The final video version of your presentation is due on July 22. Please note that any technical difficulties should have been ironed out with your personal introduction, so we won't accept technical difficulties as an excuse for late submission.

Grading of oral presentation: Your score on the presentation will be based on its content, organization, and effectiveness of the visual aids (slides). Oral presentations are nerve-wracking enough for most people without the addition of grade pressure. The main criterion we will use for evaluating your oral presentation is that you make and submit a video recording in which you appear to be well prepared. We will not grade down significantly for speaking style or loudness of voice or oratorical polish, though we do expect that you will try to address your intended audience appropriately. We will not grade down at all for nervousness (though we hope that will abate as the quarter progresses) or English pronunciation or the speaker's personality.

Each part of this assignment shares the same underlying subject matter. What's different in each part is the intended audience (and thus what knowledge you assume, what you cover explicitly, and the level of formality). The table below shows this.

Suggestions and advice: Choose software that you know something about, and more importantly, that you care about. The best writing (and the easiest for the writer) is writing where the writer has experience with the topic and really cares about getting it across to the reader. So choose something that matters to you.

Always be mindful of your audience. Novice users have different needs and a different set of assumptions than decision-makers, for example. Moreover, the appropriate level of formality is different for each of your different audiences. This table will help you focus on these distinctions:

STAGE

DUE DATES
AUDIENCE
FORMALITY

I: Change proposal synopsis, describing what changes you're proposing

discussion board 6/29

peer review comments 7/1

Your classmates in your discussion group, who may know something about the software (depending on your choice) and who may have suggestions about the changes you propose
Informal

II: Introduction to the current system

draft 7/5

peer review comments 7/7

final 7/9

Novices, unfamiliar with the software, who need to learn its purpose and basic functionality
Friendly yet professional

III: Change proposal, describing and justifying the changes

[including slides and cover letter]

draft 7/12

peer review comments 7/14

revision 7/16

final 7/21

Decision makers, who know about the software but must be convinced of the need to change (and the feasibility and advisability of the changes you propose)
Correct and professional, addressing corporate higher-ups

IV: Change presentation, video of oral presentation with slides

draft of slides (PDF) 7/12

peer review comments 7/14

revised slides 7/16

video of oral presentation with final slides 7/22

Same as above
Same as above

We encourage your effective use of graphics, though graphics may not reduce your prose page count below the minimum.

To the extent applicable, you should state your sources of information in your written proposal, backing up whatever facts and figures you used. This need not be gathered all together at the end as a formal bibliography—it is better to mention the name of the source at the point where you use its information in the body of the paper. If your word processor supports automatic footnotes, use them, but do not waste time trying to include footnotes manually—an in-line citation is fine. Citations should provide enough detail to allow the reader to find the cited work and follow up on the information and all the citations in a document should follow a consistent format, but the precise format you use is not crucial for this assignment.

There's a big difference between spoken and written language. For the oral portions of this assignment, do not simply read from a script. Of course you will use notes, but speak naturally rather than reading a "canned" speech. On the other hand, the presentations are relatively formal in tone; joking banter and slang are not appropriate.

We will be happy to advise you on any aspect of your proposal. We're a valuable resource; take advantage of our assistance.

The Peer Review Guidelines (Stage II, Stage III, Stage IV) indicate the qualities we're looking for in the scoring.

There are two sample proposals available; they received among the highest scores in a previous offering of the course. Sample A Sample B