Closed Bug 1102511 Opened 10 years ago Closed 10 years ago

[UX] Do something sensible when many search engines are installed

Categories

(Firefox :: Search, defect)

defect
Not set
normal
Points:
5

Tracking

()

RESOLVED FIXED
Iteration:
38.3 - 23 Feb
Tracking Status
firefox33 --- unaffected
firefox34 + wontfix
firefox35 + wontfix
firefox36 + wontfix
firefox37 - wontfix
firefox38 --- affected
firefox-esr31 --- unaffected

People

(Reporter: Gavin, Assigned: agrigas)

References

Details

(Whiteboard: [ux])

Attachments

(2 files)

It probably doesn't make sense to show more than e.g. 15 engines in the one-off search dropdown. We should cap them.
If we add a cap, we should probably still fully fill the last row.
[Tracking Requested - why for this release]:
Please don't "cap" the search engines at 15. When the user makes the Search Bar wider the grid gets wider, so a "hard" cap is too arbitrary, IMO. As far as "filling the last row" goes, change the width of the Search Bar and the number of rows might change leaving more room than a "hard" cap would provide. In my most used Profile I have 36 search engines installed and would like to have more so I can cut back on the number of Profiles I have. I have had more in the past but I grew weary of having to scroll down to get to the engines at the bottom and to Manage Search Engines. That is with a 1280 x 768 resolution desktop monitor. Or provide a pref in about:config to let the user adjust the "cap" if they so desire. Yes, Options > Search can be used disable a search engine to allow another to be enabled, but that could wear thin fairly fast. Almost as easy to just open a 2nd Profile just to have access to other search engines.
Limiting the number of rows rather than the number of icons may be a good way to let people with large screens use more engines. But anyway, this really seems to be UX questions for Philipp.
After reviewing with Gavin, this is a wontfix for 34. I have tracked 35+ and would like to see us address this soon.
Flags: firefox-backlog?
I see no reason for arbitrary capping, but the *empty* cells in a long row are not very helpful, IMO.
Summary: do something sensible when many search engines are installed → [UX] Do something sensible when many search engines are installed
Whiteboard: [ux]
Flags: qe-verify-
Flags: firefox-backlog?
Flags: firefox-backlog+
Too late now in the 35 cycle to take on churn here. This bug is vague and has no assignee - can that be resolved so we're tracking an actual item of work for 36?
Flags: needinfo?(gavin.sharp)
Flags: needinfo?(gavin.sharp)
Redirecting that request to Philip.
Flags: needinfo?(philipp)
The thing with UX bugs is that they often are vague (since the removal of the vagueness is the purpose of the bug ;) We don't know what »something sensible« is yet. I'll put this bug on the priority list for the next iteration, so that we'll have something more solid soon.
Flags: needinfo?(philipp)
Philipp, are you targeting 36 or 37 for this? Thanks
Flags: needinfo?(philipp)
Points: --- → 5
For now, I am going to wontfix it for 36. There are still work on this to do, we shipped two releases with it and it does not seem to impact too much people. However, as discussed on IRC with Florian, if we have a 3 lines low-risk patch for this, please submit the uplift request!
Why limit the number now, considering the new system is IMHO much better when using a lot of additional search-engines? Previously you occasionally had to scroll down a rather long list if you had a lot of search engines, which could be annoying. And users aren't installing additional engines if they aren't planning to use them anyway. Removing or disabling unneeded engines has been made a tad easier and more discoverable with recent changes, too. IMHO capping the number of available engines without reason would be just a rude move a la "too bad, so sad".
Assignee: nobody → agrigas
Status: NEW → ASSIGNED
Iteration: --- → 38.2 - 9 Feb
At this point I think we should let the desktop team prioritize this work along with the rest of their work. I am dropping tracking from 37.
I do not agree with any reduction of the displayed search engines. I have 33 search engines installed at home and 28 at work. When a user adds a search engine and does not mask it, it is because he wants to use it! At least, a preference should allow the user to adjust any limit. My suggestion is to reduce the padding of the icon containers. That could allow to display at least one more icon in a row.
(In reply to Sylvestre Ledru [:sylvestre] from comment #10) > Philipp, are you targeting 36 or 37 for this? Thanks Sorry for the slow turnaround. I don't think the work coming out of this bug needs any uplifting. Tracking for 38 or even 39 is fine.
Flags: needinfo?(philipp)
More compact layout to accommodate all default providers on one line. If user has less that 5 providers, adapt grid to second layout attachment. Related to ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1103315 which encompasses the selected state and text change on selection to reflect the provider.
Attachment #8561472 - Flags: ui-review?(shorlander)
Attached image less than 5 .png (deleted) —
If user has less that 5 providers grid collapses down.
Attachment #8561473 - Flags: ui-review?(shorlander)
Comment on attachment 8561472 [details] More efficient grid layout to allow for more providers. 7 per row. Rows added on 8th provider. If possible with this new layout, I suggest we group providers within the same domain. Ie. If user has 3 Wikipedia icons they are next to each other versus sorted by date added.
Attachment #8561472 - Attachment description: grid expanded.png → More efficient grid layout to allow for more providers. 7 per row. Rows added on 8th provider.
(In reply to agrigas from comment #19) > Comment on attachment 8561472 [details] > More efficient grid layout to allow for more providers. 7 per row. Rows > added on 8th provider. > > If possible with this new layout, I suggest we group providers within the > same domain. Ie. If user has 3 Wikipedia icons they are next to each other > versus sorted by date added. Very efficient grid but please let us manage the order of search engines.
(In reply to Blutin from comment #20) > (In reply to agrigas from comment #19) > > Comment on attachment 8561472 [details] > > More efficient grid layout to allow for more providers. 7 per row. Rows > > added on 8th provider. > > > > If possible with this new layout, I suggest we group providers within the > > same domain. Ie. If user has 3 Wikipedia icons they are next to each other > > versus sorted by date added. > > Very efficient grid but please let us manage the order of search engines. Hi, you can reorder them now with drag-and-drop in the Preferences/Settings window.
Comment on attachment 8561472 [details] More efficient grid layout to allow for more providers. 7 per row. Rows added on 8th provider. (In reply to agrigas from comment #17) > Created attachment 8561472 [details] > More efficient grid layout to allow for more providers. 7 per row. Rows > added on 8th provider. > > More compact layout to accommodate all default providers on one line. If > user has less that 5 providers, adapt grid to second layout attachment. Looks good to me. Might need to play with the final size to make sure it still feels like a good hit target. > If possible with this new layout, I suggest we group providers within the > same domain. Ie. If user has 3 Wikipedia icons they are next to each other > versus sorted by date added. Yeah, doing some kind of smart sorting to keep stuff together would be nice. Should probably address that in a follow-up bug.
Attachment #8561472 - Flags: ui-review?(shorlander) → ui-review+
Attachment #8561473 - Flags: ui-review?(shorlander) → ui-review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Iteration: 38.2 - 9 Feb → 38.3 - 23 Feb
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: