Closed
Bug 875793
Opened 11 years ago
Closed 11 years ago
[UX Spec] Contacts should be de-duped upon import.
Categories
(Firefox OS Graveyard :: Gaia::Contacts, defect, P1)
Tracking
(blocking-b2g:koi+)
RESOLVED
FIXED
blocking-b2g | koi+ |
People
(Reporter: swilkes, Unassigned)
References
Details
(Whiteboard: ux-tracking, ux-priority1.2, [u=commsapps-user c=contacts p=4])
Attachments
(1 file, 2 obsolete files)
(deleted),
application/pdf
|
Details |
This bug is for UX spec creation to show contact de-duping by the system upon import.
The design should include the ability for the user to easily and quickly delete a contact that is already a dupe (today that is difficult and can only be done on a one-at-a-time basis).
Comment 1•11 years ago
|
||
We will need lot of input from UX to try to deliver this.
So far I don't know any other system that does this in an appropriate way, so lets make it happen :)
Reporter | ||
Comment 2•11 years ago
|
||
Hi Francisco - definitely. Wilfred, I just want to confirm Product and Eng priority on this one, though. According to the Product Backlog, this feature is a must-have for 1.2 but is also on row 25, which is rather far down the list in terms of what gets done first. Please let me know if this has changed: there is UX either done or much farther along for higher priority items, so those items should be built first (unless all of this has changed). Thanks!
Comment 3•11 years ago
|
||
As per email this is moved higher up given that we have already had quite a bit of UX work done here. We just need to define a user story, preconditions and acceptance criteria, which I am doing right now.
Comment 4•11 years ago
|
||
User Story:
As a user I want to be able to remove duplicate contacts when importing contacts. As a user I want duplicate contacts to be automatically removed.
As a user I expect at least some basic validation with name and number to be done for imported contacts for duplication. If other information than name and number do not match user should be given an option to decide to delete the duplicate/not import new contact/have duplicate.
Further user stories should come from UX design.
Preconditions:
* previous import of contact list happened
* new import is from the same source of contacts
Acceptance Criteria:
* User is not asked to delete duplicate contacts one by one manually
* Exactly matching duplicate entries are removed automatically without user interaction.
Comment 5•11 years ago
|
||
A propose an improved and clearer description of the US:
We need to define precisely the criteria that determines if two Contacts are candidates to be merged under only one Contact. This criteria should be IMHO:
+ perfect matching of at least one email address
+ perfect matching of at least one telephone number
We cannot rely on matching of names as it is likely that two people could have the same given Name and family Name.
Once two contacts are candidates to be merged we need to define how the process of merging is going to work, but the principle should be the following, according how Firefox OS works now:
+ Local information has priority over imported information. That means that if there is a Contact C already existing on the address book and a new Contact C2, then in case of conflict C data has prevalence over C2 data.
+ In case of fields with multiple entries like e-mail or telephone the merging process would work seamlessly by creating a set of items without duplicates.
We need to take into account a particular case for Facebook Importation process. We need to decide if when a new Firend Imported from Facebook is matching against an existing Contact in the address book, we automatically link them or we perform a merge.
Of course this is the simplest way of describing the user story because the merge process will not require manual user intervention which will make things easier to be managed and implemented.
Updated•11 years ago
|
Updated•11 years ago
|
Whiteboard: ux-tracking, ux-priority1.2 → ux-tracking, ux-priority1.2, [u=commsapps-user c=contacts p=0]
Comment 6•11 years ago
|
||
reference comment 5. talking to Jose directly. solution will be posted here once defined.
needInfo to me to follow up
Flags: needinfo?(aymanmaat)
Whiteboard: ux-tracking, ux-priority1.2, [u=commsapps-user c=contacts p=0] → ux-tracking, ux-priority1.2, [u=commsapps-user c=contacts p=4]
Comment 8•11 years ago
|
||
(In reply to Wilfred Mathanaraj [:WDM] from comment #3)
> As per email this is moved higher up given that we have already had quite a
> bit of UX work done here. We just need to define a user story, preconditions
> and acceptance criteria, which I am doing right now.
Hi wilfed. who has done the UX work for this, and could you make it available to me please. Thanks
Updated•11 years ago
|
Flags: needinfo?(wmathanaraj) → needinfo?(fdjabri)
Comment 10•11 years ago
|
||
Hi, there is no prior UX work done within the UX team on this AFAIK. There is, however, a fair amount of precedent for contact de-duping on other systems. e.g., webOS and MeeGo.
Flags: needinfo?(fdjabri)
Reporter | ||
Comment 11•11 years ago
|
||
Wilfred, can you please point us to the re-sorted, stack-order backlog? The priorities in Bugzilla don't appear to match that shown in the product backlog spreadsheet. This one I know was covered in email, but we need to track our spec work in stack order. Thank you!
Comment 12•11 years ago
|
||
ok so based on comment 9 and comment 10 i conclude that there are actually no prior UX work/specs to refer to. In view of this I propose an approach that offers two levels to merging contacts:
i) 'passive' merging where the merge happens silently in the background and the user does not need to be aware that a merge has taken place. Having such a facility will speed up the import process, particularly if the user (for whatever reason) decides to 'import all' from the same source more than one time.
ii) 'active' merge where the user has to interact with the device in order to allow / forbid the merge.
what i am going to do now is describe the proposed logic for 'passive' merging (wireframes for active merge will follow in due course)
**PATH**
1) user selects a source to import contacts from.
2) upon import the system compares the incoming contact with contacts already in the contact list on the device and passively (silently) merges incoming contacts with those in the contact list in the following instances:
2.1) when there is an exact match between a contact's first name, last name and phone number on the device and in the incoming contact
2.2) when there is an exact match between a contact's first name, last name and email on the device and in the incoming contact
2.3) when there is an exact match between a contact's name, last name, phone number and email on the device and in the incoming contact
3) At all costs we should not avoid the 'cross pollination' contact information from different contacts and therefore should not passive merge if:
3.1) there is a match between a contact's phone number on the device and incoming contact, but no match between the first name and last name
3.2) there is a match between a contact's email on the device and incoming contact, but no match between the first name and last name
3.3) there is a match between a contact's first name and last name on the device and incoming contact, but no match between either the email address or phone number
Flags: needinfo?(aymanmaat)
Comment 13•11 years ago
|
||
wireframe release FFOS_Contacts1.2_20130717_V3.0
Please refer to release note on page 3 of document
Comment 14•11 years ago
|
||
**RELEASE NOTE**
new wireframes
- none
updated wireframes
- none
deleted wireframes
- none
new algorithems
- none
updated algorithems
Merge Contacts v1.2 : Active merge algorithems for merging
- handling of facebook contacts added
Merge Contacts v1.2 : Active merge algorithems for matching
- reference to handling of facebook contacts added
deleted wireframes
- none
new flows
- Merge Contacts v1.2 : Active merge when adding contact
- Merge Contacts v1.2 : Active merge when editing and existing contact
- Merge Contacts v1.2 : Active merge when editing an existing contact
- Merge Contacts v1.2 : Active merge when editing and existing contact
- Merge Contacts v1.2 : Passive linking whilst syncronising facebook contacts
updated flows
Merge Contacts v1.2 : Passive merge whilst importing contacts
- screen 6 annotation updated to reference handing of facebook contacts
deleted flows
- none
Attachment #777119 -
Attachment is obsolete: true
Comment 15•11 years ago
|
||
**RELEASE NOTE**
new wireframes
- none
updated wireframes
- none
deleted wireframes
- none
new algorithems
- none
updated algorithems
- none
deleted wireframes
- none
new flows
- none
updated flows
Merge Contacts v1.2 : Active merge adding a contact no duplicate contacts found
- step 3 removed (unessecary step, design misake)
Merge Contacts v1.2 : Active merge when editing an existing contact and no duplicates found
- step 3 removed (unessecary step, design misake)
deleted flows
- none
Attachment #786843 -
Attachment is obsolete: true
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•