This is a meta bug for the feature of moving preferences from a window/sheet to in-content. --------------------------- As part of UX's goal to eliminate Firefox's separate management windows in favor of in-content designs, the Preferences window should be moved into the content area. Such a move provides several benefits for users. First, it removes yet another easy-to-lose window. It means that changing preferences in Firefox can be an identical and easy experience across all devices, including tablet computers. It also means that more interactive portions of Preferences, such as about:permissions, can be integrated with the rest of preferences. This feature falls primarily in the Experience category (from the "Discover, Experience, and Connect" vision statement.) This project has two major components: Move Preferences into in-content pages Redesign Preferences such that their current usability problems are fixed and they integrate well within the content area Goals: Improve the design of Preferences Integrate the parts of Firefox that should be in Preferences (such as the Add-ons Manager) Move Preferences into the content area See these pages for mockups and designs of the new in-content preferences: 1. http://blog.stephenhorlander.com/2010/06/in-content-ui-visual-unification/ 2. http://stephenhorlander.com/pages/incontent-ui-mockups/incontent-ui-mockups.html

Google is currently redesigning the in-content preferences in Chromium. It can be a great source of inspiration. See last chromium builds.I think it has already been implemented.

(In reply to GE3K0S from comment #1) > Google is currently redesigning the in-content preferences in Chromium. It > can be a great source of inspiration. See last chromium builds.I think it > has already been implemented. I can't find any mention of a new redesign, unless you mean the redesign that happened between Chrome 9 and Chrome 10?

(In reply to Blair McBride (:Unfocused) from comment #2) > (In reply to GE3K0S from comment #1) > > Google is currently redesigning the in-content preferences in Chromium. It > > can be a great source of inspiration. See last chromium builds.I think it > > has already been implemented. > > I can't find any mention of a new redesign, unless you mean the redesign > that happened between Chrome 9 and Chrome 10? No it's a new redesign planned for Chrome 18 I guess. More on François Beaufort's Google+ page : https://plus.google.com/100132233764003563318/posts/e55rRtMnRgu

Yeah, Google should redesign it, because Chrome's preferences tab is the most failed design of a UI that I've ever seen. Anybody who thinks that a tab instead of a preference window is easier has lost his marbles. If this gets implemented it will be bye bye time for Firefox for me. What idiots are managing Firefox these days that they think that copying disasters like this and trimming URL's from chrome is a good idea?

The good thing about Firefox is that there would be a pref to disable it. (Bug 735471)

Yeah, you're right, but these days I have to adjust more and more preferences after a new install of Firefox to at least get a usable browser. Up till the point it becomes to annoying and I decide to switch. Please remember, usability is more important then eye-candy. Even Firefox developers seem to forget this nowadays.

(In reply to joopbraak from comment #6) This bug is not the right place for these discussions. Please see https://wiki.mozilla.org/In-content_preferences for more background on why this feature is being implemented. Further discussions should move to the dev.apps.firefox mailing list (https://lists.mozilla.org/listinfo/dev-apps-firefox).

I've tried it on the UX branch. Nice work ! But I can afford thinking the prefs should clearly be redesigned to have all of them on one page with all dialogs in-content (as Google Chrome). Maybe that's planned for the Australis redesign. The options tab should also have an icon.

Some other bugs : -"Applications" shows no applications -"Advanced" shows nothing -back/forward arrows work only sometimes -There is a strange grey texture behind subcategory titles (like Passwords in Security)

I forgot : the old download preferences are still visible even with Javier Rueda patch to suppress them enabled.

The cookies management window is also broken.

I noticed that the bug with the back/forward arrows appears apparently only in private browsing mode.

Another inconsistency : when you click on options in the menu, it always open a new tab. When you click on the add-on manager, if the add-on tab is already open, you go directly to it.

I noticed a bug when cleaning history while using option. You can't go back. It's shouldn't be the default behaviour since options aren't part of the browsing history.

(In reply to Guillaume C. [:ge3k0s] from comment #16) > I noticed a bug when cleaning history while using option. You can't go back. > It's shouldn't be the default behaviour since options aren't part of the > browsing history. This has landed on mozilla-central now - please file new bugs for any issues you see, and mark them blocking this bug.

Kudos! Well there is lil problem. In older implementation to switch between say General and Advanced , user can click the respected icon at the top of the dialog. However now to do so , one has to click back button , then see the submenu he/she has to go and click it again , this adds 1 more click and distracts from the motive IMO. I have made a quick mockup to solve this problem , as we have done in the addon manager, i think following the same method will maintain the consistency too. I know there are plans to bring breadcrumbs but even then the issue is not sorted, IMO Addon manager does the right job and we should follow it's implementation.

I don't like the current implementation of the settings in the tab with navigation through the pages. I need a navigation with tabs such as in about:addons. It's necessary to bring the interface to a single species.

Re comment 18: In short, one cannot jump from one options page to another, without first going back. So, it should just like the addons manager have the buttons always visible, (and the current one selected).

Extra click(+ distractions) to reach same sub menu with new implementation are making it so hard to use In older implementation to switch between say General and Advanced, user can click the respected icon at the top of the dialog. However now to do so , one has to click back button , then see the sub-menu he/she has to go and click it again , this adds 1 more click and distracts from the motive IMHO. one cannot jump from one options page to another, without first going back & this slows the user down. it should just like the addons manager or the current in-window type where we have the buttons always visible together , (and the current one selected like we have it now). This make the process just like it is in older versions(except in-content)

Re comment 18, comment 19, comment 20, comment 21, comment 22: Has anyone filed a bug to improve the navigation in the new in-content preferences? Possibly blocking bug 738796? (or this one)

(In reply to Jon Rietveld from comment #23) > Re comment 18, comment 19, comment 20, comment 21, comment 22: Has anyone > filed a bug to improve the navigation in the new in-content preferences? > Possibly blocking bug 738796? (or this one) Yes. There is plan to redesign the interaction (including the navigation) of the in-content preferences, see bug 752719. The approach will be similar to the add-ons manager.

What's the status of the Design Overhaul ?

(In reply to bogas04 from comment #25) > What's the status of the Design Overhaul ? See https://bugzilla.mozilla.org/show_bug.cgi?id=754344 for the current status.

As a localizer, I was a bit worried about conflicting access keys (with the main menu bar) by the moving prefs, but with bug 349943 in mind I recall they will use a different key modifier. Are we sure this new combo will cause no trouble and be clear to users (as it wasn't to me when filing that bug)? Not that I'd like to see them working the same way…

Shouldn't the add-ons settings be accessable from the options tab? (See chrome)

Remove the dependency on Bug 993361 because Bug 993361 is not about moving into in-content and is already being tracked by Bug 1271779.