Raindrop/Milestone/Maple: Difference between revisions

Jump to navigation Jump to search
Line 7: Line 7:
== Big  ==
== Big  ==


*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:  
*'''(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:  
**<strike>Bryan and Andy posted to design blog about the design</strike>. They continue to iterate.  
**<strike>Bryan and Andy posted to design blog about the design</strike>. They continue to iterate.  
***[http://blogs.mozillamessaging.com/raindropdesign/2009/10/26/03-third-iteration/ 03 Third Iteration]  
***[http://blogs.mozillamessaging.com/raindropdesign/2009/10/26/03-third-iteration/ 03 Third Iteration]  
Line 14: Line 14:


*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.  
*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.  
**Bryan to start wiki page listing out the combinations [[http://trac.mozillamessaging.com/raindrop/ticket/67 raindrop 67]].  
**'''(DONE)'''Bryan to start wiki page listing out the combinations [[http://trac.mozillamessaging.com/raindrop/ticket/67 raindrop 67]].  
**TBD populates Jean's accounts with the combinations.
**''(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.  
*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.  
**James to clean up JS code, make sure the low level and high level ones are distinct. Discuss with Mark.  
**'''(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]
**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.  
**'''(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]
*Mark and James to split up coding tasks on the Python server stuff once the basic API is designed.
*'''(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)''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?  
**Andy/Bryan to consider design and language of the extension asking for permission, model it on Test Pilot.  
**''(IN PROGRESS)''Andy/Bryan to consider design and language of the extension asking for permission, model it on Test Pilot.  
**TBD to do metrics extension.  
**TBD to do metrics extension.  
**Mark to do any setup for a metrics DB?
**Mark to do any setup for a metrics DB?
Confirmed users
1,059

edits

Navigation menu