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.
This is exactly the kind of feedback I was hoping we'd get! I'm just going to go line by line, after which I'll start redo-ing the PDF to reflect some of the changes.
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?
This is kind of a big deal, in an estimating-cost-of-website sense.
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.
To be honest, I think videos would be extremely useful (though I'm not
a scientist), but a lot of work.
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?
No, not really, not until someone comes up with some hard data about the
spam-reduction rates of the various methods.
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.
For the UI:
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.
Somehow I missed the "groups have categories" concept. Sorry.
An extra bit of feedback, those auto-scrolling "feedback" vertical button things are incredibly annoying, especially on mobile devices and/or small screens. They obscure part of the page, can't be scrolled out of the way, can't be (easily) switched off, and are also a huge slowdown when scrolling, again particularly on mobile devices. It's also unclear what clicking it will do. Will it take me to another page so I lose the context I'm in, will it open a popover form, will it open a menu? Is said "feedback" targeted at the current protocol/page or at the site itself? I recommend getting rid of this, or at least moving it to the top menu. Sorry, minor nitpick, but I've been so frustrated by these unremovable auto-scrolling things obscuring information I actually need to see.
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.
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.
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.
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.
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!
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.
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.
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.
22 comments
[ 3.7 ms ] story [ 46.6 ms ] threadThe 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.
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.
To be honest, I think videos would be extremely useful (though I'm not a scientist), but a lot of work. No, not really, not until someone comes up with some hard data about the spam-reduction rates of the various methods. For the UI: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?
Somehow I missed the "groups have categories" concept. Sorry.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.
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.
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.
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!
- 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.
Is 'chops' the 'ninja' of 2011? It seems to be making a comeback.
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...