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

Status: RESOLVED WORKSFORME

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

Description

[sync-1]

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:

Comment 1

[buri.blff]

we find a similar pr:879177, the patch has been added to v1.1.
but we find our k01 and k02 can be reproduced.

Comment 2

[buri.blff]

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

Comment 3

[sync-1]

Clone from brother

Comment 4

[sync-1]

Attachment: log

Comment 5

[sync-1]

Clone from brother

Comment 6

[sync-1]

Attachment: pic

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 8

[buri.blff]

we find the android and IPhone both can display all contacts.
we'b better resole this pr.

Comment 9

[Francisco Jordano [:arcturus] [:francisco]]

I do agree with Ben, I would prefer some input from UX here, since just adding the contact can affect the performance dramatically.

Comment 10

[buri.blff]

(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.

Comment 11

[buri.blff]

then we can have a better experience

Comment 12

[Joe Cheng [:jcheng] (please needinfo)]

given the amount of work may be required for this bug. koi?

Comment 13

[Joe Cheng [:jcheng] (please needinfo)]

add to backlog 891754

ni? ayman

Comment 14

[ayman maat :maat]

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?

Comment 15

[Jack Liu]

Hi Vance, this should be fixed in v1.3 per comment#14, thanks!

Comment 16

[Jason Smith [:jsmith]]

This is not a regression, so we won't hold the release on this. We can certainly work on fixing this though.

Comment 17

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi David, since UX already has some inputs, is it possible to nominate this one to 1.4?

Comment 18

[David Scravaglieri [:scravag]]

Let's put it with ? and we will triage it soon.

Comment 19

[Fabien Cazenave [:kaze]]

Having a look.

Comment 20

[Joe Cheng [:jcheng] (please needinfo)]

triage: 1.5? given the time we have for 1.4

Comment 21

[Joe Cheng [:jcheng] (please needinfo)]

traige: putting this to backlog