Sandbox category for tools

[sdosemagen]

Point: Jeff
Importance: Not designated

• Want to add a “sandbox” category for tools “In development” “Field tested”- sandbox- any idea anyone has to make anything

[rjcorwin]

On FarmHack.net we went with "Tool Stages" of:
Concept - from idea up to when the tool has been tested.
Functional prototype - tool has been built/tested in the field, but not fully documented.
DIY - tool has been built and documented well enough that it could be reproduced.
Commercial Product - currently being manufactured and available for purchase.

[swylie]

Megan: http://publiclaboratory.org/people/megan has some ideas for remediation tools she'd like to sandbox, perhaps she'd be interested in helping out with this.

[jywarren]

Currently we have "early adopter only", "in development", "proven in the field", and "ready for use". Do we want to rename "early adopter only" or make another category which precedes it? Also, what's the difference between "proven..." and "ready for use"?

Then we should move on to page design indicating clearly which tools are in which status. Maybe icons or something next to the title and a "what does this mean" link -- or the icons themselves could just lead to a page at http://publiclaboratory.org/wiki/tool-status which explains each.

If people like icons, we can try to pick some out and do some mockup/sketches to see what that'd look like. Maybe from http://thenounproject.com/

[jywarren]

Ideas:

"sandbox" - http://thenounproject.com/noun/beaker/#icon-No325

"sandbox" - http://thenounproject.com/noun/idea/#icon-No762

"sandbox" - http://thenounproject.com/noun/dialog/#icon-No2172

"proven in the field" - http://thenounproject.com/noun/idea/#icon-No762

?? http://thenounproject.com/noun/laboratory/#icon-No584

Lots of tools: http://thenounproject.com/tag/fix/

[swylie]

I like the icon idea. I think a consistent metaphor might help-how about one around growing.

Sand box--sand castle?
early adopter--seed
In development--a shoot (newly growing plant)
Prototyped--proof of concept--flower?
In field--tree/fruit?

So it speaks to both genders we could keep the graphics sparse?

[jywarren]

nice thought on growth metaphors. http://thenounproject.com/tag/tree/

[swylie]

What about these icons to be more specific?

Sand box--sand castle? http://thenounproject.com/noun/beach-bucket/#icon-No2017, dream http://thenounproject.com/noun/dream/#icon-No1216

early adopter--seed--http://thenounproject.com/noun/acorn/#icon-No340
In development--a shoot (newly growing plant)--http://thenounproject.com/noun/plant/#icon-No1169
Prototyped--proof of concept--flower--http://thenounproject.com/noun/flower/#icon-No689 --though the flow doesn't seem quite right?
In field--tree/fruit?--http://thenounproject.com/noun/tree/#icon-No2141,
or fruit picking http://thenounproject.com/noun/fruit-picking/#icon-No740

[mathewlippincott]

I think this discussion should fold into Tool page redesign, #138 while icons are interesting we need to focus on the page design and workflow of what it is to have a sandbox.

[jywarren]

agree, this is now a clear subset of #138, although i realized i wasn't sure if "sandbox" is the same as "early adopter" or an entirely new stage of development? I think i was assuming people just didn't know about the "early adopter" tag because we've never really made it a clear part of the design of tool pages

[mathewlippincott]

this comment moved over from issue #138

Each other section should flow out of how we want the early creative stages of tool development to flow. I based this on the "entering and leaving the sandbox" diagram that came out of our tool discussions and that is slide 2 here

[mathewlippincott]

I think that in terms of sections, we really should just have "sandbox" "in development", "proven in the field", and "put to use" this last category would mean that the desired outcome, as defined in the sandbox, has been achieved.

the sandbox, in this categorization, would incorporate the "prototyping" stage, and "early adopter" would be in the "in development category.

[mathewlippincott]

I found a great example of a project development page at DART, where they're planning a thermal imaging survey. I love the two-column format that invites comments and discussion side-by side with the project:
http://dartproject.info/WPProjects/?p=18

given the complexity of defining the sections of the sandbox, I feel that these kinds of in-line notes would be especially useful here, but also generally useful in tool development.

[jywarren]

OK very cool; this makes a lot more sense than just a change of tag name, and I see why it was a whole "issue" now.

