Labs/Ubiquity/Usability/Usability Testing/Sync
Tagging video is a major PITA. Syncing iMovie (for clip reels), Viddler, podcast (chaptering), the spreadsheet, and various tables in MediaWiki redoing the same tedious work 4 times every time a tag is added/updated/deleted.
One solution is to upload everything to a MetaVid wiki. That way all comments are made where the video can be edited as well. However, running a video hosting service isn't exactly cheap or easy.
To automate the process of sycning the tag data I spec'd out two options.
- A simple desktop application that converts the tag data files which are then used to manually update the various data sources.
- A GAE app that automatically syncs the various sources, versioning problems makes this solution harder -but not impossible.
I want to proceed in such a way that if the server version dies an early death or a MetaVid wiki or other such video editing wiki appears we will start by creating the scripts that actually convert the data. That way we can use the command line to run scripts and resuse them in GAE or in a desktop application.
First off is getting a script that will convert the weird iMove Data plist format (bottom of the page) into a CVS or XML file.
Once in XML it should be easy to convert it into a podcast XML file, which can then be manually be combined with Chaptertool or, if you are feeling awesome, combine it with the m4a movie file on it's own.
After that, the next most important step is pushing that data onto Viddler via their API.
And finally we need a script to create a CVS spreadsheet. It is then manually added to a special Google Docs spreadsheet which analyzes the numbers from all the tests. This also provides an easy interface for changing tags across all movies/sheets at once (i.e. merging similar tags like "wiki:confusing" and "confused by wiki").
Modularity
added by Kris Walker (kixx) 10.3.2009
One of the first things I thought to myself when reviewing this spec was "Wow, that's a lot of code to basically accomplish one task." But, it's worth noting that data/format/protocol conversion tools are always useful in other contexts. (Just look at the number of libraries that do various forms of protocol implementation or format conversion)
My "overlay" onto this spec is that it should be implemented by creating a UI that "pipes" data between code modules that implement the various data formats and remote service APIs. So far, that's not any different, but if the emphasis is put on "piping" between modules, then we begin to see similarities to the Unix design. The ability to pipe output to input between any number of commands (or code modules) makes the Unix command line very powerful.
By carefully crafting programmatic interfaces to the modules that implement each data format and HTTP service, this project could end up rolling out some code modules that could be integrated into other client UI (like Ubiquity) in some really useful ways.
I'll bet that you could list at least 10 things you could do with modules like these in 30 seconds using an extension or Ubiquity.
So, as usual, writing code for one use case might be the easiest thing to do, but I think the potential for extensibility should take center stage.
- Implement in JavaScript and XPCOM components to keep portability.
- Construct independent (uncoupled) modules to implement each data format and remote service API
- Pipe data between modules using native JavaScript structures.
- Let a loosely stardardized API emerge from the module interfaces.
