Our Open Science project is looking for a dev

by emeltzer • 15 years ago

42 22 15 years ago

emeltzer5• 15 years ago

Any critique of our ad or design spec are also very very welcome!

ajray2• 15 years ago

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!

emeltzer5• 15 years ago

Absolutely. Should have linked this off the bat, but here is our signup page: http://openprotocols.net/

stevelosh2• 15 years ago

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.

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.

emeltzer5• 15 years ago

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.

ylem• 15 years ago

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?

emeltzer5• 15 years ago

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.

zdw• 15 years ago

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.

possibilistic2• 15 years ago

Markdown sounds right. I don't see open protocols being published in print though. Especially not if they're collaboratively edited in any way.

Cixelyn• 15 years ago

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.

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.

duportet• 15 years ago

when do you plan to launch?

possibilistic2• 15 years ago

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!

djacobs2• 15 years ago

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.

emeltzer5• 15 years ago

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.

djacobs2• 15 years ago

Excellent, will send an e-mail tomorrow. I'm really excited about making an integral part of my day as up-to-date as the rest of my workflow.

jergason• 15 years ago

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.

georgieporgie• 15 years ago

> That said, if you have the chops

Is 'chops' the 'ninja' of 2011? It seems to be making a comeback.

kanzure• 15 years ago

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:

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...

Our Open Science project is looking for a dev

Related Stories