As chemists, we rely on our lab notebooks for quite a number of things. They are how we keep track of our own results, how other people subsequently repeat things, and, perhaps most importantly, how we organize thoughts and results for later analysis. The number of times I've made key advances in research by a timely re-reading of an old notebook has me convinced that proper organization and research efficiency have a direct correlation. Moreover, having a reliable way of making sure those results last as long as possible–ideally forever–is important. Microsoft outlook for mac review. A loss of research documents to a 'lab fire' or 'lab flood' is inexcusable in the modern age.
- Findings 2 0 2 – Lab Notebook App For Scientists Study
- Findings 2 0 2 – Lab Notebook App For Scientists Work
- Findings 2 0 2 – Lab Notebook App For Scientists Using
- Buy Lab Notebook
Mar 14, 2016 For scientists, lab technicians, and those in the research field/industry the Findings app is an absolute must have. Even if you haven't really considered switching to a digital record keeping/tracking tool this is the time to check it out and learn all the benefits it has to offer.
Findings is your lab notebook, reinvented. Findings is an 'electronic lab notebook', mostly targeted at researchers and scientists. Memory clean monitor and free up memory 6 0. It is meant to address a fundamental part of the scientific workflow, that was traditionally the job of paper notebooks. No sound science exists without a proper lab journal, and we think Findings can give a big boost to this process and change how researchers. Labfolder is a cloud-based Electronic Lab Notebook (ELN) that enables scientists to optimize their research data management and laboratory processes. Labfolder is a cloud-based Electronic Lab Notebook (ELN) that enables scientists to optimize their research data management and laboratory processes. A must have for EVERY scientist's research As a research scientists with dyslexia, I regard electronic notebooks as an invaluable tool in my day to day lab activities. That being said, I have tried just about every product available, and I can say with confidence that Findings is the BEST electronic laboratory notebook, by far.
Speaking of the modern age, since the day I first started doing lab work, I have sought to find a good electronic lab notebook (eLN) solution. When I worked in the pharmaceutical industry, we had an eLN that was alright–not great, but alright. I assume that, since then, that software has improved (I would love some feedback from anyone who has experience with a modern pharma eLN), but what certainly hasn't is the price: the average eLN either costs enormous amounts of money or is mostly useless in terms of its feature set. As a result, the barrier to trying a given piece of software is staggeringly high; in fact, usually the less trouble or expense you have to go through to try out an eLN, the lower the odds are that you'll actually like it enough to use it. Most of the biggest offenses in 'useful' lab notebooks come down to a lack of features (glorified text editor versus a scientific data editor), lack of integration with experimentation (how does this software fit into my work flow? Is it fundamentally as easy to use in the lab as a paper notebook?), and a lack of back-up and sharing features (I need my data to be safe, and ideally I should be able to send it to my coworkers). Honestly, the best solution I had for a long time was an Excel document that I would keep in a Dropbox folder, but maintaining that became too cumbersome after a short while.
With all of this in mind, I was intrigued to see that Mekentosj was advertising a new eLN-type software called Findings. Mekentosj is a company that I have a huge amount of respect for; they're responsible for Papers, the software that revolutionized how I read and keep track of the literature, so I really looked forward to seeing if they could solve my eLN problem, too. I've spent the past month using Findings as my primary lab notebook in an effort to evaluate it as an eLN option and I'd like to share with you my… findings. If you're short on time, suffice it to say that I thoroughly like what I see and look forward to where they take the software in the future.
In the interest of transparency, Mekentosj provided me with a copy of Findings for Mac OS and iOS for the purposes of this trial. I was in regular contact with a representative, Charles Parnot, as I used the software and questions arose. Other than that, they have had no input in this review, nor do I have any conflicts of interest with Mekentosj other than generally liking their style.
So, what is Findings? It advertises itself as a method of organizing and archiving experiments. I will say upfront that the software is designed with the life sciences in mind, especially biologists. A major feature is the inclusion of customizable 'protocols,' which can be used as pre-written notebook pages for typical experiments. More importantly, the software uses an interactive calendar feature to let you drag and drop in as many protocols as required for a given experiment and portion off time down to an hourly basis according to the demands of that experiment. The time scale the software expects you to use is on the order of days, which is typical in biology, but some of the organization features are a little more coarse than what we need as chemists.
When you open Findings, you're opened with a relatively Spartan opening screen. Unlike Papers, Findings makes use of big buttons with plenty of open space; the screenshot below is a bit misleading, given that I (intentionally) left only one active experiment, but you can see how the tiles display information clearly, if a little inefficiently. While with one experiment it looks like a waste of space, when I have a dozen or so going at once, I really appreciate the extra padding provided by this formatting. When an experiment has been edited in a given day, it turns blue and the most recent edit is displayed on the tile, making it easy to check where everything stands. Up top, on the left you can select 'Experiments,' and sort them by project and level of completeness. On the right, you can see your protocols. How useful the protocols section is to you really depends on how dedicated you are to planning ahead of time. Early on, I couldn't be bothered writing up the protocols I use ahead of time, but once I did, I found the labor of writing up a notebook page was substantially lessened. The use of protocols in this way makes setting up a routine experiment, or even just implementing a typical work-up in a synthetic experiment makes building a notebook page easy. Moreover, the fact that it apportions your time accordingly in its calendar makes it a bit easier to plan experiments throughout a day. That work-up takes two hours, but another takes one? If seminar is in an hour and a half, drag the two pages around and your time is reapportioned accordingly. Granted, it doesn't account for multitasking, and certainly isn't the ultimate in organization technology, but it helps keep things from getting forgotten and keeps things in perspective, visually.
This is where Findings really shines. Features like Protocols address the typical bad habits of scientists not just by providing a crutch, but by adding functionality that rewards you for being on top of things. Whether you just use Protocols for creating experiment templates or go all-in and build your day with them, you'll probably be glad for the convenience at least. Outlast for mac.
Findings 2 0 2 – Lab Notebook App For Scientists Study
The other place where this mantra really works is in the desktop app's interaction with the mobile app. The mobile app is iPhone-only (though an iPad version is forthcoming, or so I'm told) and acts as an experiment editor more than an experiment creator. Using a slightly modified interface, it lets you add observations in nuggets, with each 'nugget' having the possibility of containing photos, notes or warnings. I found myself regularly photographing experiments and making observations in realtime; the iPhone's built-in voice-to-text feature makes operating the phone one-handed easy and effective (although your labmates may begin to worry about you talking to yourself). All of the information that's added gets synchronized to your Dropbox, and photos taken within the app go right to your Dropbox and don't clutter up your camera roll. Here's the first hitch with Findings, really: while the fact that it syncs with Dropbox is fantastic, the syncing is very buggy and often unreliable. That said, during the course of my trial, I was in regular contact with Charles and I can say confidently that the problems are much further and far between now than a month ago. For those who would prefer to use pen and paper in lab, the software exports beautiful printouts of experiments that can be used as dedicated scratch paper. I often use these to let my hood mate know what I'm working on and keep notes if my phone isn't handy.
So at this point, two of my major points are covered: the software integrates well into my experimentation routine and the data is backed up automatically. How does the software fare in terms of feature set?
This is probably the biggest place for improvement in Findings. The software makes building procedures fairly straightforward and easy, but chemists will be somewhat disappointed. Because the software is designed with biologists in mind, there is no support for Chemdraw or any other structures. This is inconvenient, but I often prepare graphics in Chemdraw and insert them, then attach all the Chemdraws as files. It isn't as elegant as some other chemistry-focused eLNs, but it isn't so cumbersome that I wouldn't recommend it. The biggest gap is the lack of support for tables, but the company has already announced that this is forthcoming; whether they will be able to auto-calculate reagents with molecular weights and such is to be determined. While the experimental editor is good, and probably great for non-chemists, it is definitely lacking for chemistry. Mekentosj claims to be very open to suggestions, so lets hope they include something like this soon.
So there you have it: Findings is a solid piece of software that does a fantastic job of not only working itself into your experimental life, but finding small ways to alleviate bad habits, too. The fact that it synchronizes experimentals, attachments (including instrument files, I might add; I attach FIDs for NMR all the time) and photos to Dropbox makes me feel a little more secure about the lifetime of my data. The major drawback is a lack of chemistry-centric features. I would love Chemdraw support, reagent tables, and support for compound numbering/identification, but those are definitely not here, though hopefully if the chemistry community takes the software to heart, these will be added. However, the biggest advantage I can cite for Findings, despite its limitations, is its price. At $39 ($23 for students), the price is right for an individual purchase, and group discounts are available. For everything it does, especially with the mobile app added in, Findings is great value and definitely has room to grow.
Special giveaway! If you're interested in trying Findings and want to give it a go at even lower of a price point, Charles has generously offered to give the first twenty people who subscribe to the Findings newsletter a coupon for a free download of Findings! If you're already subscribed, email Charles and mention this post and you'll get the coupon, too. I'll be sure to edit this post when they're all spoken for.
Edit: if you're getting a 405 error signing up for the newsletter, use this link instead: newsletter
All the free licenses are spoken for! Have fun lab-note booking !
TL;DR? If you use SQlite FTS4 for indexing large immutable documents, you might want to consider contentless tables. With minor adjustments, the database could be 2 to 3-time smaller.
Gus Mueller recently detailed how Acorn 5's Help menu implements live searching of all their online documentation. The actual help content is huge and hosted on Acorn's website. To provide local search from within the app, a small SQLite database is embedded in Acorn. The database uses the brilliant FTS4 extension extension module which allows to create virtual tables for super-fast full-text search. Combine this with NSUserInterfaceItemSearching, and you get a clever yet simple setup for a powerful Help menu that seamlessly connects Acorn and its extensive online documentation (did I mention Acorn 5 is awesome?).
Contentless FTS4 Tables
I just happen to have been knee-deep in FTS4 last month while working on full-text search for the Findings app (of course leveraging Gus' own FMBD). One section of the SQLite documentation in particular caught my attention: contentless FTS4 tables. As the name implies, such a table does not store a copy of the content. Yet, just like contentful FTS4 tables, you can perform efficient full-text search on that content. For instance, type this:
… and you get the list of docids for all the documents containing the word 'bar' somewhere in the body column.
Behind the scenes, SQLite creates various data structures for the index, and they are the same for contentful and contentless tables. In contrast, the ‘content' part of a contentless table is simply empty:
Contentful vs contentless.
This difference is particularly relevant when indexing large documents that exist outside a database, such as a collection of web pages or PDFs. Normal contentful FTS4 tables store the entire content of those documents in the database, which means this data is needlessly duplicated. This is not the case with contentless tables. They work more like the SearchKit framework on OS X, that focuses on building and querying an index, and does not keep a copy of the documents (the client is responsible for that).
It should thus be obvious why contentless FTS4 tables could be more advantageous: they are potentially smaller than a contentful table. In theory. Is that really the case? And how much smaller, really? Let's use the scientific method and run an experiment to answer those questions!
Contentless vs Contentful
As an example of content, I used the SQLite database that indexes the Acorn help content (it can be easily extracted from the Acorn app package). The database contains 187 entries, and occupies 1,028,096 bytes on disk (roughly 1 Mo). That is pretty small if you consider that the actual Acorn help site is really quite extensive and weighs in at 524 MB! The index of course only deals with the text, but that is still roughly 400,000 characters (quick observation: that's about half of the database size).
Using this dataset, I performed the following experiment:
- create a database using a 'contentful' FTS4 table; I expect the database to be pretty much the same as the original; this is what scientists would call a positive control; it is here to make sure that whatever comparison I make with database (2) is valid; if Gus used some special pragma or a different SQLite build and I used his database for comparison, I would end up comparing apples to oranges;
- create a database using a contentless FTS4 table (note: the database also has an 'info' non-FTS4 table, for reasons explained in the section 'Querying Contentless Tables');
- same as (1) but adding the data 10 times (1870 entries);
- same as (2) but adding the data 10 times (1870 entries).
Databases (3) and (4) are meant to extrapolate what happens with more entries. Since the exact same data is used 10 times, the ‘content' will be 10 times bigger while the ‘index' part will probably not grow as much 1.
The exact script I have used is available for download. It is a Ruby script that expects the original SQLite database ‘HelpIndex.db' in the same directory when you run it. It creates 4 databases (index1.db, index2.db, index3.db and index4.db). If you don't want to run the script yourself, feel free to download index1.db and index2.db and compare their contents, e.g. using the great Base app.
Now, the results.
An image is worth five numbers. https://jubrzz.over-blog.com/2020/12/zemax-torrent-cracker.html.
First, database (1) is the exact same size as the original. Good job. Positive controls are very boring when all goes right. But then, of course, it only highlights the really interesting part: a very significant size reduction for contentless tables. Using a contentless table brings the database to less than half of its contentful size. For a larger database, the relative savings appear to be even larger (down to almost one third), in line with our expectations.
The conclusion? For indexing a collection of large documents, contentless FTS4 tables are worth considering. For indexing help pages for instance, and depending on the number and size of the indexed documents, database size could be a significant fraction of an application package. In the case of Acorn, using a contentless table would lead to a 2% size reduction of the app. If Gus decided to switch to a downloadable index instead of packaging it with the app, it would save bandwidth and would provide faster updates to the user. As the help site grows in size, the potential savings would potentially be even larger. Small is beautiful.
Now, to be fair, contentless tables are not all rosy. There are still a couple of drawbacks that I will cover in the next sections. Fortunately, in the use case we are considering here, only the first one is relevant and it is easy to work around.
Querying Contentless Tables
With contentless FTS4 tables, the only values you can get back when running a full-text query are the docids for the matches. It is an error to attempt to retrieve the values of any other column. Here is comparing what happens with contentful and contentless tables with the same column setup:
When querying a contentless table, you can only get docids.
The docids are not useful on their own. In the case of Acorn, we need to display the title of the entry in the Help menu and we need the url to open the page in a browser if the user chooses that entry. Since the original content is not stored in the contentless table, the information is simply not available.
There are different ways to work around this limitation. A simple solution I am describing here is to store the url and title in a separate, normal, non-FTS4 table, populating it in parallel to the FTS4 table, so that the rowids match. Here are the statements for creating the contentful and contentless tables; then populating the tables (latter statements left as an exercise; this is the setup I used in the above experiment where I compared the database sizes, so you can also just check the script):
Let's add an ‘info' table to complement the contentless table.
When querying the full-text index of the contentless table, we still only get docids, but we can now use those to get at the information we need: the title and the url. This adds a bit of complexity to the query, and makes it slower. I settled on using 2 subsequent queries, but I am no SQL ninja, and a faster approach probably exists (please let me know!). Given the type of data we consider here, the query will still be very fast (we're not indexing the HHGTTG). Here is how it goes, again comparing contentful and contentless tables:
A simple 2-step query for a contentless table.
Findings 2 0 2 – Lab Notebook App For Scientists Work
Update Sept 14, 2015: Evan Schoenberg (from the Disqus comment thread at the end of this post) suggests the following single SELECT statement for the query:
SELECT info.url, info.title FROM info, data WHERE (data.body MATCH 'bar') AND (info.rowID = data.docid)
Deleting Content in Contentless Tables
Unlike in contentful tables, it is not possible to delete or update entries in a contentless table. Once you index data, it cannot be altered, and will remain part of any query you do now and in the future. The reason for this requirement is the way an FTS4 index is stored internally. It is optimized to get the rows from a list of tokens (searched words), but not the other way around. To prune a row without knowing which tokens were indexed, SQLite would have to pretty much scan the entire index searching for the rowid. With a contentful table, SQLite can check the content for that row, tokenize it again, quickly get to the relevant tokens in the index and alter things as needed.
It is possible to work around this by keeping track of obsolete docids and adding a new entry for each modification. Then, when you get results from a full-text search, you ignore the entries corresponding to obsolete data. I experimented for a while with such a setup, but Findings documents are heavily edited as the user works on them, and the search index needs to be updated on a regular basis. The table then keeps growing, which defeats the initial purpose of having a smaller database. In the end, a contentful table is not that big anyway, even with hundreds of documents in the Findings library. For better or for worse, Findings documents are mutable, so contentless tables are not a good fit. This is very different from what I covered here…
Going back to our use case: we don't care about deletion.For immutable documents, this limitation of contentless FTS4 tables is completely irrelevant.
Where does that leave us, then? My earlier experiment showed that the relative space savings for large documents can be significant. When indexing help pages for instance, it is thus an alternative really worth considering. Contentless SQLite FTS4 tables + large immutable documents = Yay!
Findings 2 0 2 – Lab Notebook App For Scientists Using
[Update Sept 8: Comment thread on HN]
Buy Lab Notebook
1. Using the exact same data 10 times seemed like the best I could do for the scope of this post. Of course, it is a very artificial dataset: in the real world, nobody will ever index the same documents 10 times (right?). Using real data, though, would have made it harder to compare (3)/(4) with (1)/(2) since we would have to use a different corpus of data, and that could introduce artifactual differences (one set of data could be inherently easier to index, independent of the size). Still, the problem with my approach here is that the index will be smaller than it would be with real data, because we are not introducing new tokens with the additional documents. But hey, counter-argument: anyway, with real data, new tokens become increasingly less frequent even as you index more documents because most words will have already appeared in previous documents. OK, ideally, I'd scour the web for all kind of representative datasets, and index all of these. Alas, I only had time to write this footnote as an excuse, so let's just move on.↩︎
