Findings: Your lab notebook, reinvented | Hacker News Reader

Findings: Your lab notebook, reinvented

findingsapp.com

39 pointskluivers16 comments

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.

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.

Good idea, and no, we don't have anything like that at the moment.

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.

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.

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.

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.

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.

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.

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

Sorry to bring up the whole native vs web app debate, but this kind of app is actually a good fit for a native app: access to files, very specific workflows requiring fine-tuned user interface and user experience. Not impossible to do in a web app, but much harder to do right, particularly when your main competitor is a paper notebook that has so much flexibility and is so easy to use.

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.

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.

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.

Looks like they'll be adding export soon: "Can I print, export, share an experiment or a protocol? The initial version of Findings has not implemented these features, but it is coming very soon. Most of the implementation is ready, but it requires a bit more work for integration, and it was not done on time for the 1.0 release. Our apologies for the delay! But please let us know what you need, so we'll do our best to include it."

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.

Reply on news.ycombinator.com