Productivity tools, coherence and friction

After starting my graduate studies last year, I have tried various research tools to search for a suite of tools that would help me to perform my research activities (mainly reading and writing) more efficiently and productively. My requirements of these tools are - able to streamline current activity individually while also work together as a whole between tools, essentially fit into a coherence personal workflow. The word personal is important here. I realised that there is no one-size-fits-all tool, although I guess the tool designer would like to accommodate as many peoples/customers as possible. It was an interesting journey so far….

Being a novice in the research world, I was overwhelmed by the mountain of tools and options out there to help students/researchers to perform a literature review, writings, analysis, coding, etc. Which one should I choose? I asked myself.

As I have documented about my experience with EndNote, Papers 3 and Scrivener, my first approach was to pick a tool that is commonly used so that if there are support available when things go wrong. Then, I will use it for a while to see if I like it and whether it allows me to transition from one tool to another tool with less friction or ideally no friction. Here, friction means the feeling of discontinuous (stop-and-start-and-stop-and-start) when switching tool or activity. This part is very subjective; thus, different people will have different opinions about things. There is no right answer here. Choose the tools that allow you to move smoothly and swiftly without disrupting your thoughts or ‘flow’, if I may use this word. Here, continuation or coherence is what matters here, to allow your current ‘train of thoughts’ flow to another tool before it disappears (train is continuous, a broken train is discontinuous), or you are distracted because of the other tools, or due to context switching (i.e. switch from one task to another totally different task quickly - multi-tasking - won’t work).

Perhaps this coherence is what makes all-in-one integrated development environment (IDE) so popular - eClipse, Microsoft Visual Studio, Visual Studio Code, Emacs, vim, etc. You have your familiar layout with your favourite themes and colours, and then you can perform most activities within the same “environment” without changing. That is less friction or friction-less. Without less friction comes efficiency and productivity (time saved! not just the time between switching, but not disrupting your current thoughts can save heaps of time and able to complete the task at hand!).

Here I would like to share some of the lessons that I learnt during a few iterations of selecting some tools:

• Just ‘try’ it - instead of worrying about whether that is the ‘best’ tool, just get your hand dirty and try it for a few hours/days/months.
• Try it with a small amount of data/documents before committing to the tool, and prepare to move on if it does not feel right. With small data, you can switch quickly without wasting huge efforts of migrating the data to another tool. For example, I was trying out NVivo as a potential literature review tool, so I used it to do a small literature review in a particular area and see if it fits the purpose. While there are many tutorials out there already published on how to do it, I think most importantly is what you feel the tool provide to you, rather than what others are using. It may not be the ‘right’ tool for you.
• If possible, try “open” format rather than tied to a proprietary format as much as possible. Although a lot of tools nowadays allow you to export and import to another tools seamlessly, it may not work all the time. “Open” format is a standard format that is supported by multiple tools, for example, PDF, Plain text file (TXT), Markdown, HTML, etc. With “open” format, you can switch to another tool if you prefer the look-and-feel or design of the tool. More options really.
• If possible, do not spread the same information across multiple tools. For example, if you are using a bibliography manager such as EndNote or others, then any other tools that refer to the same paper/article/book entry in EndNote should use a reference key, such as Pandoc citekey [@AuthorYear] or other format. So that you have one central place for your bibliography. Hook is a great little utility to promote this type of cross linking between apps if you are keen. The main purpose of having one place is reducing the efforting of syncing and possibly a scenario of out-of-sync.

These suggestions are mainly focused on personal workflow. Things could become a little challenging when multiple peoples working on the same piece of work, such as reviewing papers with collaborators, sharing bibliography, etc. Finally, here are some tool preferences that you may come across: Emacs vs vi, Mac vs windows, Java vs .NET, Android vs iOS, Java vs Javascript, compiling vs interpreting, curly bracket at the same line vs next line, camel case vs underscore 😵 😵 😵.