Standardized DIYbio report format? WAS: Endophyte isolation and first successful sequencing

[Jeswin]

On Wed, Aug 7, 2013 at 10:48 AM, Dakota Hamill <dko...@gmail.com> wrote:
>
> Ben: I understand what you're saying, there are times I read amazing
> articles or posts by people on how to build this or that and when I get to
> the end, I say to myself, where is all the information and materials list!
> I've been quite busy during the week and have been writing these quick posts
> at night. There is a section on the website that we had the intention (and
> still do) of filling with more detailed protocols. Since not everyone is
> entirely interested (like casual interested readers perhaps) in the exact
> buffer recipes, perhaps what I'll do is write a detailed reference section

Can we get some sort of standard way to report the findings in the
DIYbio community? By standard, I mean, a specific file format (txt,
pdf, etc) with a specific template. The template should make it easy
to list materials, methods, results, conclusion, references. It should
be like a regular journal article except easily read by anyone and
easy to create [the report] by anyone.

And a place that accepts them as a repository would be nice, to keep
track of all the findings by people all over the world. Something like
github but I'm not sure what the general sentiment on github is. I
know Cathal uses it for his protocols.

[Ben Gadoua]

I mean, theoretically, you should be able to put it in a wiki, and keep your own materials stuff, if different than those used by the community in general, in your userspace. This would make it really easy to keep track of things, and show where you're using the same thing as someone else or as the rest of the community, also would allow people to show how their work builds on someone else's work.

[Nathan McCorkle]

Maybe a template wiki page would suffice? You copy the template to
your own wiki page, then swap the template sections for your words.
Wikis are version controlled so edits are tracked, and there are
already collaboration tools built-in to each page (see wikipedia's
'talk' page that goes along with each article).

You can convert any text into a PDF format using some code, there'd
probably need to be a stylistic format chosen for this template.

Maybe it'd be best to pick a stylistic format from one of the current
science publishers (they're all OK, though I don't really care for 2
columns of text), then work out the wiki template and the PDF
generation stuff.

[Sebastian Cocioba]

If someone with a knack for aesthetics can make a template and we can
vote on it? Try to get the ball rolling?

Sent from my Windows Phone From: Nathan McCorkle
Sent: 8/13/2013 1:44 PM
To: diybio
Subject: Re: [DIYbio] Re: Standardized DIYbio report format? WAS:
Endophyte isolation and first successful sequencing

--
-- You received this message because you are subscribed to the Google
Groups DIYbio group. To post to this group, send email to
diy...@googlegroups.com. To unsubscribe from this group, send email to
diybio+un...@googlegroups.com. For more options, visit this
group at https://groups.google.com/d/forum/diybio?hl=en
Learn more at www.diybio.org
---
You received this message because you are subscribed to the Google
Groups "DIYbio" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to diybio+un...@googlegroups.com.
To post to this group, send email to diy...@googlegroups.com.
Visit this group at http://groups.google.com/group/diybio.
To view this discussion on the web visit
https://groups.google.com/d/msgid/diybio/CA%2B82U9JHRRgiFBzNyTd47TNy05gkzJFQWxs_t9kk0jCJ9VSKDA%40mail.gmail.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Nathan McCorkle]

Lots of journals already offer LaTex templates... so what's the best
interface to magically transform plaintext blocks? A web form with
blank text boxes and a submit button works, but it doesn't let people
come back and edit it. Bryan says mediawiki (wikipedia) is hard to
parse by a computer, but being a wiki which /does/ some formatting,
the wiki engine /must/ be parsing it. I don't think mediawiki
formatting is necessary though if we had a button to shove it all into
a PDF... the wiki would just serve as a way to enter and edit the
text. Leave the wiki unformatted save for some keywords to delineate
different blocks that are needed for the LaTex template.

> To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/-5610509502223320986%40unknownmsgid.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
-Nathan

[Cathal Garvey]

The wiki parses Wikitext, yes, but the actual rendered wiki is standard
HTML and isn't designed explicitly for ease of parsing.

I'm also against relying on Wiki infrastructure because wikis are
"cloud only", in that rendering a wiki page to a local file is often
difficult, because of relative pathnames and image embeds, database
backed infrastructure, etc. - Yes, you *can* export to PDF, but PDF is
effectively a read-only data structure.

