109
edits
Raindrop/Milestone Planning: Difference between revisions
no edit summary
No edit summary |
|||
| Line 13: | Line 13: | ||
== Hosted Goal == | == 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. | 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. | ||
On the path to get to a restricted alpha, we need to bootstrap to a dogfoodable, hosted version so we can start to analyze cost and get the UI polished as we use it daily for our own needs. | |||
To help contain the cost, refine the mission for the Raindrop product: | |||
Inflow's target experience helps users process new conversations and people. To that end, to contain costs and help performance, we only will do last 2 weeks worth of messages. | |||
Later we could store more messages, but that would increase the cost for the user. More study will be done after we have more experience with the 2 week limit. | |||
Immediate primary goals: reduce the big risks of hosting Raindrop: | |||
* Platform Costs (performance/hosting costs) | |||
* User Experience | |||
How to get there for both items? | |||
* Bootstrap hosted version for dogfooding by team (See [[Raindrop/Milestone/Sequoia|Sequoia]]) | |||
* Set performance goals | |||
* Measure current version | |||
* Build in feedback loop | |||
* Use measured data to do changes | |||
=== Performance Goals === | |||
==== Platform ==== | |||
* Load initial UI under 2 seconds | |||
* Each API call under 2 seconds | |||
* Expand group widget, 1 second | |||
* View conversations for a group (like mailing lists) 2 seconds | |||
* Time to process a message after fetching from message provider? | |||
* Come up with a cost per user per month target. May need real data first. | |||
==== User Experience ==== | |||
* Sense of relief? | |||
* Be able to use on daily basis? | |||
* Ease of processing new mail? | |||
=== Measure Current Version === | |||
==== Platform ==== | |||
* Measure cost of running Jean's account '''Gozer''' | |||
* Disable/enable some features/extensions to see the effect on cost '''Mark to expand?''' | |||
==== User Experience ==== | |||
* List out the broken pieces, things that must be working to get outside people to try limited experience test. '''Bryan and Andy''' | |||
=== Feedback Loop === | |||
==== Platform ==== | |||
* As we do changes, how do we measure increase in performance/affect on per user cost? '''Mark/Gozer''' | |||
** Why not build a simple high level usage plan (initial load, click n messages, delete something, etc) and translate that to a list of URLs that would need to be fetched. From that, building a simple, automated measurment of how much time it takes to complete that could for a nice baseline number to follow around. | |||
** Also, it might be time to start thinking about Continuous Integration so we can track changes back to code changes. | |||
==== User Experience ==== | |||
* Identify up to 10 people for initial feedback test? | |||
* How to to set the tone for the feedback? | |||
* How to collect the feedback? | |||
* How to feed new "tests" to the initial users? | |||
=== Changes Based on Measurements === | |||
This section is likely to be filled in later after we have more data, maybe as part of another milestone. Some initial thoughts from Bryan (but need real data to confirm effectiveness): | |||
* From Bryan: put summary docs in a different DB, and use custom views on it, to replace the API layer. Benefits, easier to play with for developer writing front end extensions, may help performance? | |||
* Reduce the flexibility of the backend schemas. | |||
=== User reqs === | === User reqs === | ||