Tool page redesign; separate intro/explanatory from active development

[sdosemagen]

Point: Sara Team: Mathew, Jeff Importance: high

• Confusion on tool pages- development or documentation- move towards a tool developer dashboard and tool documentation page- lots of development that is going on
• Are you looking to build the tool- get involved in process with other people- do you want to know what the tool is about?

[swylie]

Draft of objectives for this issue: This project aims to revise the documentation of tool development on the website in order to increase community access and participation in development through better tools for tracking involvement, communicating/setting/meeting project development needs and goals and improving information flows between tool development projects. Specifically we will redesign the tools homepage, tool pages, and a develop “tool developer” dashboard.

[jywarren]

this task was to redesign the "tool pages" like for example http://publiclaboratory.org/tool/thermal-photography - of course it has implications for the tool dev process. But the first steps may be:

• researching how they are currently used (google analytics and observing users, short interview/survey)
• listing the purposes we see or hope for on tool pages
• listing functions and specific features we want to add/improve
• going through a set of mockups to see how the features/revisions would look and work (probably soliciting feedback)
• testing revisions and assessing results/feedback

[swylie]

Great list Jeff, thanks! I have started a slide show where we can develop the formal proposal around these next steps. I've shared it with you and Mat: https://docs.google.com/presentation/d/1x8qaj-AjFnItkE2di779QIfcApywR_kmzMOMcuSQFRc/edit#slide=id.p

It also includes a draft of the tool dev. timeline--please take a look and send ideas.

[swylie]

A feature to improve I think is the links between the tool pages and their relevant research notes. I have been thinking we could add a tagging feature to research note to assign them different types. Some ideas for types of notes:

1. literature review or bibliography
2. examples of field test
3. directions for building
4. describes proof of concept---These categories could be tied to the milestones that move a project through the development cycle. .....

The tool page could then have categories for these research notes/wiki pages that are automatically updated--so you're not faced with tracking back through every research note when trying to access a project.

[jywarren]

there is already a tagging feature; so we can just start some tags. Tag name suggestions:

literature review or bibliography - "reference" or "reading" or "research" i like the latter... examples of field test - "field-test" directions for building - "guide" or "howto" describes proof of concept - "proof-of-concept"

i'll upload some of the sketches/mockups I've been doing soonish

[swylie]

I've made a set of screen flow videos of google analytics for each tool page, they are in the video section of the dropbox. I have a really hard time interpreting the statistics? It would be really helpful to hear what you guys make of these analytics?

[swylie]

Though each tool page is a subset of the over all tools page, I made a draft of a possible overall tool page, that would integrate the tool development process with the display of projects. https://publiclaboratory.mybalsamiq.com/projects/userdashboards/mockup+Public+Lab+main+tools+page

[swylie]

Other ideas of tool page redesign: New features:

1. subscribe to this tool button/menu (where you can also see who else is subscribed and working on it)
2. link to research notes for this tool (organized by category of note)
3. ability to add pictures and videos more easily (like the research note--post a gallery of photos)
4. support this tool? (ability to donate to the tool or make an offer of help/resources)
5. Add a story/research note (making it clear that people could add a story about how the tool might be useful for them)
6. Include the icons for tool development we've been discussing here: https://github.com/jywarren/plots/issues/133

[swylie]

Thoughts on Google Analytics:

Overall Tool Page:

1. The tags for tools development stage are rarely being clicked eg. "in development" "early adoptor"
2. The tools at the top of the page are being clicked through more frequently--could the need to scroll down to see the other tools be unintentionally effecting that?

[jywarren]

So it looks like we're ready for a mockup of the tool page, using the icons and perhaps a tabbed approach to research notes/wiki pages/contributors?

As for the Google Analytics, interpreting analytics is always difficult. I'll take a look and see if there's anything I can glean from the stats.

As for the "status" links -- it makes sense that users wouldn't click on them -- the two reasons I can think of to click on them are a) you want to know what this "status" thing means, or b) you want to see other tools of the same status. Neither seems like a common thing to want, but I might prefer the latter. Regardless our icon-based redesign may change all this.

For your second point, absolutely -- the top items will always be clicked more. Sorting the http://publiclaboratory.org/tools page by # of views is kind of circular -- more popular items are driven to the top and so they're clicked on more. But dividing up by tool status as your mockup shows sounds like a nice alternative organization. We could in theory randomize the order within each status group. But given that balloon mapping is our most popular tool, it does kind of make sense that it shows up at the top left.

[mathewlippincott]

I posted a comment over on balsamiq two weeks ago that I hoped would spark debate but seems to have just gotten orphaned--

I don't think we can mock up the main tools page until we think about what the sandbox should look like.

