How to write an abstract

What is an abstract?

It is common in engineering literature for a paper to begin with an abstract.

A summary or abridgement of the document - tells readers what they will find in the paper.

What an abstract isn’t The following definitions all come from the Oxford English dictionary under the entry for ‘abstract’

Insufficiently factual or practical; dealing with ideas and generalities rather than events or specific outcomes. Difficult to understand; abstruse. Separate, distinct; set apart from; withdrawn, secluded

An abstract for a paper or a thesis is none of these things!

Elements of a Good Abstract

A good abstract does three things States the research/engineering problem Announces key themes States the main finding or presents a launching point that anticipates the main findings

Abstract Patterns

Well written abstracts fit one of three patterns

Context + Problem + Main Point Context + Problem + Launching Point Context + Problem + Launching Point + Summary

Context + Problem + Main Point

Effectively an abbreviated introduction One or two sentences to establish the context, e.g. previous research Continues with one or two sentences to state the problem or hypothesis being addressed Concludes with the main finding of the work

CFD Software development folklaw has held that text based editors (e.g. vi) and a command line tool chain promote more serious work than do integrated development environments (e.g. Eclipse), a belief that seems to be confirmed by Jacobs (2009). But Jacob’s study was based on the same folklaw that it purported to confirm. In this study no significant differences were found in the quality of software produced by a cohort of PhD students working with a text based editor or with an integrated development environment

Context + Problem + Main Point

CFD Software development folklaw has held that text based editors (e.g. vi) and a command line tool chain promote more serious work than do integrated development environments (e.g. Eclipse), a belief that seems to be confirmed by Jacobs (2009). But Jacob’s study was based on the same folklaw that it purported to confirm. In this study no significant differences were found in the quality of software produced by a cohort of PhD students working with a text based editor or with an integrated development environment.

Context + Problem + Main Point

Context + Problem + Launching point

One or two sentences to establish the context, e.g. previous research. Continues with one or two sentences to state the problem or hypothesis being addressed. A sentence or two on the general nature of the results.

CFD Software development folklaw has held that text based editors (e.g. vi) and a command line tool chain promote more serious work than do integrated development environments (e.g. Eclipse), a belief that seems to be confirmed by Jacobs (2009). But Jacob’s study was based on the same folklaw that it purported to confirm. This study evaluates the quality of software produced by thirty-eight PhD students using either command line tools or an integrated development environment.

Context + Problem + Launching Point

Summary

States the context of the problem, but before reporting results it summarized the paper focusing on the evidence supporting the results and/or the methods used to achieve it.

Context + problem + summary + main point

CFD Software development folklaw has held that text based editors and a command line tool chain promote more serious work than do integrated development environments (IDE), a belief that seems to be confirmed by Jacobs (2009). But Jacob’s study was based on the same folklaw that it puported to confirm. In this study, thirty-eight PhD students in Mechanical Engineering whose work involved software development were randomly assigned to use one of two development environments, one with a Unix command line tool chain supported by the vi editor and the other with the Eclipse IDE. Software produced was evaluated on three criteria: content, format, and testability. The two groups did not differ in any of the three criteria.

Context + problem + summary + main point

You want people to read your paper!

Nowadays, most people identify papers of interest to them using search engines that look for key words in titles and abstracts

Help them find your paper, by imagining yourself searching for it.

Ask yourself, what words would I use if I was looking for this paper.

Put in your title and the abstract.

How do I start?

Here’s a three step formula I’ve found helpful 1. Topic: I am studying _____ 2. Question: because I want to find out

what/why/how _____ 3. Significance: in order to help my

reader better understand _____

Understand your aims

If you are still struggling to write, its probably because you are confused about what you are writing about.

Seek clarity by articulating your aims.

The aims of this work are 1. …

2. …

3. ...

Critique the following

Critique the following

Critique the following

Some final thoughts …

An abstract must be a fully contained description of the paper

It must make sense all by itself

Keep in mind Word count limitations Danger of using ‘weasel words’, e.g. might , could, may, and seem Make sure the keywords you pick make assigning your paper to a review category and finding the paper once its printed obvious