Ever wondered what makes a good scientific text readable? Not that I’m good at it (and this blog is probably full of typos and bad structured sentences – it sure isn’t scientific writing :)) but here are some things I learned so far:
- Clear, understandable, not to long and not to short sentences that don’t confuse (loose) the reader
- Important things stressed out at the beginning of each sentence and not at the end (where reader gets lost)
- Not to long and not to short paragraphs
- First sentence of a paragraph is an introduction to what the paragraph is about (scanning first sentence of each paragraph of a paper should give a reader the idea of the whole paper’s structure and content)
- No citations in the abstract 🙂
- Abstract is the key part to make readers read further and it should explain what the paper is about (don’t make the abstract an introduction)
- Abstract has to be one paragraph
- Provide and overview throughout the paper and guide the reader
This is certainly not the whole list but just important points to consider when writing a scientific text. And practicing is what makes us better :). It’s like playing an instrument: no practice, no success.
To read more on the issue, the following links should be the good start with examples:
- Writing for Science and Technology Student, Lancaster University, Effective Learning, CELT
- The science of Scientific Writing, American Scientist
- How to Write a Paper, Mike Ashby Engineering Department, University of Cambridge, Cambridge 6rd Edition, April 2005 [PDF]
I have recently read a nicely written paper which I not only recommend for the sake of language:
Alan Dix (2010). Human-Computer Interaction: a stable discipline, a nascent science, and the growth of the long tail. Interacting with Computers, 22(1) pp. 13-27.
I had a supervisor once who’s papers were really nice to read, too. Even my wife has read a few of them just because his writing was fluent (she actually doesn’t care about CS or HCI). An example abstract from one of his papers:
User Interface Management Systems have significantly reduced the effort
required to build a user interface. However, current systems assume a
set of standard "widgets" and make no provisions for defining new ones.
This forces user interface designers to either do without or laboriously
build new widgets with code. The Interface Object Graph is presented as
a method for specifying and communicating the design of interaction
objects or widgets. Two sample specifications are presented, one for a
secure switch and the other for a two dimensional graphical browser.
