View source for Synapse stuff

This document outlines the tasks completed or attempted while working on ''Synapse'' - effectively akin to a research journal but as part of a production-intended project instead of a more specific study.

It was originally in a [https://docs.google.com/document/d/1HQUIQRbYrcEkHHdlrMjw0MLuEbF_aQz4IuN6_1zycxQ/edit google doc], but got moved here because setting up file uploads with a half-configured mediawiki install seemed easier than figuring out a pile of unlabelled buttons on said google doc.

== Task 1 - usable existing products ==
Different ways to collaboratively edit a document - generally you do want a platform for that instead of just emailing a thing around or whatever...

=== Wikis ===
* Shared document/page - open for editing, save changes, folks see changes
* Issues with edit conflicting
* Generally cannot easily have multiple copies of the same thing

==== Available potentially extendable products: ====
* [[wikipedia:MindTouch|MindTouch]]
* [[wikipedia:Confluence_(software)|Confluence]]
* [[wikipedia:MediaWiki|MediaWiki]]
* [[wikipedia:MoinMoin|MoinMoin]]
* [[wikipedia:TWiki|TWiki]]

=== Real-time editors ===
Probably want a real-time editor. Going with Google Drive for now for ease of setup. Will need something that can be integrated into the main app
* Edit live - automatically saves as one goes
* Folks can see each other type
* Danger of messing things up - change mind about changes, need to manually reload previous save; not possible if others editing at the same time

==== Available potentially extendable products: ====
* [[wikipedia:Etherpad|Etherpad]]
** Open source, free to use, has APIs, kind of messy front-end, would probably work with hacking.
* [[wikipedia:Google Drive|Google Drive]]
** Simple solution: link to a drive document, go there and use that
** Integratable? Check terms of use, APIs, might work perfectly.
* [[wikipedia:BeWeeVee|BeWeeVee]]
** Specifically created for integrating into other things, uses .Net/js, free for academic/NC use - would probably work fairly well without too much trouble.

== Task 2 - MVP demo ==
Work on script, record an audio...

Fiddled with it, and came up with something which fortunately wasn't used.

== Task 3 - questions ==
How can we get people signed up for our private beta?<br>
How can we run A/B testing for our demo?

=== Ways to reach people to bring them to the landing launchy page ===
* Search engine results - SEO is crap/nonexistent, so only was is through ads on results.
* Ads on sites through some campaign manager
* Social networking - linkedin, facebook, twitter
* Mail spam to potential users - cu mailing list, perhaps, others
* Word of mouth/getting people to share it themselves - reddit, clear share button on page, etc

Would probably want to do all of those, if possible. Emphasis on the last three because they cost less, and emphasis on the first one because it’s likely to find people the same way they’d be finding the product itself later once it does have a proper web presense, so if it would work later, it should work now.

How will this relate to google hangout? (commonly used by folks meeting with remote colleagues)

=== A/B testing: ===
Set up 1-2 more launch pages, Houman will make the actual landing thing in js, which should serve to scare off anyone like me, which is a good demographic to keep away from such things.

==== Prototypes ====
<gallery widths="200px" heights="150px">
File:Landing pitch thingy 1 wireframe.png|Simple centered video
File:Landing pitch thingy 2 wireframe.png|Series of steps leading to video
File:Landing pitch thingy 3 wireframe.png|Massive pile of crankiness dumped on a page
</gallery>

'''Prototype components:
* Logo/wordmark and slogan
* About
* (Feature highlight - shared notes, shared discussion, easy access later to organise archives) 
* Video(s)
* Sign up for private beta
* (Toggle between business/school) 

'''General flow of page:
# This thing!
# You want this thing!/You want this thing because!
# Now that you're interested, watch this for more info!
# Now sign up for this thing!


If that doesn't work it's hopeless. Or something is wrong, at any rate.

== Task 4 - prototypes ==
Mockups/prototypes to give folks a feel for the product...

=== Wireframes ===
General site layouts for academic version.

<gallery widths="180px" heights="130px">
File:Library wireframe.png|Library of courses/projects/whatever
File:Course wireframe.png|View of a specific course with session open
File:Course (instructor) wireframe.png|Instructor view of course
File:Notes wireframe.png|Notes page and recording app
</gallery>

=== Mockups ===
<gallery widths="260px" heights="160px">
File:Library mockup.png|Library of courses/projects/whatever
File:Library new mockup.png|Creating a new course session from the library
File:Course mockup.png|View of a specific course with session open
File:Course (instructor) mockup.png|Instructor view of course
File:Notes mockup.png|Notes page
</gallery>

== Task 5 - feasibility stuff ==
* How to parse a google doc (API results, etc, what would be pulled out)?__NOINDEX__
* Something about how to match up snippets of audio from different sources - algorithms, established methods, possible products, etc.

=== Parsing google doc ===
From [https://developers.google.com/drive/manage-downloads#downloading_google_documents developers.google.com]:

Download the content as described (probably as plain text since we're unlikely to care about images, text format, etc for this).

To parse, regex would probably be more than sufficient:
* Find sentences ending with questions
* Find hashtags
* Etc


Need to have a background process on the server or something to update - use the [https://developers.google.com/drive/v2/reference/changes/list changes feed]; check [https://developers.google.com/drive/manage-changes new changes](?) and reparse as needed.

=== Matching audio clips ===
The aim is to find overlap between multiple different recordings in order to combine disjoint recordings of the same meeting into a single, higher-quality file. 

We probably want to match the [[wikipedia:acoustic fingerprint|acoustic fingerprints]] of audio files as the first part of the process. Normally this sort of technology tends to be used for identifying music, but applications developed for that may work for this as well. In essence a fingerprint is a simplification of an audio file that focusses the perceptual characteristics (what a person would hear), and from this a basic comparison allowing for a certain range of variance between file fingerprints should serve our needs.

An existing open source solution such as [http://echoprint.me/ Echoprint] or [http://acoustid.org/server AcoustID] would probably be ideal if they would work. 

The problem is how to figure out what, if any such option, ''would'' actually work. 
* Recordings from different devices and places will contain considerably more variance and differing noise than reencodings of a song.
* Depending on how an implementation handles partial recordings, these may or may not even work to find overlap in the recordings.

Alternately generating our own 'fingerprints' for each snippet and then running them through a sloppy comparison possibly using the same methods as to generate the fingerprints in the first place - are they similar enough? - to match them up might be another, potentially more robust, option.

A paperly overview of some of the technology can be found here: [http://ucbmgm.googlecode.com/svn-history/r7/trunk/Documentos/Fingerprint-Cano.pdf Fingerprint-Cano.pdf]

=== More questions ===
* How can we add a sentence to a Google doc using the api? (to allow students to ask anonymous questions.)
*: ''Using a generic user to do the add (such that said user would be what shows up in the history instead of the student by name), the studen sends it the sentence which the generic user then adds using [https://developers.google.com/drive/v2/reference/revisions/patch patch]...
* How can we replace a word in a Google doc using the api? (why? we'll have templates for new created Google docs. Each template will have some placeholders (lecture title, instructor name) on top of the page which need to be replaced with real data from the corresponding lecture.)
*: ''Probably [https://developers.google.com/drive/v2/reference/revisions/patch patch] for this as well.
* Does the Google API allow to turn off the chat feature?
*: ''The documentation does not seem to cover the chat feature, at least not that was found. But either it shows up or not when the object is rendered and can be enabled/disabled or not, but the fastest way to check this would probably be to set up the thing itself. Even if chat is there without option when we don't want it, if all else fails we could probably make it go away on our end easily enough.
* Do Echoprint or AcoustID allow to find the exact overlapping points of two audio files or all they tell is if the fingerprints match up or not?
*: ''From what I could find there really aren't any (effectively advertised) solutions to what we want to do. Echoprint and AcoustID are intended to check if files are the same, but because they do so by matching fingerprints, these fingerprints could also be adapted to our purposes to check for partial overlap and sameness as well, thus providing the overlap points.

== Task 6 - usability and performance testing ==
Record four lectures - get volunteers to test the app while also recording it ourselves. 
* Multiple recordings increases pool of audio we have to work with and test future functionality.
* User testers can find problems with usability and also give insight into usage patterns and different use cases.

=== Things that come up ===
Taking pictures is kind of awkward.
* Picking up idling phone in general and holding it up is strange behaviour in a class.
* Phone likes to go to sleep; unlocking it takes time and can prevent actually getting the picture.
* Folks tended not to take pictures.

Class structures can present issues.
* Makes sense for lectures.
* Can make sense for presentations, but need a way to mark who is presenting, when presenters transition, etc.
** (There was a comment from Zach about how recording things is also useful for the presenters to improve their presentation skills)

What if speakers are on all sides of the room? Some quieter than others, talking in different directions... (haven't had a chance to listen to results yet so this is supposition, though)