View source for Vision for OneVille documentation

==Overall hopes for our documentation:==

Documentation should be coherent -- glued to our core research questions, throughout.

Most of all, we need basic analytic categories coherent across the project. Otherwise the project will not make a clear contribution to thinking or work.

-cites/'''citations''' to research or other projects should go as if in footnotes (secondary for the reader).

-simple language.

-examples of "ahas" and “how to” take precedence so that we show what we learned in this work and help others tackle the same sorts of issues where they live.

Documentation should be visually inviting, even playful/fun. Think of enticing a teacher or young person or parent to tackle similar efforts where they live. Use lots of visuals and photos and color. 

Show individual and group photos (or short video clips) of our participants, particularly next to their voices or work. 

Imagine a final product that looks like http://one.laptop.org/stories; http://pantone.wikia.com/wiki/Pantone_Wiki; (http://ohinternet.com/Main_Page).

The site should be hypertextual and particularly, should link to other projects within the OneVille Project.  

The documentation should include the voices of our participants. (see below)

(More details:) 

Documentation should in the end be downloadable, and distributable by people; something they can email around their school.
 
The documentation should perhaps also include our contact info, so that people can ask questions of us and our participants. Should we urge people to “please contact us"?

We might offer an index that also talks about other things to read.

          
===Of particular concern: including participant voices===

We hope that the more direct quotes, products, and videos we have from youth, parents, and youth/'''and educators,''' the better we will convey what we've been doing.

We might get quotes from participants through targeted interviews now as we co-construct the documentation, or, take them from data collected throughout the project.

We might include short video interviews that enrich the content but aren’t required by site visitors to watch if they want to understand what we've been doing.

Not all of our participants will want to work on this documentation from scratch with us. Some will and we'd love it! But some will want to comment on examples as they take shape. We should invite any version of participation.

====Some prompts for getting those voices in interviews:====

(What communication supporting students did this working group make a bit more possible?

(if known: What new support for young people has resulted?)

(What interested you in doing this in the first place? What did you think might be gained?)

(What are particularly thought-provoking examples or stories from your project, that say something about improving communication in public education?)

More specifically: was there some moment in the pilot when you realized something about needed communications in public education? [COMMUNICATION AHAS]

More specifically: was there some moment in the pilot when you redirected the work to make something succeed? When the project stumbled and you had to come up with a solution?[IMPLEMENTATION AHA]

(What are continuing barriers to needed communications?)

(Should others do what you have been doing? What would you tell them to make that possible?)

==Platform thoughts==

In our Memorial Day planning meeting, we agreed that the platform needs to allow us to update it over time. We at least want the potential to grow a conversation bicoastally and, to let continuing projects report out on what they are doing (texting pilot; dashboard updates, parent connector network in particular. Even eportfolio as it continues to grow, if they want to report their ongoing realizations online here!)

Seth’s suggestions/responses to Susan’s points questioning the choice of a wiki:

-fonts: we can find any font available on the web.
-googlesites are not PDFable.
- a googlesite also allows you to link w/in the site. A wiki allows you just to [[ ]], but, with a googlesite you’d just link the hyperlinks.

-the default wiki skin is less attractive but a wiki can get just as attractive. (e.g. the audacity documentation Mica sent out as an e.g. of exciting visuals is a wiki.)

-wikis allow font to be consistent across. 

TBD: Seth calls for consistency in font size and hierarchy of info. 

-wikis have less technical problems.

-videos can be on YouTube, embedded.
http://www.youtube.com/watch?v=qs5yA7-N4Ak

***the ultimate point: more easily enabling co-creation now and, possibly, later.

a wiki can be as rich as a website. (Mica’s main worry about wikis)

a wiki could afford later co-creation.

googlesites may at some point shut down, a la Google Translate’s recent restrictions.

In the end, we recommitted to the idea of using a wiki for this documentation, as long as it follows the vision above of being visually exciting!

==Plan to set each working group free to document==

Still working on this. But:

Over Memorial Day weekend and in a week of work afterwards, we set basic initial categories for documentation that we wanted to hold across the project (see below). From here forward, we ask that each working group:

a. start trying the categories and see how they work,

b. explore how the documentation of each could be made most visually inviting,

c. keep asking/inviting people in your working group how to shape the documentation in order to best support other educators/families/students (in Somerville or anywhere), to tackle similar things.

To do this, we looked at the Parent Connector page on the wiki, to consider its initial categories for what each working group should document. We then brainstormed this

===revised structure for the presentation of each project:===

(Summary paragraph, then:)

   1. Communication we set forth to improve
   2. Process -- how we realized and redirected things, over time
         1. History
         2. Communication and implementation ahas and turning points
   3. Findings/endpoints
         1. Concrete communication improvement(s), with examples and discussion
         2. Main communication realizations and implementation realizations
         3. Technological how-tos
         4. Things we’d expand/do differently



===Details on each to follow.===

(still testing out the categories by trying to use them to document the Parent Connector pilot.)

==Technical instructions aiding OneVille colleagues in the documentation==

===How to upload an image to the wiki:===

http://www.mediawiki.org/wiki/Help:Managing_files

from ^ but modified for our theme slightly:

Upload a file

   1. Prepare the file for upload. Make sure the file is exactly as you want it.
   2. In the sidebar, under “toolbox”, click “Special Pages.”
   3. On the Special Pages page, click "Upload File"
   4. Click “Browse” next to the “Source filename:” to locate the file on your computer (the name of the “browse” button depends on your web browser).
   5. Change the “Destination filename:” to something descriptive, if necessary.
   6. Fill in the “Summary,” if necessary.
   7. Click the “Upload file” button.


To use an image in another page, you treat it much the same as a wiki link:

[[Image:Cane Portrait Chevreuse.JPG | thumb | Female Mallard ]]
^ File name                                  |size to display | caption ]]