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)
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)
People
(Reporter: nkhristoforov, Assigned: jmcf)
References
Details
(Whiteboard: permafail [p=2])
Attachments
(3 files)
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
Reporter | ||
Comment 1•11 years ago
|
||
Reporter | ||
Comment 2•11 years ago
|
||
Reporter | ||
Comment 3•11 years ago
|
||
The duplicate merging functionality was not present in 1.1.
status-b2g-v1.2:
--- → affected
Comment 4•11 years ago
|
||
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?
Comment 5•11 years ago
|
||
Stephany said to flag UX for input on the correct behaviour here; they can make the blocker decision.
Flags: needinfo?(firefoxos-ux-bugzilla)
Comment 6•11 years ago
|
||
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)
Reporter | ||
Comment 7•11 years ago
|
||
Actual: After merging, the name that remains is Maria Sand. Expected: After merging, the name that would remain is Maria Sandler.
Flags: needinfo?(nkhristoforov)
Comment 8•11 years ago
|
||
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? → ---
Comment 9•11 years ago
|
||
(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)?
Comment 10•11 years ago
|
||
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)
Comment 11•11 years ago
|
||
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)
Comment 12•11 years ago
|
||
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)
Comment 13•11 years ago
|
||
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)
Comment 14•10 years ago
|
||
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
status-b2g-v1.4:
--- → affected
Whiteboard: burirun3 → burirun3, burirun1.4-1
Comment 15•10 years ago
|
||
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
Updated•10 years ago
|
status-b2g-v1.3T:
--- → affected
Comment 16•10 years ago
|
||
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.
Updated•10 years ago
|
status-b2g-v2.0:
--- → affected
Updated•10 years ago
|
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → jmcf
Assignee | ||
Updated•10 years ago
|
Target Milestone: --- → 2.1 S8 (7Nov)
Updated•10 years ago
|
Whiteboard: permafail → permafail [p=2]
Assignee | ||
Updated•10 years ago
|
Target Milestone: 2.1 S8 (7Nov) → 2.1 S9 (21Nov)
Assignee | ||
Comment 17•10 years ago
|
||
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
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
status-b2g-v2.2:
--- → affected
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+]
status-b2g-v2.2:
affected → ---
Flags: needinfo?(dharris)
You need to log in
before you can comment on or make changes to this bug.
Description
•