995299 - [Tarako]Contacts App Add contact is too long

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Contacts, defect, P3)

Description

[Ravi Dandu]

Attachment: Tarako_Performance_TPE-v0.1.pdf

Tarako testing has shows the Add Contacts to be 2.5 seconds. This needs to be reduced to 1 second.
From a User Experience point of view:
1) Button response should be 140 ms for human cause/effect timelines
2) "Contact Added" response whould be within 1s for human perception of progress timeline

Attached are the Tarako test results

Comment 1

[Ross Kuhlman ([e-mail])]

Contacts app feels much faster now. New contacts typically save in <1 second.

v1.3T Environmental Variables:
Device: Tarako v1.3T MOZ
BuildID: 20140418014001
Gaia: f0872318d46781bb59d0a13a2e1fffb115b8ca2b
Gecko: 32bb713e6d0d
Version: 28.1
Firmware Version: sp6821a-4-18

Comment 2

[:Eli Perelman]

Attachment: Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/18654

In addition to the recent performance improvements, this PR implements the saving of contacts using an Async UI. This returns the user to the contacts home immediately after saving. If there are any duplicates detected after the save, the window is displayed promptly once detected. If it is a clean save, then the UI feels much snappier.

Comment 3

[Jose Manuel Cantera]

Comment on attachment 8412083 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/18654

r- 

the proposed changes breaks the UX in two senses:

a/ the transition to hide the contacts add sheet when the contact is saved ends up stopping 
b/ it is not good to hide the add contact sheet and then open up the duplicates found screen. It looks weird

nonetheless, thanks for the attempt

Comment 4

[:Eli Perelman]

Hey Jose,

As far as [a/] is concerned, I never had that issue on my device, but I can certainly check that out to see what is happening.

As far as [b/] is concerned, this interaction is based on our new UX approaches with adopting Async UI interactions to improve responsiveness and perceived performance of those interactions within our applications. You can read more about this approach at [1]. I'm going to ask for someone from UX to weigh in here as well, and then I'd like to reconsider the review of this patch.

Gordon, could you please speak on behalf of UX?

[1] https://developer.mozilla.org/en-US/Apps/Build/Performance/UI_Synchronicity

Comment 5

[Gordon Brander :gordonb]

Fwd Carrie, who currently drives Contacts UX.

Background:
On Tarako, the Contacts app takes 2.5 seconds to save a new contact. This is very slow (we need 1 second for cause-and-effect to be perceived). The reason it takes so long is that we wait for the contacts app to confirm the contact is saved and there is no duplicate.

There are 2 obvious ways we can avoid this:

1. Confirm input immediately. In the unusual case that a duplicate would be created, bring up duplicates dialog when it is detected.
2. Confirm input immediately. Don't try to de-duplicate (many Contacts features do without this feature entirely).

Comment 6

[Carrie Wang [New account: [e-mail]]]

Hi I wonder that without Async UI, it would get back to the added-contact detail page or go back to the Contact home directly? (Sorry I just took over Contact ownership but can't find the original spec at the moment) Because if we get back to Contact home directly, then users cannot check if their input is correct or not. I think this is not good UX.   

If the original implement is getting back to the Contact home, then I'd suggest adopting option 2 from comment 5. The duplication can be detected after implementing bug 907097. Thanks!

Comment 7

[:Eli Perelman]

Hey Carrie, the Async UI is implemented such that you are returned to the previous screen. So if you are adding a new contact and save, you are immediately returned to the Contact home list. If you are editing a contact, you would be returned to the contact details screen. That would make the implementation fall in line with needing to be done along with 907097.

Comment 8

[:Eli Perelman]

Attachment: 2014-05-12-11-41-47.png

In researching this bug a little further as well as 907097, I believe that this bug should not need to land along with 907097 in order to achieve the functionality that UX is looking for. We currently already have the ability to manually search for duplicate contacts and merge them available on each on contact detail screen (see screenshot attachment for visual).

It is my opinion that this bug should be allowed to land without needing bug 907097, which still lets the duplicate and merge flow happen manually as suggested by UX using the current functionality, and landing bug 907097 later as determined.

Carrie, can you please assess my statement and see if this is something you can accept? I am proposing landing the Async UI for Contacts, removing the merge flow from the current save operating, and having users manually do the detect and merge process from the contact detail screen.

Comment 9

[Carrie Wang [New account: [e-mail]]]

Hi Eli, 

Of course I can accept moving the dependency of bug 907097, but I've checked the behavior form 1.3 and found that the previous interaction is going back to the edited-contact details rather than going back to the contact list. I know having Async UI can increase the performance, but in this way, users can't check the edited content after the action and this could lead to some mistakes. Is this the only way we can deal with the issue? Thanks!

Comment 10

[:Eli Perelman]

Carrie, I'm having difficulty understanding which interaction you prefer for existing contacts:

1. After saving a contact, return to the home list of all contacts.
2. After saving a contact, return to the contact detail page for the given contact.

Please advise which you prefer and I can explain further.

Comment 11

[Carrie Wang [New account: [e-mail]]]

Hi Eli, 

The second one! Is it doable with Async UI? Thanks.

Comment 12

[:Eli Perelman]

Hey Carrie, yes, the second option is how I currently have it working. If you are editing a contact, you are returned to the contact details screen. If you are creating a new contact, you are returned to the contact list. Both of these work with the Async UI.

Comment 13

[Carrie Wang [New account: [e-mail]]]

Oh great! Looks like I misunderstood the interaction here (and I blame the jetleg). Then I'm fine with the implementation. Thanks a lot! :-)

Comment 14

[:Eli Perelman]

Thanks Carrie, I will get the patch rebased and reconsidered for landing.

Comment 15

[:Eli Perelman]

In experimenting with patches for this again, I cannot reliably get to the contacts list from the save new contact interaction without the keyboard reflowing contacts list when it slides away. A proposal in 970093 would alleviate this issue and let us use an Async UI without detriment from the keyboard.

Comment 16

[BMO Automation]

Firefox OS is not being worked on