So -- as always, I want to balance my reluctance to create new technical systems (which may not fit everyone's process) with the awareness that if we don't clearly prompt people to ask questions, propose solutions, get involved, they may never do so.

For any addition to the website, I prefer simple, reusable systems, like Post-its, rather than ones that try to too-closely follow a flowchart -- like, in the worst-case, the ticket kiosk at an airport. Still, the kiosk may be the best solution. I just want to exhaust the other simpler possibilities before investing time in new infrastructure and the complexity it brings. Bear with me as I always look for a way to solve things with our existing system or through human behavior first -- just trying to be a skeptic.

So here i'm going to try to propose a few ways we could achieve the goals in the Sandbox process you laid out:

• a wiki guide page with these steps -- called "tool troubleshooting" or "moving out of the sandbox" or "are you stuck in the sandbox?"
• a person could do these steps instead of an interface? a role? we could do nominations for tools to get out of the sandbox, and refer to the above wiki page?
• new tool pages could always start as "sandbox" tools, and could be pre-populated with wiki content outlining these prompts, which is slowly replaced by real content?
• a custom system with several new types, such as "sandbox-issue" "sandbox-data" and "sandbox-designs", or these could be modified or tagged research notes...

The final one is closest to what your mockup depicts, but also the one i'd like to try last -- it could be the right approach but i want to play devil's advocate until we've tried easier, more flexible approaches.

[mathewlippincott]

Our current workflow is about building objects, not defining and solving problems. We need to be defining problems and defining what kind of data can solve them. I don't see in your proposals any alternative ways to do that-- just further proposals on ways to define parts of the object development process.

the tool pages need to be discussion pages with aggregation and comparison of research notes as a central focus, with an explicit goal of moving towards a defined data standard. the existing wiki is terrible at that. Right now tool designs win out through coming to the top of the classic open source "do ocracy" system-- whichever gets the most work wins-- not because they meet a defined community need. The data standard is defined as whatever data the tool generates.

(where on our site would a community define their need? and preserve control of the process through contexualizing the work of hackers?)

A wiki page explaining the issues of being stuck in the sand box won't get any where near this. Just having wiki prompts isn't enough.

Our existing system is about documenting hacking with the goal of creating a centralized documentation repository for others to recreate the object-- (and we're doing a good job at that) not necessarily talking about why, or preserving the mistakes, misdirections, and explorations in future discussions. Or about allowing non-technical people to maintain the problem definition. How are different approaches to be judged and on what standard?

I don't think that this problem is solvable within our current system. the workflow for balloon mapping is-- public discussion on GM list or personal e-mail question---> stuff gets made---> note gets generated --> note gets commented --> more notes generated ---> notes summarized on the wiki page. New discussion begins.

Somehow we need to reverse this workflow and make it cycle back in on itself: discussion on the problem and data to solve it happens on a page--->stuff gets made---> note gets generated---note gets contextualized/judged in discussion---> discussion continues (circle back to beginning).

[jywarren]

fascinating -- the upshot of what you're proposing is that the website architecture ought to enable non-technical contributors to exert more control over the development process? I had been thinking of users as a single group up until now.

The workflows you're describing are a great way to think about this. But, I wonder if a wiki page is the best place to start the discussion -- since new contributors don't really "get" wiki pages as readily as blog-like notes --- or email list discussion. The two things i really like about Workflow 2 are:

• making questions a more central part of the website, rather than just tech solutions
• making comments/discussion a place to refocus and recontextualize tools on goals -- i.e. "that's a neat demonstration of using a laser to get oil to fluoresce; how could that apply to testing for PAHs in the stream behind my house?"

I guess i'm not sure about the binary of "communities with needs" vs "hackers with tech", or at least I'd like to try diffusing that binary, so if we can achieve that through the website structure, that would be cool.

So perhaps we could think about these issues together -- and ask:

• Can we encourage involvement from non-technical people who have very good understanding of a problem, by helping them voice questions and pose challenges?
• What is a low-barrier way to invite such exploration of needs, and asking of questions or posing of challenges? Does it require a content type which is substantively different from research notes, comments, or wiki pages? Or the mailing list?

What about some kind of form (that doesn't presuppose a tool yet) which prompts people like:

"how can i ..." or "how does this tool help me..." or something? which creates a research note, even... i dunno. I need to ponder this for a bit. What do you think?

[jywarren]

Our comments are crossing in cyberspace :-) catching up on your latest now.

I'm sorry - i didn't mean that diagram was kiosk-like, i was more referring to the page design. Also i don't think kiosk style design is bad.

I'm trying to think of all different ways to do this -- brainstorming:

• when you create a new tool, you are presented with a form where you can answer some of those 4 questions, and it auto-generates a wiki page of them?
• tool pages display research notes organized into several categories (based on the 4 questions) and (all?) notes are somehow prompted to address one of those
• regular meetings (specifically including non-technical folks) or list discussions raise such questions for each tool

I'm also trying to think of how such a system can accommodate different workflows -- sometimes you work sideways or backwards when you realize a tool has another application than originally intended. So one ramification is that these 4 questions might or might not only be for when tools are first being created. What about finding a bunch of described needs and ideas, and deciding a tool has "emerged" from it?

[mathewlippincott]

I'm not wedded to that design I threw up. I think you're getting there with these suggestions. below are some more notes, but I'm thinking more and more its discussion integration that is the central issue here, with some way to move discussion towards a "data goal"

you're right-- sometimes a tool turns out to be used for something other than its original use-- like the spectrometer, designed for detecting oil, being used for calibrating aquarium lights.

What about opening the wiki with a series of "problem definitions" that could be collapsed/expanded? is that a technical problem? I'm thinking it could work the way wiki mobile does their pages.

Spectrometer for Oil detection (expanded)
*What do we need to know?
*What do we want to do with the knowledge? (what does the info need to be good for?)
*What kind of data do we want? (in order for the info to be put to use)
*How often do we want to collect the data?

Spectrometer for light calibration? (collapsed)
goal: x accuracy for x range/ x sampling rate.

as would aggregating the notes onto the tool page by keyword.

[mathewlippincott]

back to the DART comments system--

this could get unwieldy fast, with lots of comments going up and no way to "collapse" them/move on from them. There would need to be some sort of system where when comments lead to a wiki edit, they can get thrown in an archive.

[rjcorwin]

Awesome conversation! I'm short on time so I'm going to dump everything I've been thinking about here...

On the sandbox status

Before I go off on issues not related to the original intent of this ticket :P... I think we can wait on creating a process for vetting wether or not a Tool should be allowed out of sandbox (ie. some kind of vote prior to leaving sandbox). Writing up some guidelines and then having an administrator catch Tools that are blatantly ignoring the guidelines I think would be much less work until the rate of Tool generation gets to something like 10 a month.

On categorizing information about Tools

I like those 4 categories that you guys came up with: problem definition, literature review, tool designs, and collected data. It looks like "problem definition" would be a sort of wiki while lit review, tools designs, and collected data are categories for research notes.

On FarmHack.net we're currently going with the template approach for Tools. The Tool, Tool Wiki Template, is a tool that gets cloned when someone creates a new Tool.

On categorizing discussion

Jeff mentioned, "making questions a more central part of the website, rather than just tech solutions". I'm totally into this especially because 1) sometimes we need the right question to find the right answer and 2) it provides an on ramp for people to get involved and some day become a contributor. This is why question is one of four categories for Tool Forum Topics on FarmHack.net. The other 3 categories are new information, idea, and problem. I recorded a video of me explaining this http://www.youtube.com/watch?v=OvyJhRnIVxA&feature=plcp

Are we sure we're still talking about Tool pages?

One of the things I've been struggling with on FarmHack.net is, "Do instructions on how to build go on these Tool wikis?" I think the answer is no, and from where y'all are going with this, it looks like you're on the same page. I've been thinking lately how Tool pages feel more like... Topic pages. Reading this ticket reinforces my feelings about this as it seems the goal is really to define a problem and to documents/discuss how to solve it. So, I just want to throw this out there, we might want to think about renaming Tool pages to something else.

So if we have a bunch of Problem/Topic pages where will Tool development/design happen? I think this goes back to what Wikis are good for, and what they are not so good for. The video I made above is titled "Using Wikis for Collaborative Design" but I'm not so convinced that Wikis actually are good for collaborative design. Thinking about how open source projects work with halo developers that control design direction and vet patches, I think the open ended anyone-can-edit wiki tradition kind of tears the motivations apart for people. Wikis are however good for documenting what already exists, so, they are great for Topic pages.

These days I'm very much interested in how to collaboratively design source code, an instruction set, that is run outside of a computer by humans. I think this is totally possible using git repositories and github, but, there is a high barrier to entry there. At the moment, the Composer project from Substance is the only project trying to tackle low barrier to entry document collaboration in a GitHub like way.

From their README file

Since collaboration is more imporantant than ever before to create high quality content we've added the concept of patches to turn every readers into a potential collaborator.

There is still a lot of work to do on that project but there is an older version (no patches :( ), that is live and you can create documents on right now. http://substance.io/substance/getting-started

On site UI

Mathew mentioned making things collapsible. I actually have a theme for the FarmHack.net tool section running locally using jQuery Mobile. I think it looks pretty nice.

[mathewlippincott]

I love the video explaining wiki collaboration RJ! Thanks for that. Glad to know that collapsing some sections wouldn't be a problem.

I'm fond of those categories for discussion too-- Concerns, Ideas, Questions, New Information. I'm wondering if discussion forum pages be started by tagging the wiki, sort of somewhere between {{cn}} and the make new wiki [[page]]? it could be a regular discussion forum, browsable as one, but intricately linked into the wiki pages.

could I go through the article and start tagging things {{Concern}} {{Idea}} {{Question}} {{Info}}, so that when reading I'd see "Blah blah blah is the bestest{{Concern}}" and link straight to a discussion that would then, like github issues, get closed, or possibly "integrated" and then retire to being a footnote of the discussion, so eventually when the concern gets integrated it would read: "Blah blah blah is the bestest for doing x, other things are good for y{{footnote1}}" with the footnote linking to the closed discussion.

I'm imagining a template for a new tool/topic page (you may be right that we need to move them to topic, rather than tool):
*What do we need to know?
{{Idea}} {{Info}}
*What do we want to do with the knowledge? (what does the info need to be good for?)
{{Idea}} {{Info}}
*What kind of data do we want? (in order for the info to be put to use)
{{Idea}} {{Info}}
*How often do we want to collect the data?
{{Idea}} {{Info}}

[swylie]

Hi all, great conversation. So glad this is progressing.

I need more time to fully digest everything. But wanted to add a first couple of thoughts about how I've been thinking of the sandbox:

1. It seems an an important category to in the problem definition section would be "relevance to Public Lab's Mission" so that each project is getting evaluated specifically for DIY, open-source, environmental relevance and low cost possibilities out of the gate.

2. I had been imaging a sandbox process where lots of different people could give a small amount of input so notes like

a) a person's description of an environmental health issue they are dealing with
b) out of the box ideas--Megan wants to try reducing acid mine run off in a DIY fashion by making sodium bicarbonate filters for instance
c) expensive existing tools that are good candidates for making DIY

Ideally then it would be cool if people could use the sandbox to find each other and build a community interested in working on a project.

So I'm wondering how ideas like these for use cases would work in the mock up you have Mat?

Also I think we should produce a similar page as this for each site where a developed tool will be used, to ensure that they have thought through what they are using the tool for and that the data will help their final goals.

finally,

Awesome video RJ!

[jywarren]

OK, just as we're pondering this all, I have a slightly more abstract question which may help us contextualize the issue. I think it'd be helpful to think about whether the sandbox is:

• a new kind of collaborative content creation or new discussion format
• a new way for the website to guide the creation of tools (or topics?) -- i.e. a new interface, form, or template, vs how they are currently created
• a new collaborative mode or set of practices which contributors employ in brainstorming new tools

There are different arenas in which we could try to improve how PLOTS works -- creating infrastructure, changing peoples' understanding of process, and changing peoples' behavior are three I can think of.

That said, in thinking about the tool page I posted some design ideas which might be pretty relevant to (or adaptable to) the sandbox -- if, that is, we think of the sandbox as primarily a new infrastructure or web interface: #138