Closed Bug 1035183 Opened 7 years ago Closed 7 years ago

Matching numbers screen results is not properly localized for 10+ matches

Categories

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

defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v1.4 unaffected, b2g-v2.0 fixed, b2g-v2.1 fixed)

RESOLVED FIXED
2.0 S6 (18july)
blocking-b2g 2.0+
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: flod, Assigned: drs)

References

Details

(Keywords: l12y, regression)

Attachments

(2 files, 1 obsolete file)

For more than 10 matches, header is displayed as

> {{ n }} matches for "123"

This line sets the number to "10+"
https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/suggestion_bar.js#L129

This one from bug 1022445 converts the string to a number, but fails for "10+"
https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/suggestion_bar.js#L331
blocking-b2g: --- → 2.0?
Some doubts also about the meaning of "10+": as it's currently implemented, it means "10 or more", personally I'd expect it to mean "more than 10".
QA Wanted for branch checks.
Keywords: qawanted
Actually, the problem is worse: assuming that there are 15 matches, textContent says "10+". 
If you fix the conversion problem, for example using parseInt, you end up with an header saying "10 matches", which is not true.
QA Contact: jmitchell
(In reply to Jason Smith [:jsmith] from comment #2)
> QA Wanted for branch checks.

This issue Repro's on Flame 2.1, Flame 2.0, and Buri 2.1

Environmental Variables:
Device: Flame Master
Build ID: 20140707060819
Gaia: 99f56d9db3cd37c684b01de6fed786421f47e2b7
Gecko: 085eea991bb9
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Environmental Variables:
Device: Flame 2.0
Build ID: 20140707101630
Gaia: 16410831c2e513b5cabc550363f28a023dc256be
Gecko: 05069bac98d8
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.

Environmental Variables:
Device: Buri Master
Build ID: 20140707060819
Gaia: 99f56d9db3cd37c684b01de6fed786421f47e2b7
Gecko: 085eea991bb9
Version: 33.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

------------------------------------------------------------------------------------
Issue does NOT repro on Flame 1.4

Actual Results: Header shows "10+ matches for "555"

Environmental Variables:
Device: Flame 1.4
Build ID: 20140707000200
Gaia: 5c9e1e4131d3ac8915ed88b72bb66dc7d97be6a0
Gecko: 2d0c15450488
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [QAnalyst-Triage+]
Keywords: qawanted
@Jason, this is caused by the bug I set as a dependency (bug 1022445), no need to find a regression window.
We were also discussing this with :stas on IRC, and the form "10+" has some issues too:
* It's not necessarily common or easy to understand in all cultures.
* It's prone to confusion: does it include 10 or not? Looking at the code it does, but it's not evident, at least for me.

Given that we don't display suggestions before user enters at least 3 numbers, I wonder if we could just display the actual number of matches, I doubt they will reach 3 digits.
QA Wanted - Need a screenshot of the bug here.
Keywords: qawanted
Blocks: 1022445
QA Whiteboard: [QAnalyst-Triage+]
No longer depends on: 1022445
Screenshot added
QA Whiteboard: [QAnalyst-Triage+]
Keywords: qawanted
(In reply to Francesco Lodolo [:flod] from comment #6)
> Given that we don't display suggestions before user enters at least 3
> numbers, I wonder if we could just display the actual number of matches, I
> doubt they will reach 3 digits.

This sounds like the easiest solution.  Looping in the UX team.
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(cawang)
Hi, 
I didn't define that we should list "10+" when there are more than 10 matched results.I think this is provided from visual side(?), but yes, I agree with you, we should display the real number unless it's three digit numbers (we display 99+ for this edge case). What do you think? Thanks!
Flags: needinfo?(cawang)
triage: obvious flaw in user experience. 2.0+
ni? Vicky to feedback on comment 11.
blocking-b2g: 2.0? → 2.0+
Flags: needinfo?(vpg)
Be noted that the list only shows up to 10 numbers (refer to the screenshot https://bugzilla.mozilla.org/attachment.cgi?id=8452481).
It looks like a current design, so I doubt if displaying "real number" make the list look weird.
Flags: needinfo?(cawang)
We can also change the algorithm to not propose a suggestion if you have more than X matches. Because if you have 50 people matching a number, you're probably gonna type one more digit to filter that down anyway.
(In reply to Carrie Wang [:carrie] from comment #11)
> Hi, 
> I didn't define that we should list "10+" when there are more than 10
> matched results.I think this is provided from visual side(?), but yes, I
> agree with you, we should display the real number unless it's three digit
> numbers (we display 99+ for this edge case). What do you think? Thanks!

Hey, no, this is not something proposed from the visual side at all, I think it is more of an implementation decision. Visually there's no document that can define this type of specification, it always comes from an IA or implementation decision.

Cheers,
V
Flags: needinfo?(vpg)
Assignee: nobody → drs+bugzilla
Target Milestone: --- → 2.0 S6 (18july)
Thanks Vicky.

Carrie: What do you think about my proposition in comment 14? If we do that, that means we only display the suggestion bar when we have more than 3 digits and less than X matches.
Yes, let's take 50 as our magic number. Thanks!
Flags: needinfo?(cawang)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Thank you Carrie for the clarification. My understanding of the expected behavior is as below:

1. User types 3 (or more) digits, and the suggestion display shows once the match has less than 50 contacts. 
2. It shows with the actual number instead of something like "10+". 
3. User can tap on the actual number to go to the screen with all the matches listed. Scrollable, and up to 50.
Status: NEW → ASSIGNED
See Also: → 1033937
Comment on attachment 8456380 [details] [diff] [review]
Make matched suggestions not appear when there are more than 50, remove + indicator.

Review of attachment 8456380 [details] [diff] [review]:
-----------------------------------------------------------------

Nice to have 3 different new tests! We're still missing at least one to check that we are displaying all of them in Suggestion List. This will test your +1 / >= changes. Once you have this test, I think we may be able to remove some of the .slice() that are now useless because we always display all of the results.
Attachment #8456380 - Flags: review?(anthony) → review-
Comment on attachment 8456952 [details] [diff] [review]
Make matched suggestions not appear when there are more than 50, remove + indicator.

Review of attachment 8456952 [details] [diff] [review]:
-----------------------------------------------------------------

Only a +6 lines fix! I love fixing bugs with such low impact.

Ship it!
Attachment #8456952 - Flags: review?(anthony) → review+
https://github.com/mozilla-b2g/gaia/commit/e17b3c93d31001643ac8cff2531e0fa1edab69d8
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
backed out on 2.0 due to test failures (thanks Germán for noticing):
https://github.com/mozilla-b2g/gaia/commit/9977a02ea62ba96425a1cc4d1bfb54a909f68905

I'll fix this and reland it.
Whiteboard: NO_UPLIFT
Will request uplift of bug 1018494 to get the tests passing. We have a workaround but I'd prefer to just do the uplift instead.
Depends on: 1018494
You need to log in before you can comment on or make changes to this bug.