Raindrop/Milestone Planning

Milestones

Planning area for different milestones. Milestones are a few weeks long and are named after trees. These milestones are for the "Hosted Goal" described more.

• Balsam
• Yew
• Douglas Fir
• Wattle (Completed, but not yet tagged)
• Maple (Completed)

Hosted Goal

Our Q2 goal for Raindrop is having a hosted Raindrop that is in restricted Alpha. The goal of this hosted version is to get feedback on the design. It will be a very experimental alpha, users should expect volatile behavior.

User reqs

• Only one gmail account and one twitter account allowed to be registered.
• Firefox or Webkit desktop browser only.
• English only.

Explicit non-goals

• Contact/relationship design will likely not be included. We probably need feedback/metrics from initial alpha before doing this.
• No tagging.
• No full text search. Push off to google if possible.
• If we have time, do reply/compose. If it has bugs or is not designed well then that is a problem. It will likely not be included. When the work is done, this is the order of importance:
  • Twitter stuff first.
  • Email, plain text
  • Email fancy style.
• No mobile, strictly desktop browser.
• Developer tools will not be improved, the goal is for design feedback. But we should invite developers so they can try it and get interested in the code.

High level pieces

• Web site describing the hosted offering. Point users to the blog for news. It will not take requests for invites. Rafael?
  • See Weave project for possible templates on privacy/terms of use etc...

• Invite system: Only do it by hand, we choose the people manually. Need to work with Gozer on how to tie invite links to people's accounts. Gozer?

• Invite link goes to the Account page. Restrict account setup to the invite email name.

• Account page. Needs the following: Bryan?
  • Security
  • Explanation
  • How to enter accounts.
  • Only Gmail, twitter one account each.
  • "We'll email you when its ready" - no waiting UI is needed.
  • Last N days of email only (explain that in explanation).

• Send email when the run-raindrop is done! Mark?
  • When run-raindrop runs, at the end of each run, check for a rd.last_sync schema.
  • If that schema does not exist, write it with the current time stamp and send email using the gmail credentials for the user. So the user ends up getting an email from themself.
  • If that schema already exists, update the timestamp and do not send email.

• User comes back, sees metrics participation screen (disable checkbox for this alpha?)

• Inflow experience (see below)

• Ability to delete an account via Account page. James/Mark/?

Inflow

• Move to bulk needs polish
• Archive/delete: needs testing/polish
• Attachments: clean up what we have, so it is easy for developers can add to it. Focus on this item when talking with developers as a way to jump into the code.
• Search/find on keyword data we have now. Use ubiquity-style interface.

Security

Still mostly unknown, need to work out soon since it impacts design.

Since we need to store some passwords, then do not worry about using OAuth for twitter, just to cut down on the work, but favor OAuth in the future.

Still may use OAuth support in couch to secure the specific requests to the server. Maybe we can use the OAuth token for a "master password" for use in encryption?

Operations

What pieces of software/servers are needed? Gozer to flesh out.

Random Notes

• Refresh / Send / Receive UI
• Be clear about security
  • read / write access of messages
  • how we store passwords
• Get Satisfaction Integration
  • How to Leave Feedback?
  • How to lookup a parson's CouchDB
    • Show unique ID on the GS view

• What Metrics will we need?
  • Attachments
    • Types
    • Count
    • From (tweet, email)
  • Mailing Lists
  • types of list - list-unsubscribe, list-id