## Requirements for Ease and Academic Rigour
I think the ideal is a format that:
* Is easy for people to _read_.
* Is easy for people to _write_, requiring minimal reference and a
shallow learning curve.
* Is already in widespread use if possible, so people have little to
learn and plenty of support when they do.
* Allows image embedding.
* Allows dynamic styling, so it can be rendered into a pretty
"Proceedings of DIYbio" frame.
* Allows easy linking, referencing and footnoting; critical for
Scientific literature.
* Can be rendered into a matching document in most important formats
for academic publishing standard: HTML (->Blog/Journal), LaTeX (->PDF)
* Has extensive software support already; don't shave yaks!

## Markdown Extra
I would like to suggest that Markdown, particularly a flavour of
Markdown Extra, would be ideal. If you're not familiar with the
Markdown syntax, it might hearten you to know that _this email is
written in markdown_. It was specifically designed to mimic how people
place emphasis, build lists, write titles and otherwise structure text
to be readable in the absence of pretty rendering.. except that it
allows you to then render that into a variety of formats.

Markdown normally renders into HTML, but there are LaTeX renderers and
Wikimedia-flavour wikitext renderers, and pandoc allows you to render
into anything from RTF to .doc, if you like. There are a bunch of
scripts and applications that specialise in posting markdown documents
to Wordpress blogs (which account for a two-figure percentage of all
known websites at present, so that's not to be sniffed at).

[Markdown Extra](http://michelf.ca/projects/php-markdown/extra/)
features referencing (in the form of footnotes), abbreviations, and
tables, all using fairly common-sense syntax. Markdown Extra is
supported in PHP and in Python's Markdown package (if the "extra" plugin
is loaded).

## Infrastructure
To store and manage publications, given the flexibility, you could have
a wiki or blog to publish rendered documents, and a more formal
repository that stores the Markdown source files and associated images.
That would cater to both ends of the technical spectrum; those that
just want a clear way to present data, and those that want crunchy
machine-parsable everything for meta stuff.

For DIYbio purposes, it would be pretty straightforward to knock
together a micro-publishing system where people submit their papers,
they are put up on a github[^1] repo where people can offer
issues and feedback (you don't need to know git to use the issues
feature, so it's non-techie safe) on the content of the document. When
it passes muster/review, it can be script-rendered and published to
wordpress and/or a wiki automatically.

Given that many people will already have dabbled with Markdown, and
those that haven't can already read it legibly (this email as
case-in-point), and the ease with which it could be rolled out and
diversified, I'd be strongly in favour of choosing it over something
over-lightweight and over-centralised like just-wiki, or overly
technical and offputting like LaTeX-and-git-only

[^1]: I say github and not gitorious because github has better support
for Markdown, sadly, and their issues interface is friendlier.

## Citizen Science Quarterly
With regard to the other publishing-relevant thread from Jacob, the CSQ
might be rebooting soon (!), and it would probably make Jacob's job a
lot easier if submissions could be trivially rendered into high-quality
HTML and LaTeX, for the online and print(?) editions respectively.

Thoughts?

[Cathal Garvey]

To further illustrate my case for markdown, here's a template document
showing how a scientific paper could be formatted in Markdown for
rendering.

I make light use of the html-attributes extension that allows headers,
paragraphs or other items to be given class and id attributes in
rendered HTML: I don't know if this is supported in LaTeX processors
but if it is it's ideal for marking, say, the abstract for smaller font
and a centered full-page flow, whereas the rest of the document would
be styled perhaps according to the two-column layout favoured by many
journals.

Python Markdown also supports an extension where Metadata can be
defined at the very top of the document, but I don't think this is a
common extension with other markdown processors, so a merely
standardised and nicely script-readable format to the general document
and references would probably be best.

If we're coming up with our own standard for publishing and want to "do
it better", there's a lot that can be improved upon the older
publishing standards. Many of these were written to be unambiguous when
printed on dead-trees; I support this of course, but hyperlinks look
cleaner on a webpage or document. We could specify a more
machine-parsable (without sacrificing human readability) reference
format, perhaps using indented YAML or something, and have that render
into a nicely formatted dead-tree reference in LaTeX and a hyperlink
with machine-parseable attributes in HTML.

Perhaps it'd look like this; easy to read and write, machine parseable,
and presenting all needed information to render a classic or modern
reference format:
1. Author Garvey, C; Bishop, B | Title "Paper Title" | Publication
"Journal Name" | Issue "Unambiguous Textual Description of
Volume/Issue/Page as needed to traverse dead trees" | Link
https://link.to/article | Date YYYY/MM/DD

NB:
* The general format is as a bar-delimited list of S-Expressions; that
is, the first word of each bar-delimited section is the metadata
type. Some type are standardised, such as "author", but any
metadata may be added and will be ignored if no way to
render/serialise it is known. This bar-delimited S-expression system
is human readable, unambiguous (bars are barely used ever outside
computers), and very machine parseable.
* Using hyperlinks means a standard format for fetching the document
for machines and browsers is covered, so the "Issue" element is for
people manually seeking the data, perhaps after the link has lapsed
or the publishing house has collapsed and they're on the phone to a
librarian or navigating a new website. It has no standard structure
because journals and publishers don't, either; some have volumes and
no issues, some have issues and no volumes, some are entirely online
and have neither.
* The Date should be YYYY/MM/DD in order for it to be standard,
unambiguous, and trivially orderable between many journal articles.

To demonstrate how easy to parse this is, here's 7 lines (excluding
"#" comments) of trivial Python to do just that:
def parse_ref(ref_line):
output = {}
# Cut off the list index by splitting at the period mark and
# stripping whitespace from either end.
ref_line = ref_line.split(".",1)[0].strip()
# Split metadata sections into blocks.
for meta_section in ref_line.split("|"):
# Strip whitespace again and then split by the first tab/space/CR
meta_type, meta_data = meta_section.strip().split(None, 1)
output[meta_type] = meta_data
return output

