enable search in in-content preferences

RESOLVED DUPLICATE of bug 1335905

Status

()

defect
RESOLVED DUPLICATE of bug 1335905
7 years ago
2 years ago

People

(Reporter: cers, Unassigned)

Tracking

(Depends on 1 bug)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: p=0)

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

7 years ago
When the new in-content preferences land, it should be possible to search/filter the preferences shown.
Reporter

Updated

7 years ago
Depends on: 754344, 752719
Reporter

Comment 1

7 years ago
I've been working on some interactive mockups of how this could work:
http://geeksbynature.dk/ux/preference-manager/demo1/
http://geeksbynature.dk/ux/preference-manager/demo2/
http://geeksbynature.dk/ux/preference-manager/demo3/
http://geeksbynature.dk/ux/preference-manager/demo4/

Search "works", but more so in later mockups, as the manual transcription of the images (to avoid having to mimic the XUL elements in HTML) has been an ongoing process, and hasn't been back-ported to earlier mockups. At the time of this comment, I'm still working on demo4, and the content of all dialogs (pop-ups) and of the Applications and Sync categories hasn't yet been made searchable.
(In reply to Christian Sonne [:cers] from comment #0)
> When the new in-content preferences land

I don't think search should be a *requirement* for having in-content prefs enabled by default - not having it doesn't regress anything.
Reporter

Comment 3

7 years ago
(In reply to Blair McBride (:Unfocused) from comment #2)
> (In reply to Christian Sonne [:cers] from comment #0)
> > When the new in-content preferences land
> 
> I don't think search should be a *requirement* for having in-content prefs
> enabled by default - not having it doesn't regress anything.

I am sorry, I seem to have worded that unfortunately.

What I meant was; *after* the new in-content preferences land (as opposed to the current in-content implementation), we should implement search. So search is indeed not a requirement for the new in-content preferences, but the new in-content preferences is a requirement for search.

I hope that was more clear.
Reporter

Comment 4

7 years ago
I've added some more mockups, experimenting with breadcrumbs
http://geeksbynature.dk/ux/preference-manager/demo5/
http://geeksbynature.dk/ux/preference-manager/demo6/
http://geeksbynature.dk/ux/preference-manager/demo7/

As of this comment, the category part of a breadcrumb is clickable in demo7.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Some feedback from the UX team. Still need to give it more thoughts so a lot of the feedback are questions that need to be answered.

1. When opening the prefs, showing "All" prefs might not be a good approach. It's bulky and the only reason we have it is to have a place to show the search results. We can try moving the tab in the bottom and not call it "all" but "search results" or something else instead. It's similar to demo4 but calling the tab "search" with the search icon might confuse users that the tab is actual search box.

2. The "clear search keyword" function should be in the search box instead of in the "All" tab, otherwise user need to look back and forth when searching. Also, I think we should move the search box to the left to increase discoverability. 

3. It seems like the back button, Side tabs and Breadcrumbs all serve the same kind of function and having them all is kind of redundant. IMO we should keep the side tabs and choose between back/forward button and breadcrumbs. 

4. Also, there are some other ideas that came out of the discussion. One is the search box can act like the awesome bar when showing the results. Another is highlighting not only the keyword but also the tab category (which I understand is hard to do in the current prototype)

In general, this is awesome! Very glad to see this moving forward! I'll be busy with some user testing for the next two weeks but I'm happy to make some more exploration mock-ups after that.
Oh I forgot one more feedback: currently there's no affordance for the breadcrumbs. It's not obvious to the user that they are clickable. Need some visual design input here.
Reporter

Comment 7

6 years ago
I have a simple version of this working on top of the work in bug 754344 - once I've ironed out a few minor kinks, I'll submit a patch for feedback. Here is a teaser: http://geeksbynature.dk/ux/in-content-search.webm
Assignee: nobody → cers
Reporter

Comment 8

6 years ago
So, one of the "minor kinks" that I've been trying to figure out what to do with is how search interacts with history.

Currently when you click a category we do history.pushState(...) and update the contents. I'm not entirely convinced this should even be the case in the first place, because it's not possible to link directly to a category anyway, so having it as a separate history entry seems weird. Equally, I'm not convinced having both back/forward and the actual category buttons to navigate the preferences is good UX.

I will try to illustrate some of the weirdness history introduces with a couple of examples:

1) go to General
2) go to Advanced
3) search for "pass"
4) click back

Where is the user now? If in Advanced, then clicking forward should take him back to search, right? So the history must contain the last state of search.

1) go to General
2) search for "pass"
3) backspace until search field is empty

User should be back at General which is back in history, but what should forward now do? The latest state of search would be "p", which is not very helpful. We could of course disable forward to search if the field is empty but then:

1) go to General
2) search for "pass"
3) go to Advanced
4) click back (now back at search)
5) backspace until field is empty (now back at General)

if we don't allow forward to the "empty" search, then there's no way back to Advanced.

Secondly, the tabs in Advanced pose a problem, because if anything matches in any one of them, the only option we have is to show the entire tabbox, without regard to which panel is showing and how much content is in it. When search is enabled, it might make more sense to merge everything in Advanced into one page - like all the other categories, but with somewhat more content.

Any input on either of these issues would be greatly appreciated.
Reporter

Comment 9

6 years ago
Posted patch early WIP (obsolete) — Splinter Review
Whiteboard: [triage]
Whiteboard: [triage]
Whiteboard: p=0
Reporter

Updated

5 years ago
Depends on: 216931
Reporter

Comment 11

5 years ago
Posted patch Updated WIPSplinter Review
Attachment #8334929 - Attachment is obsolete: true
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
Hi Christian or Blair,
Is there a try build that UX can try out?
Flags: needinfo?(cers)

Updated

4 years ago
Duplicate of this bug: 1051502

Comment 14

4 years ago
Hi, just wanted to know if someone is still working on it, and when can we expect this feature.

Updated

4 years ago
Duplicate of this bug: 1206543

Updated

4 years ago
Depends on: 1195005
Duplicate of this bug: 1046783
Clearing needinfo and resetting assignee as there hasn't been any visible work on this in a while. Please reassign if you have an updated patch.
Assignee: cers → nobody
Flags: needinfo?(cers)

Updated

3 years ago
No longer depends on: 216931
The bug 1335905 is doing search on about:preferences.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1335905
You need to log in before you can comment on or make changes to this bug.