General Description

JWA is trying to create a simple app that will allow iPhone and/or Android (if not both, then adding a second soon would be a priority) users to share media (image, audio, video) from their mobile devices with our archive. The same “share” would also have an option of sharing on Facebook, Twitter, etc.

Sharing could involve some significant behind the scenes setup: When installing the app, a person would need to give (or not give) fill in personal metadata (or it would be captured from the mobile device) about name, email address, twitter ID (we’d hide the latter, but would want it so that we could reach them), permission/copyright stuff (would the default for anything shared be a Creative Commons license, or “JWA use only”), along with permission (or not) to make any, some, all personal identifying information public, plus whether or not they agree to include available geolocation data as part of the metadata transmitted with the media. In short, on install:

• captures as much personal data already entered into the phone as possible, then ask for additional (limited, at the moment, to Name, email, twitter ID)
• ask what, if any, of that data can be transmitted with objects, and what, if any, of that data can be made public
• ask what geolocation data captured by the mobile device can be shared w/JWA as part of the media metadata
• ask what CC license (or none) is generally acceptable to the user (default: attribution, non-profit, okay to modify)

Code will be open-sourced—we want it to be possible for the developer and others to do further work with this initial seed and would be thrilled to see this spark additional innovation. We have kept this spec to be relatively vague so that we hear from a variety of approaches that meet these needs, and so that we don’t force inclusion of marginal features that would make development more difficult/expensive, or architecture that would make the application less useful to others. Proposals that use/adapt of existing open source standards and code will be preferred.

On the object-receiving end we would probably want to talk directly with a specific platform—in our case it would be Drupal 6 (conceivably Drupal 7)—and also conceivably to something like an AWS-based “S3 bucket” which we would reference with Drupal via CDN or other modules. Conceivably, “sharing” could be as simple as emailing the object to a server which processes it, along with a Web form to capture the additional metadata after the fact. In practice, that may not create a sufficiently compelling experience for people to actually use the app.

At the same time, the goal is to keep this as simple as possible, while also ensuring that we get meaningful data in a way that was fun/easy for the mobile users.

Budget

The budget is currently staked at $15k for work that would start in the Fall 2011 or later.

Of interest? Please feel free to share this message with anyone specific who you think might be interested in talking this out with us.

Possible configuration

(One proposed architecture)

App

• edit app configurations (allow location, edit name, email, copyright, etc)
• upload media files from device, enter media file metadata (categories, tags, which media sites to share with)

Server

• accept media files posted from devices
• read them for media metadata (associated with file) and other metadata supplied with the post
• deposit object to CDN (or wherever) and save content description in Drupal
• optionally post object and metadata to other n number of social media sites
• optionally save out a small xml file describing the object for future portability

Future Features

These are currently assumed to be relevant for a “version 2” of the app. If there is a simple way to address them in version 1, they would only enhance the ways in which we could use the app, and the likelihood of its success. These features focus on displaying items in JWA’s digital archive to app users:

• Feed showing what has recently been uploaded to JWA (RSS?) along with browsing tools
• Autodiscovery of items when someone is near a relevant geolocation (e.g., if you are near a location posted to “On the Map” you would be able to see what locations were pinpointed and browse the items to decide if you would like to visit.