Raindrop/Milestone/Maple: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with 'Maple is the first post-reveal milestone. End date is Nov 10, 2009. Trying to pick Tuesdays since they correspond with a weekly call. Current list of items being considered is b…')
 
No edit summary
 
(6 intermediate revisions by 2 users not shown)
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:


== Big ==
== 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.


* 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:
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.
** Bryan and Andy post to design blog about the design.
** James to tag the tree as 0.1, update wiki page to point to the tag if people want to see the code that was in the reveal, and mention different things are happening on the trunk.
** James to clean up the inflow and client/lib to be optimized for iteration 3. Inflow #1 and inflowgrid will be deleted, and the widgets will be cleaned up to fit iteration 3's


* 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.
== Mobile Design ==
** Bryan to start wiki page listing out the combinations.
Andy posted [http://mozillalabs.com/raindrop/2009/11/12/thinking-mobile/ an article] about a possible mobile design.
** 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.
== Conversation Types ==
** James to clean up JS code, make sure the low level and high level ones are distinct. Discuss with Mark.
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.
** 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.
* 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?
== Web API ==
** Andy/Bryan to consider design and language of the extension asking for permission, model it on Test Pilot.
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.
** TBD to do metrics extension.
** Mark to do any setup for a metrics DB?


 
== Metrics Collection ==
=== Community Involvement Opportunities ===
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.
 
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.
** 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.

Latest revision as of 00:58, 14 November 2009

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.

The following improvements were made during Maple:

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.

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.

Mobile Design

Andy posted an article about a possible mobile design.

Conversation Types

The combinations of message types has been documented on the Conversation Types page. This will guide the layout of conversation widgets in the code.

Web API

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 Web APIs page.

Metrics Collection

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 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.

Retrieved from "https://wiki.allizom.org/index.php?title=Raindrop/Milestone/Maple&oldid=183104"