(remainder of comment moved over to #133, Sandbox issue -- Jeff)

[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

[jywarren]

Sorry -- i saw that and was interested but was off work or at Ecosynth last week so didn't get a chance to respond.

I think we might move this back over to the Sandbox issue, since although it would precede the general Tool page, its not quite the same page. Would you mind if I copied your comment over and removed it from here, so we don't overflow the comments area? I am writing some notes about the sandbox process and want to add it after your comment, but on the other thread (#133).

The Dart Project's commenting system is reminiscent of the Google Docs comments... i've never seen a comment-able wiki but that might be an interesting experiment.

[mathewlippincott]

sure-- lets copy over to 133. I see the sandbox as central to how we set up the tool page, but you're right-- not the same page.

After seeing the Dart Project's in-line comments I keep dreaming about them. In-line comments would really help us develop pages, and put process, rather than product, front and center.

[mathewlippincott]

moved everything to 133. should I remove the comments here?

[jywarren]

indeed, it's a pretty neat system. the "talk page" system on Wikipedia seems crude by comparison. It re-inserts authorship into wiki pages without disrupting the flow/cohesion of the content which everyone is trying to write together.

[jywarren]

Taking an idea from Mathew's comment in #133 -- I also like the idea of making tool pages primarily discussion pages. I think the idea of having tabs on tool pages separating wiki documentation from active research development could achieve this -- and we could have the latter (research notes) be the default tab.

[jywarren]

Not to jump the gun - i know we want to talk sandbox first -- but I was watching some of RJ's farmhack planning vids and had to try some ideas for the tool page -- namely a button on the tool page prompting you to post a related research note:

Oooh, or even:

RJ captures really nicely here: http://youtube.com/watch?v=R06nlcDwm9A&feature=relmfu how a wiki and a discussion forum (in our case, notes + mailing list) can be a cycle where wikis spawn questions, concerns, ideas, which eventually get cycled back into a wiki after discussion. OK now i'm going over to read the rest of RJ's comment in #133.

[mathewlippincott]

I'd hold off on making separate linked out pages. I really feel I should read a statement and it should be accompanied by a concern. I want to be able to see how contentious/problematic/unresolved the existing text is, so there's a sort of procedural froth dripping off the wiki text in situ.

my ideal case is some sort of two column wiki + forum/threaded comment situation, but I'm really set on the idea of making sure that comments/discussions all link to specific spots of text in the wiki, and that their existence is visible somehow in the wiki.

[jywarren]

Procedural froth sounds delightful. As RJ points out, in traditional wikis froth happens in the Talk page...

OK - RJ and I talked through some possible approaches, and I'm going to outline two, from least-ambitious to most-ambitious. RJ brought up a good metric for evaluating new designs -- how often do you think it will be used? I think the key points to consider are:

• intended audience -- is it a way to get newcomers to engage? or non-technical contributors? or is it a way to preserve history?
• how hard it is to explain to newcomers (or how much proposed changes add complexity to the mental model of the site)
• how well does it balance familiar modes (blogs, wikis) with new forms (which may be more powerful but have a learning curve)
• how hard it is to use -- also, will we "eat our own dogfood" and use this system ourselves?

A. Minimal

Put a series of prompts on each tool page (and possibly each wiki page) inviting people to i. ask questions, ii. raise concerns, iii. offer ideas, and iv. post data related to the tools development. These buttons would just open a new research note tagged "question", "concern", "idea", and " data", as well as a tag linking it to the given tool.

• if extended to wiki pages and research notes, it might save a URL of the page the user clicked the button on, and include a suggested "(Commenting on )" in the body of the note form.
• the note posting form could simply be a popup or floating modal box
• a recognizable bar with the buttons in colors or with icons could be universal across the site - maybe at top/bottom of any wiki page?
• the button prompts could be different depending on what "stage" a tool is at
• tags would allow viewing of all tool-related notes, as currently possible (but with better design, maybe a "notes" tab)

B. Major

Make a "gutter" alongside any wiki page, which when clicked on (like in GitHub code view) prompts you to write a research note along the lines outlined above.

• this could "accordion" open or open in a floating bubble window
• the research note would (using URL params) be linked back to the specific line (paragraph) you "raised the issue", with a link "Commenting on..."
• small speech bubble icons could indicate where "issues" have been raised (question, concern, idea, data) in the gutter. Possibly you could view a list of them in a bubble popup

Both these designs would get at the mutability of wikis, inviting new or non-technical input, cultivating a culture of iterative critique/discussion/refinement, and the balance between documentation and active research. The former has fewer features, but would take much less time to implement. It could also be "upgraded" later based on evaluation of its usage.

[jywarren]

Also: A. has "page resolution" whereas B. has "paragraph resolution".

A staged approach might start with just implementing buttons, and pre-populating the note submission form with the relevant tags/links without doing the whole popup interface from the get-go.