Closed Bug 903958 Opened 9 years ago Closed 7 years ago

[Buri][Contacts]It can't search all the matching contacts.

Categories

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

defect

Tracking

(tracking-b2g:backlog)

RESOLVED WORKSFORME
tracking-b2g backlog

People

(Reporter: sync-1, Unassigned)

References

Details

Attachments

(2 files)

log
314.35 KB, text/plain
Details
21.48 KB, image/x-png
Details
AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.179
 Firefox os  v1.1
 Mozilla build ID:20130730070228
 
 
 Created an attachment (id=484140)
 pic
 
 DEFECT DESCRIPTION:
  It can't search all the matching contacts.
 
  REPRODUCING PROCEDURES:
  1.There are many contacts,with similar name(such as:tabeij100~tabeij300)
  2.Search contacts,slide search screen contacts list,there are just display top seven contacts---->KO1
  3.Search "tab",it can search part of contacts(tabeij100~tabeji121)---->KO2
 
  EXPECTED BEHAVIOUR:
  KO1:It should display all contacts
  KO2:It should search all the similar contacts
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
  Mid
  REPRODUCING RATE:
  5/5
  For FT PR, Please list reference mobile's behavior:
we find a similar pr:879177, the patch has been added to v1.1.
but we find our k01 and k02 can be reproduced.
blocking-b2g: --- → leo?
REPRODUCING PROCEDURES:
  1.There are many contacts,with similar name(such as:tabeij100~tabeij300)
  2.click Search bar,slide search screen contacts list,there are just display top seven contacts---->KO1
  3.input "tab" in search bar,it can search part of contacts(tabeij100~tabeji121)---->KO2
Clone from brother
Attached file log
Clone from brother
Attached image pic
Based on looking at the code previously, I believe the code was designed to explicitly limit the number of elements shown during search for performance reasons.  I think this was done for performance reasons since adding/removing large portions of the list as the user types may introduce jank.

Currently there are two levels of row limiting in the code:

1) While the search textfield has focus the number of results is limited to the screen size, which is typically 7.

2) When the search textfield loses focus, further results are added up to a total limit of 25.  This is not that useful, though, because its hard to remove focus from the textfield without selecting a contact.  (I think there was a bug to do this when hitting "enter", though.)

It seems we could try to optimize the code and increase the limits, but there will probably be some restrictions in order to keep the interface fast.

Perhaps a good compromise would be a UX change where we add a "show more results" button at the end of the list?

Finally, I would note most real users will not have a large lists of nearly identical contacts and therefore will have shorter lists of results.
we find the android and IPhone both can display all contacts.
we'b better resole this pr.
I do agree with Ben, I would prefer some input from UX here, since just adding the contact can affect the performance dramatically.
(In reply to Francisco Jordano [:arcturus] from comment #9)
> I do agree with Ben, I would prefer some input from UX here, since just
> adding the contact can affect the performance dramatically.

OK, please improve the UX, so that the customer can have a better experience.
When search bar blur, we can rufuse user to scroll.
Only usrer input something, then we give the result list which can be scrolled.
then we can have a better experience
given the amount of work may be required for this bug. koi?
blocking-b2g: leo? → koi?
add to backlog 891754

ni? ayman
blocking-b2g: koi? → ---
Flags: needinfo?(aymanmaat)
It would be absolutely preferable to show all results. This is our benchmark and we need to hit it, so i would absolutely encourage you to strive for that rather than loading results in batches. 

However if performance is an issue we must be objective about the nature of a 'show more results' CTA and compare interaction with it against other options. For example selection of such a CTA in the actively of Search is, on the surface, as labour intensive as typing another character. However a 'show more results' CTA will be perceived negatively as it constitutes a barrier to accessing more of the same returned result set that an end user would expect to have free access to in the first place. Therefore it will be perceived as increasing their 'labour expenditure'. However, on the other hand typing another character would be perceived as positive action, reducing their labour expenditure as it works towards reducing the result set, thus reducing the amount of effort a user has to expend to find what they are looking for. For this reason if we have to limit the number of results displayed can we explore the possibility of calling more results 'on scroll' so it happens 'in user flow' rather that having a "show more results" 'flow blocker/barrier/effort toll' CTA that the user has to actively select in order to proceed?
Flags: needinfo?(aymanmaat)
Hi Vance, this should be fixed in v1.3 per comment#14, thanks!
blocking-b2g: --- → 1.3?
Flags: needinfo?(vchen)
This is not a regression, so we won't hold the release on this. We can certainly work on fixing this though.
blocking-b2g: 1.3? → -
Hi David, since UX already has some inputs, is it possible to nominate this one to 1.4?
Flags: needinfo?(vchen) → needinfo?(dscravaglieri)
Let's put it with ? and we will triage it soon.
blocking-b2g: - → 1.4?
Flags: needinfo?(dscravaglieri)
blocking-b2g: 1.4? → 1.4+
Having a look.
Assignee: nobody → kaze
triage: 1.5? given the time we have for 1.4
blocking-b2g: 1.4+ → 1.5?
traige: putting this to backlog
blocking-b2g: 1.5? → backlog
Duplicate of this bug: 1023211
Assignee: fabien → nobody
blocking-b2g: backlog → ---
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.