Closed Bug 782599 Opened 12 years ago Closed 7 years ago

enable search in in-content preferences

Categories

(Firefox :: Settings UI, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1335905

People

(Reporter: cers, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: p=0)

Attachments

(1 file, 1 obsolete file)

When the new in-content preferences land, it should be possible to search/filter the preferences shown.
Depends on: 754344, 752719
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.
(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.
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.
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
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.
Attached patch early WIP (obsolete) — Splinter Review
Whiteboard: [triage]
Whiteboard: [triage]
Whiteboard: p=0
Depends on: 216931
Attached 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)
Hi, just wanted to know if someone is still working on it, and when can we expect this feature.
Depends on: 1195005
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)
No longer depends on: 216931
The bug 1335905 is doing search on about:preferences.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
No longer depends on: 1195005
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: