My Notes

As far as Julius' thoughts about using external software for editing and then plugging it into wiki:

My initial thoughts were that while this would be great for certain users, it still requires diligence and savvy that most users won't have. So, I think the focus should be on improving the wiki user interface and other wiki features.

But that doesn't preclude features as Julius mentions. Along the same lines, there are certain things, such as raw data collection, where it would be useful to be able to stream right into OWW. E.g., wouldn't it be nice if the gel imager (or any other instrument) could save directly to the OWW database?

Per Anne Ozaksut (see below): spreadsheet functionality would be a killer feature to add.

A "data entry mode" edit feature, to make it easier to enter data w/o having to remember to save periodically. For example, maybe autosaving every so often? Not sure..

I guess basically like a chat window?

Java sketch pad (and some mechanism for converting to text)?

Need to be able to email to the wiki (as w/ Social Text)...this provides a pipeline for adding notes to your lab notebook if you have to rush out of the lab, forget to write something down, or just plain have an idea. Of course, you can email to yourself and then cut and paste, but that takes diligence.

Copyright and licensing problems--it is fine to paste any kind of picture or anything in a printed lab notebook as "fair use" (I think). But it's not OK to upload to OWW, because technically you are putting a "copyleft" license on it. (And it may not be fair use, since it's so widely available?) This is a problem.

Better file uploading--drag and drop w/ version control

Integration w/ WikiCommons or Wikipedia: (i.e., like for Wikipedia when you can embed images from the Commons)

Agenda for brainstorming session:

Brainstorming about features

Thoughts on how to prioritize implementation

?

From observing my Junior Physics Lab Students

They are drawn to Excel because I haven't provided them a better option and the wiki doesn't do any spreadsheet, graphing, or data analysis.

They like the table editor

Many of them prefer to take data down on paper and then transfer it over. So far I'm not requiring e-notebook for primary entries, because sometimes it is necessary (computer not available, or need to have lights off and eyes adjusted).

As far as giving feedback early and often, e-notebooks are far superior to printed notebooks, simply because I can access them anytime.

I haven't detected any qualms at all about doing their work in public. So, it appears easy to create Scientists 2.0. :)

Collaboration (and proper citation) between students, even on different lab days has been a real pleasure to observe...I think the wiki has added a completely new and very rewarding dimension to the traditional undergrad physics lab course.

From observing students in my own lab

A great idea from Anne Ozaksut, a student in Phyiscs 307L: Incorporate more spreadsheet and even graphing technology into the wiki. I have seen this with wikicalc, which I think was in collaboration with SocialText? The more I think about it, the more important it seems.

The short-lived cookies (session doesn't last very long, even if you change this under "my preferences") is a real annoying thing

The new table editor is great, but has a couple drawbacks

Has a bug so that data is lost when saving

Apparently creates non-wiki style table code that is tough to edit without the editor? (I'm not sure about this)

Bill Flanagan: Comments on moving forward with Lab Notebook features

I'd like to thank Steve Koch for both the way he helped pull together last month's Lab Workbook Brainstorming Session and his continued assistance in working all of you to come up with what's turning into an exciting project.

We're now starting to implement features coming out of the Working Group. We hope to have a follow-up session after we finish with next weeks OWW Board and Steering Committee meetings. Steve has already indicated that he'll be moderating the next session as well.

Two particular features are starting to move forward that I want to briefly mention. I welcome your comments on them as well. One is going to be introduced into OpenWetWare over the next few days. The feature is an extension of a feature in MediaWiki called "Magic Links". Any time you type the term 'PMID' and put a number next to it, MediaWiki creates a usable link to PubMed when you save the document. With no special linking characters, these references allow a reader of the page to go to PubMed via NCBI and view the associated document. This also works with Internet RFC document and, to a lesser degree, with ISBN book numbers. Thompson and Francois St. Pierre, PhD candidates in the lab my wife now calls my home, told me about this feature. I had been working on MediaWiki for quite a while and never ran across it before.

We've now extended the original magic link concept to include GenBank accession numbers, BioBrick parts, and references to Cornell's ArXiv (Archive X). Julius Luck's Atom-based network interface to that system is how we implemented it.

In the case of GenBank accession numbers, we came up with an interesting way to allow the data to be viewed. We're generalizing it to the other network document repositories as time permits. I'll keep you all up to date as we move forward.

When you hover your mouse over an accession number that has been linked, a small dialog box pops up. It initially will contain the title of the GenBank record for the part. These links will only be present if a valid part number is entered. In the dialog box, a download tag is present. If you click it, OpenWetWare will download the sequence from NCBI and stream it down to your desktop. If you have an application that knows about the '.gb' tag, the sequence and associated header information will be directly loaded into your application. Vector NTI and CLC Free Workbench 4 are a few apps we've tested with. Once the sequence is downloaded the first time, it stays in our OWW cache and will zoom down to you or anyone else requesting it for anytime forward. Tom Knight asked for an extension to this that I'm just finishing up. If you enter a term such as, "GENBAN U49845:12-1024", only base pairs 12-1024 will be downloaded.

The other feature, originally suggested by Tm Knight, was a way to print labels from OWW. This has turned into a very fun feature. I've created a new tag, "<label>". The Label tag will permit you to enter a label into your lab notebook (or any OWW document). When you save the page, an image of the label will be visible. If you click on the associated 'print' icon, the label will pop up in a separate window along with a print dialog box. If you have a label printer available to you, you can print the label to it. I'm creating a new section called "OpenHardWare" to allow people to share their experiences about which printers work best. I'm putting my money ($29.95! on ebay!) on a Brother USB label printer as our test platform.

The label will feature a barcode. Steve made a great suggestion to tie the use of the labels back to OpenWetWare. The barcode will be a unique pointer, across all of OpenWetWare, that will associate the label with the page it is printed from. We want to create templates for a few different kinds of labels used in the lab. We will have a way for anyone to create and contribute templates for specific sizes and layouts. Any petri dish in a lab using OpenWetWare for creating these labels will find, if available, the exact context of where the page originally came from. Those stacks of plates you just found in the corner? Scan first, blame for taking up too much bench space later.

I'm experimenting with a $10 barcode scanner, the CueCat, as a "necessary and sufficient" scanner for this activity. We also have access to more sensitive and expensive bar code readers but out goal is to work with the absolutely most affordable barcode scanner we can find.

If anyone has suggestions as to what else we can do with this information, let me know. We'll be rolling out a very "beta" version over the next few weeks. More features will follow as soon as we make them work.

We have several more tricks up our sleeves that I'm flushing out. More will follow.

When MediaWiki ceases to be useful for doing what we need to do, we are extending it. The built-in archiving is a feature we desperately want to keep in the middle of everything we do. But how we create the documents and what happens when we read them may vary from the standard product. Lab scientists have different requirements that Wikipedia readers. We want to make sure those needs are accommodated without breaking OWW's essential 'Wikiness'.