Design the data format (API) first, then the user interface later. You have the cart in front of the horse.
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.
I think it would be even better if the protocols were stored in some sort of machine parse-able format rather than just human readable text.
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.
I work in a lab and also code. I was just thinking about implementing a prototype site with this functionality this week. I have coded for a while but have no coding resume, so I don't know if I qualify for your position. But here are a couple of ideas I had, if you'd like them:
- 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.
Many of these ideas are things we are either planning to implement or have discussed in the past--great minds think alike :)
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.
Git-revisioned protocols and sharing is nice, and is one step up from the current situation in sharing and developing lab protocols. DIYbio as a group has been eyeballing more programmatic ways of specifying protocols, either through structured document formats (like XML) or parsed languages like in Microsoft's Biocoder project:
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 problem you might face is that there are already more than a few wikis for this. For the last few experiments I've run, I used sites like these.
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!
This looks really neat. I am doing web development for a lab that is pretty obsessed with open source, open protocols, ect, so I will for sure keep an eye out on this. Wish I wasn't so swamped with work, because this looks like it would be lots of fun.
Do you want to run this as an open source project? Also, are you going for standard lab protocols (of say the pharma variety), or reproducible statistical analysis as well?
It'll be open source (like most projects in the open science space are, see PLOS's open journal effort for a good example) because there is no reason for it not to be :)
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.
I am a research scientist but not a web developer. Is there anyway/anywhere I can sign my email up to be notified when an Alpha/Beta is available? I'd love to contribute if possible!
Here are a few quick, random things I noticed after looking through the PDF.
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.
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.
[+] [-] zdw|15 years ago|reply
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.
[+] [-] Cixelyn|15 years ago|reply
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.
[+] [-] possibilistic|15 years ago|reply
[+] [-] djacobs|15 years ago|reply
- 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.
[+] [-] emeltzer|15 years ago|reply
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.
[+] [-] kanzure|15 years ago|reply
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...
[+] [-] possibilistic|15 years ago|reply
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!
[+] [-] jergason|15 years ago|reply
[+] [-] ylem|15 years ago|reply
[+] [-] emeltzer|15 years ago|reply
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.
[+] [-] emeltzer|15 years ago|reply
[+] [-] ajray|15 years ago|reply
[+] [-] stevelosh|15 years ago|reply
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.
[+] [-] duportet|15 years ago|reply
[+] [-] georgieporgie|15 years ago|reply
Is 'chops' the 'ninja' of 2011? It seems to be making a comeback.