Recordkeeping; lab notebooks

If it’s not written down, it didn’t happen.

https://www.researchgate.net/publication/297922054_‘If_it’s_not_written_down_It_didn’t_happen’

Everything not saved will be lost

I frequently forget to finish my sentences or add background context, etc, when making logbook records.

One strategy I’ve found helpful is to return to the record a few hours, days, weeks later (either by setting a specific date to return to a certain document), after the sourrounding context is a little less fresh in the memory and after the immediacy and excitement of the experiment is no longer, but before all the details are forgotten - and make sure it still makes sense.

That said, one thing to keep in mind is, if it wasn’t recorded contemporaneously, it probably won’t ever be recorded at all.

For electronic lab notebooks with version control, I find it important not to be afraid to boldly restructure. If it will help the reader understand and find the important information, don’t hesitate to move sections, split one big document into subpages, merge snippets into an overarching summary.

Another is not to be afraid to duplicate information in multiple places, if it makes sense to do so.

Sometimes, in the moment, it doesn’t make sense why you need to record a piece of information.

For instance, we had certain pump wear out. We bought another one, and it was installed, and it worked the same way as the other one. There wasn’t a clear rationale why a nice logbook entry should be written out for a routine action which has no scientific value.

It turns out, however, that this was part of a pattern of failures, and it was later necessary to go back and analyze properties. I was very fortunate that I had written a short blurb on when this action had taken place.

You don’t know in advance what you will need the information for - so record more than you think you need.

Some tips from the late Bill Stanley on lab notebooks:

Be as detailed as possible. Finish your thought now - don’t put it off. Be complete, be thorough. Record your observation, get’er done.

Sometimes you need to follow a procedure that’s been written in e.g. a wiki format. I’ve found it useful to print it into a PDF “worksheet”, then use a PDF markup editor to add freehand annotations (like check marks, and comments on things that need to be altered to the procedure or record results contemporaneously). That worksheet then gets dated and can be uploaded back to the wiki to close the loop.

This works pretty well. Pretty much the same as printing out, except this way you can upload the annotated version to show which parts were done and which were skipped, and notes are kept.

https://www.loc.gov/resource/magbell.21700201/?sp=1&st=grid

Scientific photographs

make a habit of keeping photos of equipment up-to-date in their working state - I’m thinking especially about wiring, but I’m sure this would be equally applicable for other physical hardware - on some schedule, and especially before and after making any changes.

You can write a lot of text documentation and still miss essential points; pictures can help to fill in info that you didn’t think to capture beforehand.

We had issues while troubleshooting a rack of equipment; it turns out some cables were mis-labelled. Luckily, an old picture of the system had the rack visible in a corner, and it was easy to identify that some connectors had been put back in the wrong places. It would have been a nightmare to re-construct otherwise.

nanographs - adam mccombs - has got this down pat. Network-connected DLSR with umbilical, dedicated time cut out for taking pictures as equipment is being worked on.


https://earthobservatory.nasa.gov/blogs/fromthefield/category/above/

Clarity, Conciseness, Completeness, Confidentiality, and Chronological Order

The Impact of Structured and Standardized Documentation on Documentation Quality; a Multicenter, Retrospective Study

Furthermore, results showed that structured notes were significantly longer than unstructured notes, but were more concise nevertheless.

This study showed an overall increase in documentation quality after the implementation of structured and standardized recording. In 8 of the 11 elements measured with the Qnote instrument, a significant increase in quality was found. This result may be explained by the fact that relevant elements and items that have to be documented are presented to the health care provider in an intuitive, uniform way. Therefore, clinicians are less likely to forget certain elements and items within the note. Furthermore, repeatedly recording in the same format ensures the physician is trained to record properly and completely.

In clinical sites, much energy is expended to facilitate correct and proper documentation. At its best, documentation is usually timeconsuming and laborious—a combination guaranteed to result in avoidance behaviors and slapdash execution. In an effort to help, institutions have developed every permutation of checklist, abbreviated charting convention, and electronic, tape-recorded, and transcribed format. Somewhere on the dusty shelves a generic “progress notes” form is waiting to be used when longhand, detailed recordkeeping cannot or should not be avoided.

https://www.ons.org/pubs/article/11306/preview-download

Some reflections from reading some old hardcopy lab books:

  • Colored flags for different events helps a lot in drilling down to where something happened.
  • In this setting, there was one continuous stream of lab books filled out linearly and continuously.
    • There’s a lot of emphasis nowadays on having e.g. scan or acquisition software that keeps track of parameters automatically, bakes . It’s good to have a reminder that this isn’t the only paradigm that works. being trained to record sufficient records, irrespective of
  • frequent, “business as usual” operations - regular calibrations, etc - that fill up the book - can drown out or dilute rare important events or findings. this is something to keep in mind for elogs as well.

Outputs

  • Many datasets are collected. For simple, instant analysis - first-order plots - these are put inline. However, more exhaustive analyses often get communicated in e.g. emails to PI, personal logbooks. That means, reading though, you don’t really get a good idea of see the outcome.
  • Choose some system for ensuring that later outputs get merged, referenced.
  • On an elog this could mean splitting each doc into collection and analysis and having specific links back and forth.