Thoughts, again? :)
-Cathal

[Nathan McCorkle]

That seems like a good list of 'wants' for what a software for this might be.

I disagree about your wiki coment... It's stored as markdown but rendered as html, why would you try to parse rendered HTML? It's not cloud only, you can definitely run a local wiki, or download the markdown and render it in some custom LaTex prettifier or something else.

[Cathal Garvey]

My "criticisms" of wiki were directed at "wiki-only", not "wiki as
well".

In other words, if your files are written in a standard,
machine-parseable format that's accessible somewhere, then rendering
and displaying on a wiki is nice for human navigation between papers
and references (although with proper linking within pages it shouldn't
matter whether they're all hosted on the same site/wiki.), and provides
a visual set of modifications to the file over time.

However, the "wiki" is little better than a Wordpress install for this
purpose; the usual purpose of a wiki is to be human-editable, but if
it's merely a rendering of a source file stored elsewhere, then changes
made to the wiki will not be passed back to the file.

But, having "wiki-only", while having the advantage that it's
human-editable (preferably by author/editor only!) and the presentation
*is* the file, has the disadvantage that it's poorly machine parseable,
making conversion into other formats and analysis less friendly to
meta-study and development. The machine-parseable "wikisource" is
usually stored as a database entry somewhere rather than as a
readily-accessible file to a passing bot.

Also, wikitext, while originally as simple as Markdown, has sort of
devolved a bit, and has some non-obvious syntax which means lots of
checking syntax guides during authorship: does the bar character come
before the link or after the link? How do you do alt-text again?
References ditch the normal syntax entirely and look like a horrid mix
of wikitext and html.

So, I'm not a big fan, but it's still far
friendlier, machine-parseable and standardised than most other
alternatives. Even LaTeX is terrible these days; it appears the primary
goal of LaTeX developers over time has been to guarantee backwards
compatibility rather than to develop a great markup format. Doing
anything useful requires ten or more plugins which don't come as
standard with LaTeX. The "development environment" for new authors is
forbidding. While Markdown is poorly standardised too, it comes with
more batteries and compiles optionally to basic LaTeX if you really
want to do hardcore layout work.

I'm contemplating devoting an evening into making a "scientific article
compiler" in Python for Markdown; any suggestions on what you'd like to
see most in an application like this? Or how you'd like to see it
implemented? I'm assuming that the default presentation format these
days is HTML but will look into creating a layout that can be printed
to a niceish PDF, too.

On Thu, 15 Aug 2013 12:33:44 -0700

[Cathal Garvey]

Hi all,
Inspired by the notion, I've partially written a python script that
implements the idea of a "Markup language for Academic Authorship".

It's not ready, it won't dump a paper for you yet, but it has most of
the basics ready:
https://gitorious.org/plod/plod

Included is an unfinished "paper" for demonstration purposes. If you
compile, you'll get a simple layout that demonstrates citation
formatting, but you'll only notice the abstract extension at work if
you look at the html and note the class and id attributes.

The gist:
0. It's not ready, so seriously; don't bother if you're not interested
in hacking on the code and making it ready.
1. It's Extended Markdown, using the Markdown package from PyPI
(required): https://pypi.python.org/pypi/Markdown/2.3.1
2. It has (currently) two custom extensions:
- one is a "fencing" scheme for defining the abstract as a
separate, named HTML block so it can be styled and laid out
differently: The abstract is surrounded in "@@@" (@=a=Abstract)
to achieve this.
- the other is a citation format like what I wrote up earlier in
this thread. If this format is desired (you can always do it
manually), it is written as "{{ <fieldname> <contents...> |
<field2> <contents...> }}". To actually place citations just use
the "footnotes" extension as included in Extended Markdown;
follow the cited statement with "[^tag]", then define later with
"[^tag]: {{ <citation block> }}". The tag can be anything
memorable; it will be replaced with a number in order of
occurrence. The citation block will be placed either at the end
of the document, or wherever "///References List///" is found.
3. The "metadata" extension allows definitions of metadata at the very
beginning of the document, which is not rendered into the final
document but alters its rendering. At present, only "title" is used; it
becomes the HTML page title, and until a better way to automatically
detect the paper title is cooked up, this is the only way.
4. The "attributes" extension is enabled, and is used to set the
class/id of some elements that vary between papers, like the title;
you'll see in the example "test1.md" document that the title is
followed by {: #paper-title }, an ugly format used by the extension to
add "paper-title" as the HTML ID of the paper title. A postprocessor
extension might resolve the page-title issue more cleanly but would
require some sort of standard title formatting anyway to distinguish it.

Other than the above, it's standard extended markdown; you format the
same way and you process the same way. It compiles to HTML and can be
embedded in a template (read the script to see how the template works,
if given). Indeed, that's the whole point; right now, it just compiles
to a flat HTML file, but with the right HTML/CSS template, it could
compile to a properly formatted "paper" as you might read on PLoS or
Pubmed.

A lot of nice things remain that could be implemented better. I would
like to see these features:
1. Framed images, for figures with explanatory subtext.
2. Insertion of other markdown documents, allowing a source file to be
separated, perhaps so important tables can be handled independently and
compiled into the main source as needed. Would also be handy for larger
works, to be broken into chapters.
3. "Cited by", though this would probably require a central database of
citations to check with, which is pretty out of theme with
peer-produced academic literature.

[Avery louie]

It seems like there may be a slight case of putting the horse before the cart here.  Do people actually want to share what they are doing?  If so, why are they not already doing it using the mailing list, twitter etc. how easy will it be to use?  I am not saying this is bad, I am just pointing out some things to think about.

--A

[Cathal Garvey]

I don't really expect this to see much, if any, use. For me, it's an
exercise in actualised musings about the future of academia. I
presently record all of the work I'm happy to share on blogposts and
twitter, yes. And occasionally here, if I think it merits shouting
about.

But, say I wanted to share positive results on an experiment that
generated new knowledge in a meaningful, if small, way. There's a
reason we write science the way we do; impersonal, explicit,
formalised. It's a whitepaper of knowledge, and a deliberate effort on
the part of the experimenter to remove her/himself from the process and
open it up to criticism.

For this, I don't think blogposts in the casual form we're used to are
sufficient, but neither do I think we need an intermediary to measure
"scientific merit"; our peers will do just fine, thank you; that's how
science began, after all.

So, because I like to write in markup and hack on code, a markup format
to assist in writing explicit, formatted, impassionate scientific
literature seemed a worthy evening's work. Others may feel similarly,
or may decide to press on using LibreOffice or Wordpress' rich-text
editor. The standard layout, impersonal voice, and quality of the
research are what matter, not the method used to achieve it.

And no; there's not much of any of that yet in DIYbio. Indeed, I doubt
many will publish their research as "DIYbio". Rather, I think we'll
continue to trailblaze opening up science to the "masses", and
meanwhile showing up a lot of assumptions about how science itself
should be done, and those who want to generate knowledge will carry on
calling it "science", not "diybio" or "biohacking". Me? I'm in it for
something else, right now. But I'll always be a scientist in spirit,
and the future of the field is wide open.

[Dakota Hamill]

And occasionally here, if I think it merits shouting
about.

I hope people share whatever they are working on, in whatever stage of development it is, whether they think it warrants a shout out or not.   For too long I was worried about something being "good enough" to share.  I think it's great to show off whatever you do, even if it's rudimentary, because to some people, that's inspiring enough.  Not every experiment one does has to shatter boundaries, and not every write-up has to be ready for submission to a journal for peer review. 

I find motivation to be a roller coaster ride, at times extremely high, and at other times, extremely low.  I look to posts on here, big or small, grandiose or simple, for motivation to get back in the lab.  

I think it would be very beneficial to setup links to everyone else's blogs or websites/projects they are working on, such that if someone stumbles across one blog, they could be linked to anothers in the community.  Since News.DIYBio is down, maybe we should start another thread where we can all post links to our websites?  

[Brian Degger]

Keep on with the good work Cathal!

Some other resources, basically plugins for turning wordpress into a scientific paper

https://sites.google.com/site/wpscientists/home/plugins 

also its now easy to generate citable references using figshare, upload a figure/paper/graph/data and get a doi! 

As an example 

http://figshare.com/articles/Netroceros_bellicornis_Konow_lectotype_SDEI/779797

Netroceros bellicornis Konow lectotype SDEI. Andreas Taeger. figshare.
http://dx.doi.org/10.6084/m9.figshare.779797

Retrieved 12:26, Aug 23, 2013 (GMT)

To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/CAGdeWmRUJAxGx0u%2BFfja0Zs3cP3eteDORwEemEH46JpRSK%3DowA%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
----------------------------------------
Brian Degger

twitter: @drbrian

http://makerspace.org.uk

http://transitlab.org

----------------------------------------

[David Taffany]

What is the general feeling towards Figshare and other sites like ResearchGate and Academia.edu? Does their focus on academic scientists alienate the DIYBio community? I'm on a team trying to make a data sharing site for DIYBiologists and other citizen scientists, so any input people have would be much appreciated. Thanks!

[Brian Degger]

I like figshare and Mendelay
Figshare for the ability to give doi to anything...good for slide decks about diybio, or even individual micrographs.
Mendelay for setting up reading groups on certain topics. I have a soft spot for Daphnia and research re it.

To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/d08de476-1fa7-4dab-be1c-f69860eefd1a%40googlegroups.com.

[Pieter]

@David, what tool are you working on? Open source is a big requirement for me. That's why I currently prefer Zotero over Mendeley and other proprietary platforms. Let's avoid another privatized social network trap on the way to open science.

[David Taffany]

Hi Pieter, I'm working on a site called Nucleus (www.wearenucleus.com). It just launched and it's pretty bare bones right now, but we're working hard to make it a really great resource for the DIYBio crowd. In summary, yes, it is a social network rather than an open-source extension like Zotero. But Nucleus is less about organizing and sharing research that has already been published; it's more about sharing your work as you do it and getting feedback from other Nucleus users. This is ideal for DIYBiologists. While currently most DIYBiologists and other citizen scientists share their work on their own websites or blogs, we want to bring all that under one roof. Our hope is that by providing a home for a grassroots group of indie scientists to share and collaborate freely, this mindset of openness about research will translate up the ranks and fundamentally change how science is performed for a modern age.

Right now you can create an account, name a project, and then upload data in the form of figures. Then you can share that link and invite others to view the data and comment. Soon you'll be able to tag your work by subject to become discoverable by the community. Nucleus is open to any and all who are willing to try it out. If you have questions or want more information, please comment on this post, email info(at)wearenucleus(dot)com, or hit me up on twitter at twitter.com/SuprDave. Thanks everyone, I hope you enjoy Nucleus!

[Cathal Garvey (Phone)]

I have a question: what's your business model or income stream? To what extent are users the product to be bartered and sold?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[David Taffany]

Hi Cathal. Right now the site is totally free to use. We're looking into a few strategies to monetize down the line. To be clear though, users will always retain 100% ownership over anything they upload to the site. We're also not going after users' personal data, for example for the purposes of ad sales. Eventually, we anticipate using a "freemium" model where a basic version of the site is free to use and additional features will be available for a monthly fee. Right now we're just trying to get as much feedback from users as possible and then try to figure out how we can bring enough value that people will want to pay for.

[David Taffany]

Hi All,

It's been a while but my team and I are still working on our site, Nucleus (www.wearenucleus.com), as a home for DIYBio on the web. Here's the idea: DIYBiologists post about their experiments, and others can view the results and comment, critique, and give "kudos" that help the scientist's reputation on the site.

We think there's a huge benefit to bringing DIYBio projects under one umbrella, rather than sharing only on community lab wikis or personal blogs. We hope Nucleus can be that umbrella, allowing for a network effect that will bring citizen science projects greater discoverability along with greater reputation and collaboration opportunities to the scientist.

The team is just myself and two others. Nucleus has no affiliations with any larger institutions. We're building it because we really believe in citizen science and its potential to change science at large. We're hoping Nucleus can help all of you work together more easily. We'd love for people to check it out, and please feel free to reach out with your thoughts at david -at- wearenucleus -dot- com. Thanks!

David

[Nathan McCorkle]

David, its hard for me to tell how good it is, as there doesn't seem
to be a well prepared example Project (they all seem like development
test projects).

> --
> -- You received this message because you are subscribed to the Google Groups
> DIYbio group. To post to this group, send email to diy...@googlegroups.com.
> To unsubscribe from this group, send email to
> diybio+un...@googlegroups.com. For more options, visit this group at
> https://groups.google.com/d/forum/diybio?hl=en
> Learn more at www.diybio.org
> ---
> You received this message because you are subscribed to the Google Groups
> "DIYbio" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to diybio+un...@googlegroups.com.
> To post to this group, send email to diy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/diybio.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/diybio/156c5b48-637d-42bc-a114-21e1a50a8e1c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
-Nathan

[David Taffany]

Nathan, 

Yes, embarrassingly, you are correct! We're in that very early Catch-22 stage where in order to recruit users, we first need some users. We're looking for some enterprising beta testers to be the first ones on there and set the example. If you've got a test project you'd like to post, I'd be happy to help you through the process and would love your feedback.

David

[Nathan McCorkle]

It would be nice if your team could showcase at least one example
Project, to expose all the features of the site for others.

> https://groups.google.com/d/msgid/diybio/85e2c626-6572-423f-adb1-5d6fc734a23a%40googlegroups.com.

[Dakota Hamill]

Ya i made one just to see what it looks like.  The idea is great no doubt, but I guess the final product remains to be seen.  What features are you hoping to add?

To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/CA%2B82U9%2BLm-gV6gFxAbg%2BbBLefByiJb%2Be3U7QMtMSOoRey7%3DoRQ%40mail.gmail.com.

[Dakota Hamill]

I'm on my  phone now so cant be really type well but, I guess I'd approach it from a scientists perspwctive.  There are 100 project management platforms out thetr.  Make yours unique and geared towards data, pictures and graphs, and maybe a lab notebook type setup.  Idk.  It'd also be cool to add a feature that would allow people to get points or a thumbs up type of recognition for having a protocol that works.    In science repeatability is key, so a way to give a tip of the hat that someone has used your experiment and it worked would be cool

[Nathan McCorkle]

also version controlled text (at least), ability to fork or transfer
Project ownership (experiments usually build on previous protocols).

> https://groups.google.com/d/msgid/diybio/CAGdeWmQYBZt4dhWB7G%3Do2%3DRg0_vPi__VoyRhenkOU%2Bd4-WtmtA%40mail.gmail.com.

[David Taffany]

Dakota, thanks for your input. There is definitely a long list of features we'd like to add, as you might imagine. Naturally, the direction of our site will depend entirely on how the community embraces it. We're anticipating two main areas of focus: open sharing and private project management. Ideally, we'd like to support both, and likely we will down the line. But first, because we want to support the open nature of the DIYBio community, we decided to focus on just making it really easy for users to share data. So we made big buttons for "Create a Project" and quick, minimal upload and view features. Moving ahead, the next challenge is to focus on making that data beautiful. There's a lot of potential in viewing data in an interactive format. Our design experience is limited right now, but we're learning quickly.

As you said, there's a lot of project management tools out there for scientists already. Right now there is the option to make a project private and you can use Nucleus solely for keeping track of projects. Again, we wanted to focus on sharing at first, so more robust project management features are still to come, for both public and private projects. For example, we're working on integrating Markdown and LaTex support for a dedicated protocol tab to accompany the data.

When you get back to your computer, I hope you'll upload some data and get to try it out in more detail. Thanks!

[David Taffany]

Nathan, thanks for those ideas. As I mentioned in my response to Dakota, we're working on a dedicated space for methods/protocols to accompany data, and this will support Markdown to make versioning easy. The ability to indicate a project builds off of another is in the pipeline as well. A GitHub-style site for science datasets rather than code was the inspiration for Nucleus, so we will try to emulate as many of these types of features as we can moving forward.

David

[Nathan McCorkle]

On Fri, Apr 4, 2014 at 5:04 PM, David Taffany <david.a...@gmail.com> wrote:
> Nathan, thanks for those ideas. As I mentioned in my response to Dakota,
> we're working on a dedicated space for methods/protocols to accompany data,
> and this will support Markdown to make versioning easy.

Markdown isn't for versioning though, is it? I thought it was just
meant for defining how things should be rendered (i.e. bold, as a
hyperlink, as an ordered/unordered list).

What is the software backend? What have you done as far as a security
assessment? Are you planning on getting an SSL cert?


--
-Nathan

[Nathan McCorkle]

Things I noticed. The Abstract and Hypothesis sections would be nice
if they expanded rather than overflowed. It seems after adding those
data, I can only upload a 'Figure' file, I don't know what files are
acceptable so I tried an .exe and the server gave me a 500 error!

--
-Nathan

[David Taffany]

Nathan, you're right. At its core, Markdown is more of an easy method of text input. But we can do some things with the site to make version tracking easier with Markdown files. Stay tuned. The storage side of the site is hosted with AWS, and yes, we are looking at SSL certification. Of course, security of uploaded data is extremely important to us, especially for Private Projects.

Right now, we're supporting upload of PDFs, images, and Microsoft Office files. We hadn't considered people wanting to upload .exe files! What kind of program are you trying to upload?

[Nathan McCorkle]

I was really just testing the uploader... I didn't know an .exe would
cause an error, but you should be restricting the selectable filetypes
in HTML, again checking on the server side, and returning a better
error than 500 if an upload error does occur (i.e. "the upload was
corrupted, your file was malformed, or our server has a bug")! Also
listing out the acceptable file types to the user would be a
no-brainer.

> --
> -- You received this message because you are subscribed to the Google Groups
> DIYbio group. To post to this group, send email to diy...@googlegroups.com.
> To unsubscribe from this group, send email to
> diybio+un...@googlegroups.com. For more options, visit this group at
> https://groups.google.com/d/forum/diybio?hl=en
> Learn more at www.diybio.org
> ---
> You received this message because you are subscribed to the Google Groups
> "DIYbio" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to diybio+un...@googlegroups.com.
> To post to this group, send email to diy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/diybio.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/diybio/436bbdfd-57f8-4879-b852-1e9f3e83f9b4%40googlegroups.com.

[David Taffany]

Nathan, correct on all counts. I'll add those to the to-do list! Thanks again.

[Nathan McCorkle]

On Fri, Apr 4, 2014 at 5:50 PM, David Taffany <david.a...@gmail.com> wrote:
> Nathan, correct on all counts. I'll add those to the to-do list! Thanks
> again.
>
>
>
> On Friday, April 4, 2014 8:46:28 PM UTC-4, Nathan McCorkle wrote:
>>
>> I was really just testing the uploader... I didn't know an .exe would
>> cause an error, but you should be restricting the selectable filetypes
>> in HTML, again checking on the server side, and returning a better
>> error than 500 if an upload error does occur (i.e. "the upload was
>> corrupted, your file was malformed, or our server has a bug")!

Note that I didn't mean to modify the 500 error page, but rather to
catch the error in your code and return a better error response. That
way if errors that you're not expecting occur, a 500 will still be
thrown and you'll know its a new bug.

[Patrik D'haeseleer]

On Friday, April 4, 2014 2:45:14 PM UTC-7, David Taffany wrote:

Nathan, 

Yes, embarrassingly, you are correct! We're in that very early Catch-22 stage where in order to recruit users, we first need some users. We're looking for some enterprising beta testers to be the first ones on there and set the example. If you've got a test project you'd like to post, I'd be happy to help you through the process and would love your feedback.

David

If you want a fully fleshed out sample project, feel free to copy over material from our BioPrinter or Ghost heart instructables, provided you include a link to the original:

http://www.instructables.com/id/DIY-BioPrinter/

http://www.instructables.com/id/Ghost-Heart-in-a-Jar/

Patrik

[David Taffany]

Patrik, this is great. I'll get to work posting it into Nucleus. Thanks!