Motivation

Based on the chapter in Williams & Bizup of the same name.

Motivation

In the Audience topic, we mentioned attitude toward the info as a concern. How does your reader feel about the information you're trying to convey?

What can we do to get the reader interested?

Motivation

The motivation question here is one of motivation of the reader.

How can be motivate the reader to engage with what we have written (i.e. actually read it carefully)? How can we help them follow what is written?

Motivation

If we're going to engage the reader, we need more than a collection of facts.

Quicksort usually runs in O(n log n). Insertion sort takes O(n2). Insertion sort is easier to implement.

So what?

Motivation

Readers will be more engaged if there is an actual problem to solve which motivates the discussion.

It can be subtle.

Quicksort usually runs in O(n log n), which is faster than insertion sort, which takes O(n2). Insertion sort is easier to implement correctly, whereas Quicksort can be difficult to get right.

Now we have some problems the reader can think about: sorting quickly and correctly.

Introductions

Your introduction can help motivate the reader by stating the problem that you'll be working on. Pose a problem that you can convince the readers needs to be solved.

Maybe you'll also have to convince them that they care about the problem.

Introductions

Answer the big question: So what?

Introductions

It could be a problem the reader is very concerned about, or that they didn't know they had.

Introductions

As an example, we're going to write an explanation of “scrum development” and need an intro.

Scrum is an incremental agile software development methodology. It defines a product development strategy which breaks from the traditional “waterfall” method and encourages frequent face-to-face communication. This report will describe the basic concepts of scrum development.

[That's shorter than an intro might normally be, but it has to fit on a slide. Examples here are unusually terse.]

Introductions

The problem scrum is trying to solve is managing requirements and developer efficiency. Let's say that.

Software development teams work together to meet the requirements they are given. However, employee time lost to handling changing requirements is both frustrating for them and expensive for the employer. The scrum development methodology provides a development strategy that manages changes in requirements and helps the development team work together toward a common goal.

What does that have that the bad version doesn't?

Shared Context

What circumstances/​situation/​belief/​need do you have in common with the reader?

Consider starting with something the reader can use to orient themselves. You may challenge this context later, but can use it to frame the discussion.

Shared Context

In the earlier example:

Software development teams work together to meet the requirements they are given.

Or something like:

As we start developing web-based products we will need…
It is often necessary to use the output of one process as the input of another. [something about Unix pipes…]
Over the last two years, our company has been able to…

Shared Context

The shared context doesn't have to be a point of view you stick with.

Modern web development can be difficult because of the variety of concerns the developer must consider. … Rails reduces these concerns by… challenges the context

It doesn't have to be at the very start.

Employee time lost … is both frustrating for them and expensive for the employer. was the second sentence

Shared Context

Explicit shared context can be omitted if its role can be taken over by…

Stating the Problem

What are you trying to solve with this piece of writing? Make sure the reader knows what it is.

Stating the Problem

Two things you should mention as part of the problem:

  1. The condition or situation: what is going on that we're talking about?
  2. Why that's bad: what is the cost or negative consequence?

e.g. (1) employee time lost to handling changing require­ments, (2) frustrating… and expensive.

Stating the Problem

The “problem” could be an actual practical problem that needs to be solved. e.g. X isn't working/efficient/beautiful.

In this case, you will likely be answering what should we do about it?

e.g. development inefficient → switch to scrum.

Stating the Problem

It could also be a conceptual problem: your reader doesn't know or understand or appreciate X. A lot of academic writing falls into this category.

The “cost” may be less obvious here. The real answer might be you don't understand something happening around you, and that sucks.

Stating the Problem

A suggestion: state the problem and ask yourself so what?

e.g. Reader doesn't understand dimensionality reduction techniques in machine learning. So what? Machine learning models run much slower.

Stating the Problem

Critisism of my colleagues: many instructors forget to answer the so what? question when introducing material in courses. Experience tells me that students will learn anything if they see the point in doing so.

In some courses, you may have to answer for yourself why it matters.

Stating the Problem

The cost/negative consequences will depend on your audience.

e.g. bad development methodology frustrates developers (which they care more about), and costs money (which managers and owners care more about).

Stating the Solution

You won't state the whole solution in the introduction, but should tell the reader the main point, or the direction you'll be going.

e.g. The scrum development methodology provides [benefits].

Stating the Solution

For a more conceptual problem, the “solution” might be an ability to use this knowledge later, or simply the main point (thesis) of the writing.

e.g.

An improved understanding of distributed data structures will allow more efficient handling of large data sets in future analyses.
Here we will explore the benefits of project planning.

Introductions

We have proposed that introductions consist roughly of:

  1. Shared context.
  2. Problem: condition and cost.
  3. Solution (or main point or thesis).

As with any writing rule, this should be adapted or even ignored if necessary.

Remember that the examples here are quite short: each of these might take a couple of sentences in real writing.

Introductions

Another example: report on dimensionality reduction in machine learning:

Machine learning techniques are often useful for uncovering patterns in data. shared context Unfortunately, the algorithms in machine learning are often too slow to be applied to large data sets, which makes them impractical. problem and cost Dimensionality reduction techniques can improve performance of analyses and allow them to handle larger collections of data. solution/main point

In-Class Exercise

Write a short introductory paragraph for the tutorial on a module that handles geographic points.

Conclusions

At the other end will be your conclusion. What does it do?

Roughly: undo the introduction.

Conclusions

Start by (re)stating the main point that you have built. You can probably be more specific now that you have filled in the details in the main body of the report.

These techniques will reduce the number of dimensions in the data that is used as input to another algorithm.
The scrum methodology allows predictable handling of changing requirements, as they need to adapt.

Conclusions

Again explain the significance and answer so what? Again, possibly with more subtlety than in the intro.

This will allow several orders of magnitude reduction in the input size, depending on the level of structure in your data.
The predictable adaptation will let developers focus on X and encourage product owners to Y.

Conclusions

Consider extending with a further question or problem: answer now what?

After dimensionality reduction we must consider how to correctly complete our analysis.
Minimizing the level of change in requirements is also important: this is also considered by scrum but has not been covered here.

Conclusions

Maybe end with an anecdote, related fact, or quote.

These techniques will help us approach a wider variety of problems, for as John Tukey said, an approximate answer to the right problem is worth a good deal more than an exact answer to an approximate problem.

… but that may not be appropriate for technical writing.