My first Overleaf paper

.

Overleaf

This blog post can only be interesting for colleagues of mine and other researchers who work in academia. You have been warned.

It's a bit weird to realize that I hardly ever write about concrete work practices that play such a large role in my daily life as an associate professor (researcher and teacher). I never write about how email structures my day or the fact that our sustainability research group has a Slack channel that is more active now (during the Corona shutdown) that ever before. The one tool that rivals mail in my everyday life though is Google documents. We use them for everything in our research group. A new [something] almost always starts with a new Google document. In our FLIGHT research project (that started in mid-2019) we (this far) have documents for:

- the research project application (the actual application + another document for brainstorming-about-the-text)
- running meeting notes from our weekly meetings in the project
- a GANTT scheme for when what (pre-Corona) was supposed to happen when in the project
- a variety of data (several spreadsheets)
- a list of research articles of interest (which has now been superseeded by a shared group in the reference tool Zotero)
- brainstorming ideas for new research papers
- each paper writing project we consider or initiate (on document with the actual text/academic paper + another document that is used for brainstorming about the text)
- a rebuttal that we wrote when a research paper was "conditionally" accepted (the paper was later accepted)
- another research grant application we were part of + a brainstorming document
- another future add-on and follow-up research grant application (after this project finishes)
- saving links to news articles, blogs and other resources of intest to us (including universities where interesting things happen and persons of interest)
- discussing criteria etc. for hiring a PhD student in the project (the document is from half a year ago, we have now hired someone who started to work with us recently)
- the research workshops we were supposed to do now but that have been Corona-postponed
- the test workshops Elina conducted in Lancaster (UK) when she travelled there in February
- discussing what departments we are or have recruited for the research workshops (one per School at KTH)
- discussing upcoming project presentations (including what exactly to say)
- project proposals for a project course (one group chose to work with us)
- a slide presentation with thesis opportunities (for master's and bachelor's theses students) (ten students are working with us in 5 pairs)
- another slide presentation (pitch for students in a project course) (three groups chose to work with us)
- there's also a folder that contains all our FLIGHT-related google documents

There are certainly more documents, but these are the most important shared documents. To keep track of everything I have a personal "document of documents" with links to everything (se image below). Every time I create a new google document, I also create a link to the new document in my document of documents. I'm unfortunately not equally good at removing old links (the document is currently 25 pages long).

My to-do list with links to all my Google documents

When I write a paper together with one or several coauthors, we usually start with one or more brainstorming sessions (preferably with a whiteboard nearby). Later on we look for the "main argument" of the paper and start to structure the idea(s) in a Google document. We then use a shared Google document to write the paper and end that process by transferring the text to the asked-for format of the conference or journal in question. My new PhD student, Aksel, only started to work with us recently, but has already (multiple times) suggested we should use Overleaf for final formatting work - and preferably also to use if from start to finish when we write papers. It's a hard sell since we have worked with Google docs for years and years and by now have fine-tuned structures and practices according to the affordances and limitations of Google docs. I suggested that when he eventually takes on the responsibility of being the first author of an article, he will have extended possibilities to decide how we will work (e.g. what tools we should use for that "writing project"). So far, so good.

And then there's the ACM new-and-improved format guides about what papers should look like. I'm not sure they are better than previous format guides - but they are for sure more complicated (on top of the previous also being complicated). So we had a deadline for submitting a paper this past Friday and I was the first author of that paper. Aksel convinced me we should "pour" the text from our Google document into Overleaf instad of Microsoft Word and I accepted the challenge since Aksel's suggestion also came with an offer for a one-hour private lesson on how to use Overleaf. I have in fact used Overleaf before (some), but I have to say the one-hour just-in-time lesson was a game changer. It was enough to get me going and for me to manage to do most of the job myself (Aksel later checked in to fix some things I didn't know how to easily manage, like placement of images and formatting of a table). So what's the verdict? Well, I have to say I'm impressed by the level of control you can have over what a document will looks like when you use Overleaf. Although I of course still have much to learn (Overleaf is very powerful), the level of control that you can have over the tiniest of details appeals to me as a control freak. I'm however even more impressed by the smooth integration between Overleaf and (in this case) the ACM reference format guide, as well as by Overleaf's handling of references.

I don't yet know if this will affect how we go about to write papers, but I suspect we might never again use Microsoft Word for final formatting and for other tasks that are related to the appearance of a document. I honestly don't know why I haven't switched earlier. Overleaf's power comes from (left in the image below) being able to work either with Rich Text (which very much looks like any document in any word processor) or directly with the source (running text + codes for describing the appearance of that text) - and then on the fly being able to generate a pdf of what a final version of the text would looks like (right in the image below). You can thus repeatedly experiment with code and generate a new pdf on the fly to see what the results will look like. It's not WYSIWYG (What You See Is What You Get), but what you loose in interactivity you gain in sheer control over every detail of the text's appearance.

Two examples (see image below):
1) keeping global average temperature \emph{“well below 2°C”} specifies that "well below 2°C" should be emphasized (in italics).
2) \section{From Moore’s law to the Carbon Law} specifies that "From Moore’s law to the Carbon Law" should follow the ACM rules for what a header should look like - and as an author I don't really have to care what exactly they look like (right image)

View in Overleaf. Source code to the left and final appearance to the right.

.