

Findings: Your lab notebook, reinvented - kluivers
http://findingsapp.com

======
dan-g
Looks really cool. How do you simulate the permanence that paper laboratory
notebooks have? I was always trained to write out everything, and if I ended
up not using a particular procedure, striking it out so it was obvious it
wasn't used but could be read by a third party whenever necessary (for legal
reasons).

There's always the honor code, but my understanding was the lack of paper
trail is one of the big issues with switching to computational means for
keeping track of scientific results.

~~~
RaptorJ
I'm not sure if this is what they do, but it seems like a solution would be
the git commit hashing procedure. So at the end of a day/worksession have the
app take the hash of ( what you entered today + yesterday's hash) so you
create a provable trail of changes.

~~~
michaelmior
I'm not sure I see why hashing is necessary nor why it provides any "proof" of
what was changed. Perhaps it's the git analogy that's tripping me up because
you can easily forge commits to appear as being from any user at any time.

~~~
charles_parnot
The problem evoked here is for your institution at which you work, to know
that their researchers are not changing the data afterwards and following best
practices. In this scheme, the user would submit the hashes to a central
server controlled by the institution. Then, the user have no way of changing
the content without them knowing.

And yes, you would need to add some authentication to know it's always the
same user, but that's a different, orthogonal issue.

For actual proof e.g. in court, you'd need a third party with a private key
used to sign the content. A little more involved... But the main point of that
would be patent litigation, and with the new 'first to file' rule in the US,
it is much less relevant.

~~~
michaelmior
If you have a trusted third party that can hold content for you, why not just
have them store the actual data? Unless of course it's very large, but that
seems unlikely to be the case in this scenario.

~~~
charles_parnot
You could actually have quite a lot of data generated in a lab, depending on
what you do. By only storing the signatures, you can have a much cheaper
service that what would be needed to store GB of data, and really focus on
other aspects that are critical for this: security, backup, user interface,
speed,... Having only to worry about backup of a bunch of signatures is a much
easier task than having to worry about backing up the actual data.

------
eaurouge
Great idea! You should find a partner to print to physical books - this may be
a simpler export option (and added feature) while you work on your sqlite-
based export. You should provide some sort of verification that notes that I
claim to have entered on a certain date were indeed entered on that date, for
inventions (although the US is now first-to-file). And you should allow me to
scribble notes on a tablet.

~~~
charles_parnot
Thanks for the feedback! Nice idea about printing. The export will be here
very soon, it simply did not make the cut for 1.0 because it needs more
testing.

Yes, the 'first to file' thing is still new enough that many scientists still
think it is useful to sign their notebooks for that purpose. There are still
subtleties to those rules, though, that we need to investigate a bit.

------
CamperBob2
Makes no sense to do this as anything but a web app, IMO. Certainly not as a
Mac-specific native app.

~~~
GioM
On the contrary, it makes perfect sense. Labs work with all kinds of data,
including samples and information obtained from human trials where privacy is
mandated by law. Sync that to the cloud, and you open a huge can of legal-
compliance worms.

By keeping local data in a local DB, this is avoided. I see on the website
that sync is coming soon. If the developer is smart, they'll allow selective
sync so that labs can choose what to upload and what to keep local, or will
offer some sort of non-cloud p2p sync solution.

~~~
charles_parnot
We do plan to allow syncing to a local network drive, if that can work. The
idea is that it will be file-based, and can leverage Dropbox, Google Drive
or... a local networked drive. Still working on it, though! See PARStore on
github for some of the basic ideas, as this is what we use for document
storage.

------
aaronem
How do they avoid lock-in? The site makes no mention of the concept
whatsoever, and I don't see anything about an ability to export, in a non-
bespoke form, all the data you've painstakingly collected in Findings.

~~~
charles_parnot
We definitely want to make sure you can always export your data. At this
stage, you have of course to take our word for it, since we do not have export
working yet. However, we also have a section in our intial user guide about
the format used to store those documents. It is SQLite-based, and is a simple
key-value store (using the open-source PARStore implementation). Also, it's
not store "in the cloud", it is on your local hard drive, and you can easily
get to that library via the preferences of the app.

