Raindrop/Milestone Planning: Difference between revisions

Raindrop/Milestone Planning (view source)

Revision as of 22:09, 18 January 2010

339 bytes removed , 18 January 2010

no edit summary

Jrburke

109

edits

@@ Line 10: / Line 10: @@
 * [[Raindrop/Milestone/Maple|Maple]] (Completed)
-== Backlog ==
+== 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.
-This is a sketchpad area where we can list out things we want to do that have not been slotted into a milestone yet.
+=== User reqs ===
+* Only one gmail account and one twitter account allowed to be registered.
+* Firefox or Webkit desktop browser only.
+* English only.
-'''Do not''' assume anything listed here will actually be done. It is more of a planning area, and the list will change drastically over time.
+=== 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.
-When choosing items for the next milestone, focus on items that will help Raindrop develop a significant market presence. Right now that means getting Raindrop to run on a hosted service in the cloud.
+=== High level pieces ===
-Grouping milestone work into the following three goals will get us there:
+* Web site describing the hosted offering. Point users to the blog for news. It will not take requests for invites.
+** See Weave project for possible templates on privacy/terms of use etc...
-* '''Emotional feeling of better organization''': Make sure the experience gives the user a sense of relief via easy setup and automatic filtering/grouping done for the user.
+* 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.
-* '''Dog Food''': The inflow app should be usable by all the team members on a day-to-day basis.
+* Invite link goes to the Account page. Restrict account setup to the invite email name.
-* '''Cloud enabled''': Raindrop is runnable in the cloud, with clear instructions on how to set it up to make it secure. The goal may or may not be to host Raindrop on Mozilla Messaging services, but at the very least make it easy for users or ISPs to run Raindrop on their own servers.
-The following section is where we can group tasks that follow under one of the three goals above. For each milestone, we should pick items from the current goal.
+- Account page. Needs the following:
+** 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!
-Codes:
+* User comes back, sees metrics participation screen (disable checkbox for this alpha?)
-* BE: Back End (platform)
-* FE: Front End (platform)
-=== Emotional feeling of better organization ===
+* Inflow experience (see below)
-''This targets a read-only emphasis of your communications, organized.''
-; goal : Automatically organized and visualize the person's email and twitter messages such that viewing Raindrop when coming from GMail or other mail clients is a relieving experience.  People should feel like they've stepped into the BMW of email clients where the lines are smooth and connected and lots of innovated design has been integrated into an excellent experience.
+* Ability to delete an account via Account page.
-* Specific group widgets for Twitter and Mailing Lists
+=== Inflow ===
-* Ability to deal with people or messages you "Don't want in my inflow"
+* Move to bulk needs polish
-* Organizing and tracking contacts and relationships
+* Archive/delete: needs testing/polish
-* Organizing Mailing Lists, and Broadcast Messages out of the inflow
+* 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.
-* Layout of Conversations with Attachments inline and consumable
+* Search/find on keyword data we have now. Use ubiquity-style interface.
-* Search / Find of existing mail, folders, tags, and people
-=== Dog Food ===
-* reply
-* archive/delete
-* new message
-* FE: Developer tools
-** Server API inspector
-** In-page code inspector: show widgets and their properties.
-** Improved extension editor that allows HTML/CSS/JS.
-* FE: implement JSDoc comments to allow for API documentation.
-* Implement twitter sending/more twitter APIs so people can make their own twitter web app?
-* [http://trac.mozillamessaging.com/raindrop/ticket/71 Stronger guarantees on message authenticity?]
-=== Cloud Enabled ===
+=== Security ===
-* New web-based account setup based on the security model, ideally something suitable for a hosted environment, but not required.
+Still mostly unknown, need to work out soon since it impacts design.
-* Security: investigate CouchDB OAuth to restrict access to the couch to only authorized users.
-* Security: set up secure storage and use of credentials to message service providers.
+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.
-* Cloud images for Raindrop: Amazon image, others?
-* Extension sharing model.
+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?
-* More mobile work? A code prototype?
+=== Operations ===
+What pieces of software/servers are needed? Gozer to flesh out.