Findings Beyond Science & Research
The scientific workflow can be applied successfully outside the realm of research. With Findings as your guide, why not give it a try for your everyday experimentations and your personal projects?
Findings is primarily aimed at researchers and scientists, but the scientific workflow is something that can successfully be applied to many situations, with great benefits. Findings encourages experimentation and can help improve any kind of process or workflow that depends on multiple parameters or needs to be adapted to various situations. Which is pretty much everything in life, right?
In this post, I will go over 3 examples. To help with the reading, each example can be toggled on and off, so you can pick and choose. But be sure to give at least a quick look to each of them, as you'll see different features of Findings highlighted for each case.
Not enough candy
You have a nice cupcake recipe. Sometimes, they turn out amazing, and sometimes, usually when it matters most, they turn out… meh. Alas, you can't figure out what makes a difference.
The problem is you don't always remember what modifications you make and you certainly can't tell which ones matter for the final result. It's time to take things to the next level: be a scientist!
Now, every time you start a new batch of cupcakes, use the recipe to start an 'experiment'. This is best done using the calendar view of the experiment and dragging the protocol on the current date. When you switch back to the text view, you will see the recipe text, duplicated as part of the experiment. You can follow along the steps, marking them done as you go. You can also modify the experiment content if you tweak a step, or want to add a note. These changes will not affect the original recipe from your protocol library, since it is a copy.
After tasting, you can rate your experiment and add a picture of your creation. You can also type a few lines about the results, the conclusions from this batch, with some ideas on what to try out next time, and what to watch out for. Speaking of which: next time, you can also use the 'duplicate' functionality to create a new 'experiment' with the same content as last time, ready to be edited further! This way, you can be sure to keep track of new tricks and new improvements to your recipe. And of course, to make sure you can easily get to all your cupcake variations, keep all your cupcake experiments in a 'Cupcake' project.
Who said it's not fun to prepare your taxes? OK, maybe it will never really be fun, but at least, it could be less painful and more satisfying. Every year, it's the same process, the same forms, the same painful calculations, the same googling around. Yet it feels like starting from scratch, every year. And actually, one of the most annoying part is that it's not always quite the same.
You know an activity where carefully reproducing things, keeping track of parameter changes while still controlling every aspect of it is critical? Science!
In this example, I'll talk about tax preparation, but it could be used for any recurring paperwork chore, like renewing an ID, registering your kids for school, getting a new parking pass at work, etc. In all these cases, the goal is to make it much easier and much faster for your future self, with very little work for your present self.
With Findings, each tax preparation is a new 'experiment' (and you'll get better at it every year). The idea is simple: just like you would do if testing new antibiotics or creating a new rocket, you write down every task you perform, as you do it. With Findings, it's easy to drag forms and helpful files next to your text, and write down distinctive notes with any piece of advice for your future self. One thing I always do with online steps is paste any relevant URL, and write down what to click on, because there seems to be an unavoidable law with administration websites: the more common and important the task, the more convoluted and byzantine the process.
Findings is also very useful for tasks that may span several weeks or months, for instance if there are several steps that each may take a week or a month. By writing down what you do at each step as well as what you should do next, you'll be always prepared and it will be much easier to overcome procrastination. Findings naturally connects all the related tasks spread out over time, as they are all kept in the same "experiment", with special headers for dates.
As you build knowledge and experience over the years, you don't have to repeat yourself. Even things you did only once, three years ago, become easy to do right, without all the usual head-scratching. Each new tax preparation, each new passport renewal, each school bus application, is more efficient, more accurate and less annoying than the previous one, leaving you free to focus on all the other, actually fun stuff in life.
Yes, yes, premature optimization is the root of all evil. But surely it's ok to improve performance in version 1.5 when users start loading the app with thousands of documents and complain about scrolling lag.
Optimizing performance can be a long and menial task. You need to carefully measure the impact of each code change, which needs to be done in a controlled environment. You may require to refresh your application state, load some specific resources and wait for the new code path to be executed in a reproducible way. Next, you will need to dig through a bunch of stack frames and extract the needed information. When you embark on a performance improvement spree, rigor is de rigueur. That's a job for science!
For this example, what could possibly be better than actually showing you how I used Findings to keep track of performance improvements done on… Findings itself! The initial situation with Findings 1.3 was slow performance when opening large experiments or protocols: loading would lead to the dreaded spinning beach-ball (unresponsive app), typing resulted in a very noticeable lag, copying or pasting would take more than 1 or 2 seconds, etc. This was only happening in large documents, and was manageable, but this was not the experience we wanted for any of our users, and there was no reason why Findings should not behave correctly even in heavy use.
First thing first. I created an experiment with a clear title, and wrote down the aims for this performance cleanup session. Just typing a few lines before you get started can really help in establishing a clear goal, and will keep you focused on that goal.
Next, it was time to define the methodology for the experiment: (1) put the app in a condition where the performance issue would be clearly visible, and (2) measure the activity of the app using the Instruments app with the 'Time Profiler' template, both when opening the document, and when typing in the document. For this, I created a test document with 10,000 lines of text, spread over 100 days.
By following those steps, I obtained my first results. The raw output is a bunch of stack traces in an Instruments file. With Findings, it's easy to drag this into the experiment and have the file inline with the rest of the text. But of course, I also had to dig into those stack traces and extract some useful information. To document this, I found that taking screenshots of the relevant bits directly from Instruments is the easiest and most effective way. I took advantage of the system-wide keyboard shortcut cmd-ctrl-shift-4 which allows you to select a rectangular section of the screen to populate the clipboard with an image of the screen. After selecting the interesting parts of the screen, I switched to Findings and used the Paste menu item (cmd-V) and voilà, I had the screenshot right in the text with all the details I wanted to highlight.
What's a researcher to do with the results of an experiment? Draw conclusions! In this context, my conclusions were mostly about: which parts of the code were affecting performance, which parts I could change, and how it could be changed to potentially resolve the performance bottlenecks.
After those changes were made, I went back to starting a new Instruments session, following the same methodology, getting more results, and drawing new conclusions on how the previous code changes impacted the performance, what other bottlenecks may remain, and what to do next. After a few passes, the app performance was drastically improved! Version 1.4 will be released soon and is already available as a beta (which you can enable by going into the Findings menu, opening the preferences and looking in the 'Options' panel).
Forcing myself to write down what I did, what I found, and what to try next, helped me keep the whole task focused and consistent. The notes I was taking in Findings were a guide and a constant reminder of what I was trying to achieve. This was particularly useful to deal with unavoidable interruptions. Remembering exactly what you were doing the day before (or even a couple of hours in the past!) is not always a given when dealing with fairly complicated code paths. I am also hopeful that those notes will be useful when I embark on a new performance hunt in a future update. Another nice benefit you get for free when working in a team: easily share the results as a nicely formatted PDF… and impress your colleagues!
Everyone is a scientist!
That’s it for today! If you have questions, comments, or suggestions, on this topic or any other, let us know via email to email@example.com, to @findingsapp on Twitter or on our Facebook page.