Some tips and tricks when writing academic papers

I have been teaching the course Research Methods, Tools and Issues in our MCT programme this semester. The last class was an “open clinic” in which I answered questions about academic writing. Here is a summary of some of the things I answered, which may hopefully also be useful for others.

Formatting

Your academic exam paper is not the place to experiment with fancy layout and formatting. Some basic tips:

  • Template: Choose a conservative template (but not too old-school). Check that it is in A4, as templates using a North-American “letter” paper size looks weird when/if printed in A4.
  • Font: A serif font typically looks more serious than a sans-serif, so “Times New Roman” or something similar is the safest choice.
  • Paragraphs: There are different ways of formatting paragraphs. The two most common ones are: (1) indented first lines, (2) spaces between lines. The first type is the most common in professional type-setting and is what you see in books and academic journals. It is also the most space-conservative. Making spaces between lines is what most people do when they write on computers. Choose whichever type you want, but do not mix the two.

Writing

It is impossible to cover everything about academic writing here. But these are the things I usually comment on when I supervise:

  • Long sentences: It is better to write short and meaningful sentences than long and complex ones. Many students think that their text will look more academic if they make long sentences. The truth, however, is that it is much more pleasurable to read well-formed and meaningful sentences. The general rule of thumb is to include only one point in a sentence. If in doubt, start a new sentence. It also helps to read your text out loud. Whenever you feel that
  • Short sentences: Some students only write very short sentences. This is not good either, so find a balance.

Spelling and grammar

Whatever you do, ensure that your texts are not full of spelling mistakes. You should also reduce the number of grammatical errors. There are so many tools available to help you these days, so there is no excuse for not using them before you submit your final text.

Figures

Figures are nice, please include them! But when you do, always think about this:

  • Label: Figures should always have a figure name (“Figure 1”) followed by an explanation of what the figure is about (“This figure shows…”). Ideally, the figure text should be sufficient to understand what the figure aims at conveying of information. Many people (like myself) like to browse through papers and books quickly, and use the figures as a way to quickly navigate the content. Then it helps if the figure texts are self-explanatory.
  • Text size: Figures are often made in different software than where you write. This means that you typically do not have full control of their size in the final layout, hence the text inside of the figure may be too large and too big. As part of the final layout, you should try to make the text size similar to the text size of the main document within which the figure is placed.
  • Units, labels and legends: If you include graphs or other types of representations of numbers, it is critical to include information about what the axes mean and the units that you have used (“Time (s)”, “Number of people”, “Vertical position (mm)”). You should also have clearly marked legends (if relevant) to explain what the different lines in your figure are.
  • Simplify: You should always aim to remove unnecessary stuff from figures so that the most important things are what people see. This follows Tufte’s ideal of aspiring for a high “data-ink ratio”.

References

Adding references to your text, and including a bibliography at the end of your document, is the clearest sign that you are writing an academic paper.

  • Consistency: Ensure that all citations have an entry in the bibliography. Similarly, all entries in the bibliography should be referenced in the text.
  • Reference manager: Use a reference manager to keep track of everything. While it is not perfect, I generally recommend Zotero. It works on all platforms, has an online front-end, and integrates with many writing platforms.

Submission

  • PDF: If you are not asked to do otherwise, always submit a PDF file. This will ensure that both content and layout are preserved for the final reader. Submitting your “raw files” (.docx, .pages, .odt, etc.) is problematic for a number of reasons. First, they may not be readable by people on different platforms (.pages files only work on OSX, for example). Second, often such raw files contain the history of the file, which you may not want the end reader to see. This may be particularly important if you have been using track changes.
  • Good naming: Always give your file a useful name. If your exam is anonymous, include your candidate number in the file name. If not anonymous, include your last name. Your examiner will probably download a zip-folder with all submissions. Having a bunch of files with names such as “exam.pdf”, “submission.pdf”, etc., is annoying.
  • Supplementary files: It is often fine/useful/required to submit supplementary material. Then it is usually good to have a list at the end of your main document describing what you have chosen to include (for example, a list describing audio files). If you have many supplementary files, you should zip them down and give them a useful name. Again: remember that the reader will download your submission together with a bunch of other things. It is your job to make the read as pleasurable as possible.

General form

The standard “IMRAD” form of a paper looks like this:

  • Abstract
  • Introduction
    • Motivation (could include a rhetorical question/something catchy)
    • Research question(s)
    • (Hypotheses)
    • Definitions
    • Limitations / scope
    • Overview of the paper
  • Background (either chronological or topical)
  • Methods (be precise – explain what you did, how, etc)
  • Results
  • Discussion
  • Conclusion

Many interaction papers, and also “NIME-like” papers, have a form something like:

  • Abstract
  • Introduction
  • Background
  • Method
  • Design
  • Implementation
  • Evaluation / Discussion
  • Conclusion

Converting MXF files to MP4 with FFmpeg

We have a bunch of Canon XF105 at RITMO, a camera that records MXF files. This is not a particularly useful file format (unless for further processing). Since many of our recordings are just for documentation purposes, we often see the need to convert to MP4. Here I present two solutions for converting MXF files to MP4, both as individual files and a combined file from a folder. These are shell scripts based on the very useful FFmpeg.

Convert individual MXF files to individual MP4 files

The first solution is based on converting a bunch of MXF files to individual MP4 files. This is practical if there are multiple, individual shots.

Save the script above as mxf2mp4.sh, make it executable, with a command like:

chmod u+x mxf2mp4.sh

and run the file:

./mxf2mp4.sh

Convert a folder of MXF files to one MP4 file

