MSU CSE Capstone update 2/14
14 February, 2012 § 6 Comments
It is the beginning of the sixth week of the project to move the preferences to in-content UI.
Much progress is under way at this point, with four of the seven preference panes being worked on in parallel.
Owen has been working on the Tabs preferences pane, and had a question about instant applying of changes to the preferences on Windows. Since the preferences are now located in a non-modal environment, we are going to use instant application of preference changes on Windows. This will bring parity between Windows, Mac, and Linux.
Jon has been working on the Privacy preferences pane and the “Landing” page. The Landing page will be the place that is first seen by users when opening up the preferences. This page will import the other preference pages, and as such is required to integrate all of the pages together. Jon is planning to get near-full feature functionality of the Landing page done this week in time for their Alpha demo. Once the functionality of the Landing page is complete, work will begin on integrating the General, Tabs, Privacy, and Advanced preference pages.
Joe has been working on the Advanced preference page, and ran in to some script errors. We believe the script errors are stemming from a missing string bundle. Joe will spend some time seeing if this is the proper fix and continue his work on the Advanced preferences page.
Devan spent last week working on the General page. The page is near feature functional, and has been handed off to Jon to integrate with the Landing page.
To implement the separate pages, we are including all of the pages in to one larger page. Page navigation will use the HTML5 History API and the showing/hiding of nodes to give the effect of page navigation. This approach will provide us with the framework for our search implementation. There will be back/forward buttons in the top-left corner of the Preferences page, similar to the about:addons page.
At this stage in the project, we are focusing now on functionality and architecture while keeping an eye out for any issues that may come up that would affect the styling. We will wait for full feature functionality before spending time on fixing the design issues.
Every single preferences option should have its own attributes to search on. They should contain any string/text for that option and any string/text to describe its category.
i wait the new UI from the first day witch annoce the firefox 4
I’m curious why this is being done – is there any real benefit in moving preferences (and prior to that, the add-ons screen) from a window to a tab? To my mind, tabs are about web content (it’s a web browser, afterall), and those things don’t really qualify as web content.
Such a move provides several benefits for users: it eliminates the need for another easy-to-lose window, and makes the experience of changing preferences simple and identical across all devices. In addition, more interactive options that fall under the Preferences category, such as Permissions, can be easily integrated with the rest of the options.
Will there be a way to restore previous settings or to undo a change (e.g. if someone accidently selected a different font size from the dropdown and has no idea what it was before)? I really liked that I had to explicitely accept changes until now or could discard them if unsure. You just couldn’t do anything wrong unless you clicked the OK button of that dialog.
How do people on Linux/Mac think about the behaviour there?
Having a way to undo changes or revert settings to their default value is a nice usability win. I’ve filed bug 727274 as a follow-up bug for this feature (http://bugzil.la/727274). Thanks!
Thanks, this is great news 🙂