Closed Bug 935681 Opened 11 years ago Closed 10 years ago

[B2G][Contacts] Suggested contact's longer last name doesn't overwrite original contact's shorter last name when merging two contacts

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v1.2 affected, b2g-v1.3T affected, b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected)

RESOLVED WONTFIX
2.1 S9 (21Nov)
Tracking Status
b2g-v1.2 --- affected
b2g-v1.3T --- affected
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.1 --- affected

People

(Reporter: nkhristoforov, Assigned: jmcf)

References

Details

(Whiteboard: permafail [p=2])

Attachments

(3 files)

Attached file Logcat
When merging two contacts who have last names that differ in length, the original contact's last name remains even when it is shorter than the suggested contact's last. It looks like the original contact's last name will be preserved when merging because when the original contact's last name is longer than the suggested contact's last name, then the longer last name remains.

Repro Steps:
1) Updated Buri to Build ID: 20131103004003
2) Select the Contacts app.
3) Create a contact with first name as Maria, last name as Sand, and phone number as 123.
4) Create another contact with first name as Maria, last name as Sandler, and phone number as 123.
5) Select the "X" button when "Duplicates Found" screen appears.
6) In the Contacts list, select Maria Sand.
7) Select "Find duplicate contacts" under "Organize Contacts."
8) When "Merge duplicates" screen appears, select "Merge with 1 contact."
9) Verify that "Maria Sand" is the contact that remains.

Actual:
The shorter last name is not overwritten by the longer last name.

Expected:
The longer last name would overwrite the shorter last name.

Environmental Variables
Device: Buri v 1.2 COM RIL
Build ID: 20131103004003
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/eec4da1b27eb
Gaia: cb981e2f47bc644b4d178d54378c3676c946facf
Platform Version: 26.0
RIL Version: 01.01.00.019.276 
Firmware Version: 20131015

Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/cases/?filter-id=9835#caseversion-id-81241
See attached: Logcat and screenshots
Attached image Screenshot after merge
The duplicate merging functionality was not present in 1.1.
This sounds like wrong behavior for a 1.2 feature - we're setting the last name incorrectly here, which is likely to confuse users unexpectedly when they try to use the feature.
blocking-b2g: --- → koi?
Stephany said to flag UX for input on the correct behaviour here; they can make the blocker decision.
Flags: needinfo?(firefoxos-ux-bugzilla)
Re-reading this bug again after seeing comment 5 - I'm really confused by the expected & actual behavior here. Please rewrite the expected & actual behavior in the context of the STR you used to reproduce with the Maria context.
Flags: needinfo?(nkhristoforov)
Actual:
After merging, the name that remains is Maria Sand.

