|
|
| Line 1: |
Line 1: |
| Maple is the first post-reveal milestone. End date is Nov 10, 2009. Trying to pick Tuesdays since they correspond with a weekly call. | | Maple started around Oct 26, 2009 and finished on Nov 12, 2009. We did not create an explicit tag for Maple since the code is very much still in flux and not usable for much at the moment. |
|
| |
|
| Current list of items being considered is below. We should focus on one to two bigger items and some smaller clean-up items.
| | The following improvements were made during Maple: |
|
| |
|
| View [http://trac.mozillamessaging.com/raindrop/query?status=new&status=assigned&status=reopened&milestone=Maple&order=priority Maple Trac tickets]
| | == Inflow Design #3 == |
| | With Design #3, it was decided to strip down the interface and build up piece by piece, as the designers work out each piece. For Maple this means just the basic layout of conversations/messages was established: group/direct conversations taking two column widths and one column width of broadcast message widgets. This basic layout was implemented in the code. |
|
| |
|
| == Big ==
| | The basic conversation layout is the only thing that functions right now. There is no navigation to mailing lists, folders, contacts and no more Quick Compose. The Reply functionality is also broken. Each of those things will be built up over the next few milestones as each piece is designed. |
|
| |
|
| *'''(DONE)'''Inflow Design #3: Bryan and Andy have worked out the start of iteration 3, which is a combination of inflow #1 and inflowgrid. Basically, use inflow #1 for personal conversations, but use grid layout to the right of it to show grouped conversations. Specific tasks:
| | == Conversation Types == |
| **<strike>Bryan and Andy posted to design blog about the design</strike>. They continue to iterate.
| | The combinations of message types has been documented on the [[Raindrop/Conversation_Types|Conversation Types]] page. This will guide the layout of conversation widgets in the code. |
| ***[http://blogs.mozillamessaging.com/raindropdesign/2009/10/26/03-third-iteration/ 03 Third Iteration]
| |
| **<strike>James tagged the tree as 0.1, updated wiki page to point to the tag if people want to see the code that was in the reveal, and mentioned different things are happening on the trunk.</strike>
| |
| **<strike>James to clean up the inflow and client/lib to be optimized for iteration 3. Inflow #1 and inflowgrid will be deleted</strike>, and the widgets will be cleaned up to fit iteration 3's needs.
| |
|
| |
|
| *Define set of message combinations we can see (direct message turned to a group message, group message forwarded to an individual, different types of notifications, newsletters vs. listserv mail). Then seed Jean's account with that info.
| | == Web API == |
| **'''(DONE)'''Bryan to start wiki page listing out the combinations [[http://trac.mozillamessaging.com/raindrop/ticket/67 raindrop 67]].
| | The server-side web API for the inflow app was started. It is implemented in Python and called via a couch external. It contains the API for fetching conversations by conversation type. Other APIs around contacts and identities are not implemented yet. The JavaScript code was updated to use the new server API for conversations. The API is being documented on the [[Raindrop/WebApis| Web APIs]] page. |
| **''(IN PROGRESS)''TBD populates Jean's accounts with the combinations.
| |
|
| |
|
| *Web API work. Start working on better web APIs. Take the opportunity with Iteration #3 to clean up the old JS code used in the client. The JS code is already split into a higher level app API and a lower level, more couch-based API, make the distinction clear in the JS code and use it to inform a server-side API.
| | == Metrics Collection == |
| **'''(DONE)'''James to clean up JS code, make sure the low level and high level ones are distinct. Discuss with Mark. [http://hg.mozilla.org/labs/raindrop/rev/2c602dcd9dcb switch the front end to using the REST API]
| | The inflow app now has an extension that tells the user metrics are being collected. The user has the option to opt out, and even after dismissing the metrics UI blurb, there is a metrics link at the bottom of the page that allows the user to get more information about the metrics at any time. The [[Raindrop/MetricsInfo|Metrics Info]] page has more details on the metrics. Right now only one metric related to the number of broadcast domains is stored in the local couchdb, but that information is not sent to a central server. |
| **'''(DONE)'''Mark to build up up some primitives to have some Python code run in an external so we can try porting the JS APIs to run on the server. Basic services needed: wrappers for doing megaview calls, fetching documents, merging results together. [http://hg.mozilla.org/labs/raindrop/rev/1c1a36e6cc3f server API checkin]
| |
| *'''(DONE)'''Mark and James to split up coding tasks on the Python server stuff once the basic API is designed.
| |
| | |
| *Start work on metrics collection: this is two parts, an extension asking permission to collect metrics, and then logging the metrics somewhere. Initial pass, maybe just log the metrics in a separate couchdb database and consider using replication back to a common server?
| |
| **''(IN PROGRESS)''Andy/Bryan to consider design and language of the extension asking for permission, model it on Test Pilot.
| |
| **'''(DONE)''' metrics extension that informs the user via a notice on first run of raindrop, and logs a simple metric to the user's local raindrop-metrics couchdb database. More info at [[Raindrop/MetricsInfo|Metrics Info]].
| |
| <br>
| |
| | |
| === Community Involvement Opportunities ===
| |
| | |
| These are things that can benefit from community involvement. You can help out with the following!
| |
| | |
| *Explore some JavaScript server side options. At this point we want to try to avoid an option that requires Java, but just to cut down on our code dependencies. It may be considered later if a suitable solution is not found. Two options stand out:
| |
| **Explore couchJS. Can it be used for our purposes? Need network and probably restricted file access to load some JS library code. Mark has done a pass on this, and we need fixes in CouchDB for curl support in couchjs.
| |
| **Explore [http://www.toolness.com/wp/?p=678 Pydermonkey]. Would be nice particularly if it has access to Python libraries, but at a minimum need network and restricted file access.
| |
| | |
| *Security: Please see the [[Raindrop/Security|Security wiki page]] for more information. Anything we can do to start securing user data better and securing the couch is appreciated.
| |
| | |
| == Small ==
| |
| | |
| * Trac tickets that are [http://trac.mozillamessaging.com/raindrop/report/3 post-reveal]. Move anything you want to do to the Maple milestone.
| |