The second solution is when we have made one long recording, which is split up into individual MXF files of 1.9 GB size (the maximum size of FAT32-formatted drives) in the camera. Then the aim is to merge all of these together to one MP4 file. This script will do the trick:

Do the same as above to run the script.

Tips for doing your job interview over Skype

I have been interviewing a lot of people for various types of university positions over the years. Most often these interviews are conducted using a video-conferencing system. Here I provide some tips to help people prepare for a video-based job interview:

  • We (and many others) typically use Skype for interviews, not because it is the best system out there (of commercial platforms I prefer Zoom), but because it is the most widespread solution. The most important thing to do when preparing for an interview, is to check that you have the latest version of Skype (or whatever other program is required) installed. You don’t want to get an upgrade button when you are starting up for your interview.
  • Ensure that you have a reliable Internet connection. If you can, use a cabled connection. It will most certainly be more stable than wireless.
  • Only use your mobile phone in an interview if you do not have any other options, or if your computer fails in the last minute. Even though you may be used to talking to people from phone to phone, remember that your image will most likely be projected on a big TV/screen, and your sound will be played over a speaker system. Then the “phone quality” will certainly be visible/audible. Also: if you do use your phone, remember to put it in landscape mode. Otherwise, the image will look weird when it only covers a small part of the projection.
  • Sit in a suitable place where you will not be disturbed and where there is no noise. Avoid public spaces in which people may walk in on you.
  • To obtain the best possible video image, think about your placement with respect to lighting. Do not sit in front of a window, since a bright light in the background will make it difficult to see your face. It is better to sit in front of a plain wall with light in your face. If you don’t have a plain wall at hand, consider whether the background is suitable for an interview situation. I have seen all sorts of weird images, messy rooms, etc. This does not give a professional impression.
  • Do not sit with your computer in your lap. Then it will move all the time, making the committee seasick.
  • When positioning yourself in relation to the camera, remember that most likely you will be shown on a large TV or projected on the wall. It is better to sit so that your entire upper body can be seen. Otherwise, your face will be big!
  • Use a headset with a microphone located close to your mouth. This will pick up the sound better than most built-in computer microphones. Using a headset will also prevent feedback during the conversation, and it will not pick up sound if you are typing on the keyboard.

If you experience any issues with your setup, stay calm. Remember that the committee will be positive towards you, otherwise you would not have made it to the interview. Committees are used to all sorts of issues in video-based interviews. Sometimes the error is also on our side. Seeing how you tackle the stress of an unforeseen situation may convince the committee about your personal qualities.

Good luck!

What tools do I use for writing?

Earlier today I was asked about what tools I use when writing. This is not something I have written about here on the blog before, although I do have very strong opinions on my own tools. I actually really enjoy reading about how other people work, so writing about it here may perhaps also be interesting to others.

Text editor: Atom

Most of my writing, whether it is e-mail drafts, meeting notes, or academic papers, is done in the form of plain text files. I use different text editors dependent on what computer/platform I am working on, and that is also one of the beauties of text files. They work everywhere. On my main laptop (running Ubuntu Studio), I primarily use Atom as my main text editor. This is mainly because it is cross-platform, has some plugins that are useful, and has excellent integration with Github.

Most of the time I write using markdown, which is just a structured way to write text files. The nice thing about markdown formatted text files, is that they can easily be converted to other formats using Pandoc. I often have to send off files as either PDFs or DOCX files, and this can easily be done with a terminal command such as:

pandoc file.txt -o file.pdf 

Yes, it is a nerdy way of writing things, but working in a text editor (as opposed to a word processor) is just so much quicker for many things. I use quite a lot of advanced query-replace functions, for example, and then regular expressions are useful. I also like to be able to do multiline editing.

Academic writing: Overleaf

I usually start my academic writing with notes in markdown, but as soon as I start to get into the proper writing mode, I convert into LaTeX. This is also a text-based format, but with a slightly more complex (and also more powerful) syntax than markdown.

Since most of my academic writing these days is collaborative, I almost only work in the web-based LaTeX editor Overleaf. This editor makes it possible for multiple users to work on the same document, and it also handles the compiling into PDFs very nicely. Being a web app, you don’t have to install LaTeX locally on your own computer. This makes it much easier for people to get started with LaTeX than it used to be only a few years ago.

Academic references: Zotero

Zotero is my current reference manager. It is not perfect, but I like that it is cross-platform (and by that I mean Windows, OSX, and Linux), it has a web interface, and it synchronizes between systems. There is a connection from Zotero to Overleaf, but I have found this to be somewhat shaky. So most of the time, I just export a BibTeX file of my complete library from Zotero, and import that .bib file in Overleaf.

Other collaborative writing: Google Docs

When I am writing non-academic texts with others, such as administrative documents, reports, and so on, I typically use Google Docs. I have been using it for several years now, and it really shines when it comes to collaborative writing and editing. I try Office 365 from time to time, but it just cannot compare to the trouble-free collaboration I experience in Google Docs.

Word processor: LibreOffice

When I have to use a normal word processor, it is usually LibreOffice. I never start writing in LibreOffice myself, so this only happens when someone sends me a .docx file that they want me to look at. Fortunately, LibreOffice handles .docx files well most of the time. So I am able to edit documents using “track changes” and send them back to people using MS Word.

In those few cases where LibreOffice does not manage to handle the .docx documents I receive, I connect to a remote desktop at the university and fire up MS Word. This is typically when there are some weird macro functions in the document, or some strange fonts. Fortunately, this happens only once in a while.

Summing up

All in all, I am quite happy with my current set of tools. Relying on text files has worked well for me for many years now. They are also the most future-proof solution I can think of. My software tools will continuously be replaced, but I am sure that plain text files will be around for a long time.