Expected:
After merging, the name that would remain is Maria Sandler.
Flags: needinfo?(nkhristoforov)
Oh - that's the opposite of what I thought the bug was implying. In that case, I actually think the actual behavior is the correct behavior - the user has selected that Maria Sand is the confirmed dupe, which means they are expecting the existing contact's name to be retained. I'll wait for UX to comment, but I'm pulling the koi? until we figure out the right behavior here.
blocking-b2g: koi? → ---
(In reply to Jason Smith [:jsmith] from comment #8)
> Oh - that's the opposite of what I thought the bug was implying. In that
> case, I actually think the actual behavior is the correct behavior - the
> user has selected that Maria Sand is the confirmed dupe, which means they
> are expecting the existing contact's name to be retained. I'll wait for UX
> to comment, but I'm pulling the koi? until we figure out the right behavior
> here.

Oh wait - I misinterpreted the bug again. In this case, the user has created two contacts - Maria Sand & Maria Sandler. The user has tried to find duplicates from the Maria Sand context to find Maria Sandler as a duplicate & decided to merge the two together.

Hmm...thinking about this more, the UX in general here with the merging is confusing. Do we need more fine grained control when certain important attributes conflict (e.g. last name)?
Flagging Ayman, as it does seem the UI could be improved here. It's not at all clear to me, in this context, which name will be retained after the merge (in advance of my actually doing the merge): Will Maria Sand become Sandler or vice versa? I know I can probably edit a contact name post-merge, but I'd still like to know what exactly is going to happen.

The label of "merge" doesn't clearly communicate to me what is going to happen. Is there any way we could show the user a sort of preview ("your new contact will look like this"), and then allow them to either edit or approve that preview before committing a merge/de-dupe to contacts?
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(aymanmaat)
For the first pass at designing the Active Merge Contact functionality we made a pragmatic call that the contact from which the ‘Find duplicate contacts’ facility was launched would be king. This being that the user is more likely to want to merge contacts into the contact selected, than merge the contact selected into contacts that are found. Therefore in terms of its names fields, these in the contact from which the ‘Find duplicate contacts’ facility was launched (provided they were not null) would not be overwritten by content in the contacts that are being merged into it.

This behaviour equalises that of our benchmarks.

What is actually required as a matter of urgency to improve the merge facility is not a preview or dialogue to handle different names, its a facility to ‘undo’ merging thus evolving merging into linking. We should have been doing this in V1.3, but DSDS pushed it out. We should put our resources here as a priority because recovering from an undesirable merge at the moment is impossible within the app... and thats a huge usability issue and puts us behind our benchmarks.

Focusing back to the issue of name conflicts. I believe that in the background, upon merge, we do not discard the names that are not displayed. This is what i asked our developers to do. We should be retaining them hidden so that, post merge (or link should i say), we have the possibility to allow the users to customise the content of the name fields with whatever unique values have been found during merging. 

I would advise though, that in order to implement such a feature we would require indication in the interface that there are name options available. The UX of the interface of the Contact Detail Card and Contact Detail Card in Edit Mode is, frankly, suboptimal and layering more items into there is probably not going to help.

I would propose therefore that we implement undo merging first, then when we redesign the Contact Detail Card and Contact Detail Card in Edit Mode (and i am on my knees at this point praying for the day when this is going to happen) ..we also implement this ‘select name’ feature, because remember, what we have at the moment regarding contacts names upon merge equalises that of our benchmarks.
Flags: needinfo?(aymanmaat)
Flagging Jacqueline to ensure she's aware of this proposal, agrees, and so on. Thanks for the great summary, Ayman. Appreciate it.

Ayman's proposed approach seems reasonable and doable to me. I agree that we should begin with undo merge and verify that we are not discarding the names that are not displayed. 

I also agree that the UI should indicate available name options, and that we need to deal with Contact Edit mode, which is raising its ugly little head on some NFC and BT UI issues as well.

Let's see what we can do to get this into the Comms backlog going forward. Good topic for the upcoming Comms work week in Taipei in late Nov. perhaps?
Flags: needinfo?(jsavory)
I certainly agree with Ayman's proposal, we should focus upon undoing the merge and then focus on fixing the contact edit screen as it could definitely use a refresh. 

Also, I agree that the merging contacts screen is quite unclear as to which information is dominant, I'm thinking that this could be a minimal change that could really clarify this information for the user.
Flags: needinfo?(jsavory)
Issue occurs on 1.4 buri build

Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140307040203
Gaia: 04eb7996543f114133d1367f834a4d88b68c60ac
Gecko: b0e7f63c2138
Version: 30.0a1
Firmware Version: V1.2-device.cfg
Whiteboard: burirun3 → burirun3, burirun1.4-1
Just to clarify, this issue does occur for the first name as well, not the last name alone (i.e. Christofer Smith was merged with Chris Smith, and the first name Chris was kept as the final).
Whiteboard: burirun3, burirun1.4-1 → burirun3, burirun1.4-1, burirun1.4-2
Whiteboard: burirun3, burirun1.4-1, burirun1.4-2 → permafail
This issue also occurs on the Open_C v1.4 MOZ ril.

Environmental Variables:
Device: Open_C v1.4 MOZ ril
BuildID: 20140505000201
Gaia: fccb15d6940db51615545574877a62d69406b1c2
Gecko: bf937fbec8c1
Version: 30.0
Firmware Version: v1.2-device.cfg

-If "Chris Smith" exists in the contacts, and "Christofer Smith" is created and merged with the suggested existing "Chris Smith", "Christofer Smith" overwrites the original and becomes the new name.

-If "Christofer Smith" exists in the contacts, and "Chris Smith" is created and merged with the suggested existing "Christofer Smith", "Chris Smith" overwrites the original and becomes the new name.

The newly created entry seems to overwrite the original, regardless of which is longer.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Assignee: nobody → jmcf
Target Milestone: --- → 2.1 S8 (7Nov)
Whiteboard: permafail → permafail [p=2]
Target Milestone: 2.1 S8 (7Nov) → 2.1 S9 (21Nov)
I've been reviewing thoroughly the issue and the comments made by Ayman.In essence the current behavior is ok but we are still missing a functionality to undo contact merge. Once we have it it can be easy for the user to obtain whatever result she wants. 

So I'm closing this bug as won't fix, as undo merge is something we are working towards it as part of the upcoming contacts data refactoring we are aimed to.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(dharris)
Pulling the 2.2 affected tag based on comment 17. This bug has already been closed as WONTFIX
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(dharris)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: