Our Open Science project is looking for a dev
openprotocols.net
openprotocols.net
Rather than decide how it looks and works, decide how you want the data structured then come up with a format to represent it. This sounds like unstructured to minimally structured document centric data - something like a Markdown with additional tagging or an XML format would probably be ideal.
This way, eventually when your design changes or someone wants to shift the data into another format (say mobile use, or transformed into LaTeX for publication), it's a matter of writing a fairly simple converter, rather than trying to scrape the site or do other PITA stuff.
This solves two problems a) the big problem of reproducibility in fields like biology, and b) if it's machine-readable, you can just toss the file onto a robot and have the whole procedure done for you.
Check out Biocoder for an example of a language for describing protocols: http://research.microsoft.com/en-us/um/india/projects/biocod...
Format conversion and outputting versions for publication also follow quite easily once a strict protocol language is defined.
- Create protocol versioning backed by something like Git - changes made to protocols are tracked according to the user, and it should be simple to refer to any version of the protocol (which will usually be versioned with words instead of numbers)
- Allow users to upload raw protocols and attempt to parse them for the key sections - maybe have an assisted parsing, where the user can edit the final interpretation
- Make elements as semantic as possible (for example, catalog numbers, repeatable steps, timepoints, notes/advisories)
- Have protocols that are "certified" as being proofread or accepted by multiple, reliable sources or contributors - especially protocols describing reagent recipes
- Make protocols as abstract as possible such that you can change variables (volumes, number of reads, timing) at the top of the protocol, and the rest of the protocol changes accordingly
- Allow a rough graphing option of active/inactive time during the protocol, so that the experimenter can generally gauge how to manage his time
- Allow automatic creation of flow charts if protocol is formatted correctly
I have loads of experience with the pain points of protocols in science, so I'd love to see a good, standard solution emerge in this space.
We'd absolutely love to talk more about this stuff with someone else who's as interested in the problem as we are! Please do get in touch--email in the ad.
http://research.microsoft.com/en-us/um/india/projects/biocod... or xml: http://diyhpl.us/~bryan/irc/pcr.xml
Still, I think this isn't a solved problem. The API for Biocoder feels all wrong for numerous reasons; on top of that, nobody is going to learn a new API, library or programming language just to write down a protocol, unless they are being paid, or there's some really compelling reason to do so (which, there isn't). Without something changing here, you just end up with a giant corpus of protocols like we presently have, without metadata and basically useless unless you already know what you want or need, or have the time to manually check and double check everything in each protocol you might be using.
One of the advantages of machine parsable protocols is being able to query against your lab inventory... http://diyhpl.us/cgit/skdb/plain/doc/BOMs/diybio-equipment.y...
I should also point out that Jonathan Cline was working on parsing plaintext protocols a while back:
Don’t Train the Biology Robot: Have the Machine Read the Protocol and Automate Itself http://88proof.com/synthetic_biology/blog/archives/290
So it's just unclear how you plan to fix or assist in some of these dynamics, at this point, or which specific problems you're solving.
I also posted this to the diybio people: http://groups.google.com/group/diybio/browse_thread/thread/1...
That said, you could easily distinguish yourselves. A website that could recalculate concentrations, etc. based on your setup would be neat. To make it even more accessible to newcomers, you should try to one day host a collection of "open" review articles.
If I weren't so bogged down I'd love to work on something like this. Good luck!
As for the type of protocol, since the site is oriented around user-moderated groups, we're absolutely down with any kinds of protocol our users are interested in.
The emphasis on documentation is great. We need more of this.
You say that the "hint text" in the various form fields should disappear when the field has focus. I actually find it much easier to use when the text gets lighter but doesn't disappear until the user has started to type. I usually navigate forms by tabbing through the fields, and I hit tab as soon as I'm done with one field, which means that by the time my eyes get down to the next field the hit text would be gone. The jQuery In-Field Labels plugin is a great way to make it a little bit more usable: http://fuelyourcoding.com/scripts/infield/
I'm assuming that users create groups. When two users inevitably create similar groups, is there any way to merge them?
Do you really need a separate "add link" button for each reagent? Why not just show the link field and clearly mark it as optional, so someone doesn't have to click many times if they have a bunch of reagents with links?
You mentioned videos for steps. Are you thinking people will upload them? If so, that's tricky. What formats do you accept, do you have the space/bandwidth to host them, etc? Or are you thinking that people will upload them to YouTube/Vimeo/etc and paste the link? If so, are they embedded or do users need to go to the video page to view it?
The requirements for the step editor seem awfully specific. I'd suggest taking a look at the available editors around like CKEditor or WMD and choosing one of them as a baseline.
http://ckeditor.com/ http://wmd-editor.com/
The page describing the fonts, buttons, etc seems extremely specific. If the PDF is a collection of wireframes and not a design (maybe I misunderstood it) then there are probably things more important to nail down than the border-radius (border-radii?) of input fields.
For the log in lightbox, have you considered using email verification (user signs up, gets emailed an activation link, clicks link, logs in) instead of a captcha?
Do you really need the "Ban User" functionality for group admins? Does banning a user make them not able to see that group at all? What if they log out, or create a new account? It seems like the troll rate on a site like this would be extremely low, so is this necessary or just adding extra complexity?
What is that "Language" link in the header? Will the site support multiple languages? Can users translate protocols? If so, which user "owns" the translated protocol? This could potentially add quite a bit of work, so it should probably be nailed down.
Is the "Blog" in the header just a link to a Tumblr/WordPress/whatever blog or is it part of the site?
Something that seems to be missing is a rough overview of the data. A page describing the data would be very helpful, even something as simple as "protocols are divided into groups, groups are created by users, and users can add new group admins" would go a long way.
I'm a bit confused about the "DIYBio Protocols" page. Is this a group? It seems like it has a bunch of groups inside it. Maybe I'm misunderstanding what a group is. A rough data model would help with this a lot.
1. Hint text. Good point. That implementation definitely sounds more useable, and of course, there's a jQuery plugin for it :)
2. There's no explicit way to merge groups, because it sounded like more of a hassle than it was worth. What do you think of avoiding the problem in the first place by suggesting existing groups as the user types in a group name to be created?
3. Separate add link button: good point. changing this.
4. Video: lets forget it. I've never done anything involving video uploading, and once I had a look at what a hassle it is to do, I don't think it's worth it for the amount of our users that will actually use it.
5. Step editor. Yes, also a good point. CKeditor seems perfect.
6. the importance of border-radii: cannot be underestimated. the PDF is supposed to be a bit more than wireframes, but is not intended to be that high-level of a design.
7. Captcha vs. email verification. I did think about this one a bit. I personally hate email verification more than I hate captchas, but is there some other reason to prefer one over the other?
8. ban user is about as useful as video uploads, and is probably not worth the hassle it entails. lets cut this.
9. early on, many of the people who've expressed interest in the site wanted to use it in non-english speaking settings. since there is no "settings" page yet (not enough settings to make it worth having one) the languages selector goes on the top menu rather than inside a settings section. Changing it at the very least changes the language of the UI (assuming this isn't too difficult) but could also change which protocols are shown (this sounds much harder.) Not an essential launch feature, on reflection.
10. The blog is just a link to a posterous/tumblr/whatever, for now.
11. The last page has a crude data structure diagram, but i'll add the users into it.
12. DIY bio page: That is a group page. The different headings on the page are categories within a group. I'll put this into the data model as an example.
2. There's no explicit way to merge groups, because it sounded like more of a hassle than it was worth. What do you think of avoiding the problem in the first place by suggesting existing groups as the user types in a group name to be created?
How are suggestions displayed? Inline, as-you-type, AJA* updating, or only once you hit create?
Also, how do you determine if two groups are similar? Just based on the words in the titles, or in the descriptions as well? What about synonyms?
It's a hard problem, and a perfectly reasonable answer for an initial launch is: no merging, and no suggesting. If two similar groups are created: tough. Deal.
4. Video: lets forget it. I've never done anything involving video uploading, and once I had a look at what a hassle it is to do, I don't think it's worth it for the amount of our users that will actually use it.
7. Captcha vs. email verification. I did think about this one a bit. I personally hate email verification more than I hate captchas, but is there some other reason to prefer one over the other?
9. early on, many of the people who've expressed interest in the site wanted to use it in non-english speaking settings. since there is no "settings" page yet (not enough settings to make it worth having one) the languages selector goes on the top menu rather than inside a settings section. Changing it at the very least changes the language of the UI (assuming this isn't too difficult) but could also change which protocols are shown (this sounds much harder.) Not an essential launch feature, on reflection.
Who translates the UI? How do they do it? Who checks their work?
For the protocols:
Yes, this would be hard to get right. Very hard. What about translating groups? Who owns those? How does a translator know when a group's "original" description has changed and need re-translating? What if someone edits a translated group -- who reverse-translates the edit back to the original group? What if the original has changed since then?
12. DIY bio page: That is a group page. The different headings on the page are categories within a group. I'll put this into the data model as an example.
Oh, and as for the linking, you might want to check out how Ravelry does it (Ravelry is a site for knitters to organize their projects at). They have a text field where you can type in the name of a yarn/designer/pattern, and a link button. Clicking the link button pops up a little box where it searches for anything with a similar name in the respective database, and you can click on a search result to auto-populate and link the field to the result.
http://www.pandastream.com/ http://addons.heroku.com/pandastream
For the editor, a WYSIWYG editor may better target your users, but I recommend keeping the formatting options to the bare-minimum you have already defined.
Providing enough options to typeset a book is cool, but would probably distract both editors and viewers.
Is 'chops' the 'ninja' of 2011? It seems to be making a comeback.