[Contacts] Estimate current haida status in contacts

RESOLVED FIXED in 2.1 S6 (10oct)

Status

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: arcturus, Assigned: arcturus)

Tracking

unspecified
2.1 S6 (10oct)
x86
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [p=3])

In bug 1022646 we started working on haida, but work has been stop.

We need to estimate current work, and see what things are missing to plan haida for next sprints.
Blocks: 1022646
No longer blocks: 1022646
Whiteboard: [p=3]
Target Milestone: --- → 2.1 S5 (26sep)
Blocks: 1022646
Assignee: nobody → francisco
Here I manage to put some ideas separating the form to a document:

=====================
Contacts dependencies
=====================


Navigational changes
====================

Contacts.cancel
  - Cancel edition and transition to the contacts list

Contacts.navigation.home
  - Go back to the list after a contact delete. Replaceable by
    a message

Contacts.goBack
  - Navigation to go back after we pick the another contact for
    merging. This saves and go back. Navigation action replaceable
    by message


Utility functions
=================

Contacts.updatePhoto
  - Setup a new photo and propagate to the rest of the app
    the new photo. Can be extracted to an utility method.
    NOT A MESSAGE TO OTHER PARTS -> ISOLATED

Contacts.goToSelectTag
  - Just used in the form, we can move it outside Contacts.js

Contacts.isEmpty
  - Used to check for contacts empty fields. Used in form and
    detail. We can move this to an utility class

contacts.NFC
  - Stop listening for NFC events, we could lazy load the NFC
    class.

Contacts.confirmDialog
  - For confirmation when deleting. Lazy load the dialog html
    in theory could be extracted to an utility library


Interaction with other parts of the application
===============================================

contacts.Search
  - When deleting a contact we need to invalidate the search.
    We can replace this with a message.

Contacts.setCurrent
  - Used to notify contacts what's the current contact object selected.
    We can replace this with a message.



Deep integration (matching and mergin)
======================================

Contacts.extServices
  - Shows duplicated contacts. Check if we can lazyload or we
    need to load from scracth.

contacts.Merger
  - Right now is lazy loaded, shouldn't be a problem

contacts.Matcher
  - Lazy loaded and executed, shouldn't be a problem.


Facebook
========
Makes uses of all the facebook set of functions and postmessaages.
Wich means that we need to load the fb frames as well.


Activities
==========
form.js handles 1 activity, 'new' we dont need to load the whole activity handler,
right now we use just
ActivityHandler.currentlyHandling
ActivityHandler.postNewSuccess
We could have an activity handler just for the form. Also we need to setup the
message handler.


====
HTML
====
- We need to try to get a bare minimun html for form.html. Use the element form.html
  as content, it doesnt make sense to lazy load just that section.


================
Other objectives
================
- Avoid to load contacts.js
Latest work can be found here:

https://github.com/michalbe/gaia/compare/Bug946750-form-temp


Key points that I think that are important:

- Create a new document form.html
- Load the new document into the current architecture via navigation shim.
- Communication between documents via broadcast messenger shim.

Things we need to worry about:
- We have already several iframes that will be reused, and can be triggered from both documents. FB (iframes). This was causing some problems on undesired executions.

- We should trim the form.html to ideally contain just the minimun, current solution also loads contact.js
Otherwise our memory footprint will grow like crazy.

- Don't share all the code, we have activities that are a lot of code. Let's just put the specific part that each document will need.
Target Milestone: 2.1 S5 (26sep) → 2.1 S6 (10oct)
I would suggest to land following the plan:

- Integrate in the current branch thew new form design.
- Clean html for the form.html
- Fix problems with frames interactions (merge, fb, etc.)
- Work on form startup (initialization with data)

I would suggest continue working on a separate branch and perform constant (every single day) rebase from master.

The task could be splitted as exposed above, and this is my estimation for them:

- Integrate the current branch (last work) with latest master: 4 points (16 hours)
- Clean html for the form.html: 2 points (8 hours)
- Fix problems with frames interactions: 3 points (12 hours)
- Work on form startup: 4 points (16 hours)

Definitely to be splitted in more than one sprint.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Folks,

I would need you to validate my estimations and work to be done, based on the comments on this bug.

Thanks!
Flags: needinfo?(sergi.mansilla)
Flags: needinfo?(jmcf)

Comment 5

4 years ago
hi Francisco

I see your estimations rather optimistic. This task has been deviating for a long time so we would need to be conservative with our estimations

thanks!
Flags: needinfo?(jmcf)
(In reply to Jose Manuel Cantera from comment #5)
> hi Francisco
> 
> I see your estimations rather optimistic. This task has been deviating for a
> long time so we would need to be conservative with our estimations
> 
> thanks!

Thanks for the feedback Jose, any proposal?
Flags: needinfo?(jmcf)

Comment 7

4 years ago
(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #6)
> (In reply to Jose Manuel Cantera from comment #5)
> > hi Francisco
> > 
> > I see your estimations rather optimistic. This task has been deviating for a
> > long time so we would need to be conservative with our estimations
> > 
> > thanks!
> 
> Thanks for the feedback Jose, any proposal?

I would suggest we double those estimations, WDYT?
Flags: needinfo?(jmcf)
I agree with doubling the estimeation.
Flags: needinfo?(sergi.mansilla)
You need to log in before you can comment on or make changes to this bug.