Many years ago I picked up a nice idea on how to write abstracts that efficiently convey the idea of a paper. Unfortunately, I don't remember where I read it, so I can't give proper credit.
The idea is that you should write your (first version of the) abstract using only four sentences:
Sentence 1: State the problem
Sentence 2: State the consequences of the problem
Sentence 3: State your solution
Sentence 4: State the consequences of the solution
This makes a very to-the-point abstract. Sometimes these work right away and sometimes they have to be refined through multiple iterations. If they need further iterations, the four-sentence abstract is a great starting point.
Examples:
Most hamburgers are larger than what can be held with one hand. This makes them hard to eat. We present a new type of hamburger, called the Hand Burger, that is small enough to hold in one hand. Experimental results show that the Hand Burger increases eating speed by up to 150%.
The node_modules directory of Node JS applications often contain multiple copies of the exact same file. This increases the size of the node_modules directory and decreases application startup speed. We have developed a caching scheme for Node JS modules that maintains a single copy of each unique file. This mechanism reduces the size of the node_modules directory by 75% for the most commonly used Node JS applications and increases startup speed by 25% on average.
Horse-drawn carriages have a hard time moving on land because of vegetation. This makes travel slow, or outright impossible. We present a novel concept that we call roads. Our measurements show that roads decrease travel time from years to days to reach the 20 most popular destinations throughout the Roman Empire.
That seem to be excellent advice. It touches on one of my pet peeves when reading articles. Why is it so hard for authors to provide examples? Many times they describe elaborate algorithms but do not describe how they would operate on real data so you have to try and decipher that. If you hadn't added the three examples to illustrate your point, I wouldn't have understood it. But since you added them I understood it perfectly!
I don't think this is limited to articles! I'll often read the documentation for some library or tool and I'll encounter a weird flag or option where I end up wondering: what is this for? When you're not incredibly familiarized with a problem domain it can be hard to figure out the purpose of a lot of things.
By providing real examples you also help the reader build up a mental index in case they ever have to deal with a similar problem.
Too many people write an abstract as if it's a preamble to the paper. If a person has to inspect your paper in-depth to see what results you got, reconsider your abstract.
That depends on the goal of your writing. Technical writer like to think they are above such things, but often the goal is less to convey information and more to keep eyeballs on an article. Sometimes you want to give the customer what they need as efficiently as possible. Other times the goal is to hold their attention as long as possible. You have to adjust you writing to both the audience and the desires of your publication medium.
Oh yeah ok. I'm talking about academic writing. I'm sure some academics' work will always be read, whether because they're well known, do good work, are active in communities etc. However when a large chunk of publications are never even cited, it's not a good idea (imo) to make your papers read like a mystery novel. "I can't wait to get to the end to see how many fractions of a % they increased precision by!"
Back in the day, as I was beginning my career as a research scientist (https://scholar.google.com/citations?user=5DdrMc8AAAAJ&hl=en), I had a revelation: write the paper first, and the abstract becomes trivial. Since any serious research aims to end not just with an abstract for presentation at a specialty meeting but also a published scientific paper, such an approach is far more efficient and makes one much more productive as a working scientist. Granted, it's far harder to write a paper than an abstract, but once you've bitten the bullet and done so, the ease and pleasure of pulling a sentence or two out of each part of the manuscript's Introduction/Methods/Results/Conclusion, packaging them neatly into a single paragraph, then submitting the product to an upcoming meeting, is sublime. Plus, this completely eliminates the tendency to stop with an abstract because the wall of the complete paper seems too high and formidable. So many of my fellow department members seemed to produce abstracts that never went any further because of the degree of difficulty of producing complete papers. Bonus: tenure committees reward published papers, not abstracts.
A few years ago i found a great version of a similar piece that proposed something like a 'sandwich' model for each section, and the work as a whole. A sandwich layer was a hook (something interesting), the meat (what you actually did), and a summary.
I failed to save it and i haven't been able to dig it up again, but I liked the idea. The paper was written in the style it described, as well.
> The five-paragraph essay is a format of essay having five paragraphs: one introductory paragraph, three body paragraphs with support and development, and one concluding paragraph. Because of this structure, it is also known as a hamburger essay, one three one, or a three-tier essay.
The digraph presented in the OP really is a great approach, IMHO:
EDIT: reading @adtac's reference, it also recommends "Writing Technical Articles"[1] as an additional reference (the URL in the paper is not copy-pasteable because of a unicode tilde)
Very good read but I'm starting to wonder about formatting. Is the standard 2 column format still preferred when most reading is done on a screen? I frequently find myself scrolling up and down a single page when I zoom into something.
A paper on how to write good papers should not start the abstract with a complex and wordy sentence. Indeed, the entire first paragraph of the abstract could be put more directly.
The idea is that you should write your (first version of the) abstract using only four sentences:
Sentence 1: State the problem
Sentence 2: State the consequences of the problem
Sentence 3: State your solution
Sentence 4: State the consequences of the solution
This makes a very to-the-point abstract. Sometimes these work right away and sometimes they have to be refined through multiple iterations. If they need further iterations, the four-sentence abstract is a great starting point.
Examples:
Most hamburgers are larger than what can be held with one hand. This makes them hard to eat. We present a new type of hamburger, called the Hand Burger, that is small enough to hold in one hand. Experimental results show that the Hand Burger increases eating speed by up to 150%.
The node_modules directory of Node JS applications often contain multiple copies of the exact same file. This increases the size of the node_modules directory and decreases application startup speed. We have developed a caching scheme for Node JS modules that maintains a single copy of each unique file. This mechanism reduces the size of the node_modules directory by 75% for the most commonly used Node JS applications and increases startup speed by 25% on average.
Horse-drawn carriages have a hard time moving on land because of vegetation. This makes travel slow, or outright impossible. We present a novel concept that we call roads. Our measurements show that roads decrease travel time from years to days to reach the 20 most popular destinations throughout the Roman Empire.