User:Gandalf/About:Config

Overview

Current about:config window in Toolkit apps is hardly usable. It is almost impossible to be used by non technical people, and it's hard for use to experienced users too.

The plan

The plan is to redesign it's UI and then implement the back end :)

Elements

View config should be made of several elements

* List of preferences
* Search box
* Description of each element
* Widget allowing user to change the value and type of the preference
* Visual presentation of preference grouping - tree, list
* Beginners helper widgets that will make it easier to use about config for beginners.

First mockup

* Screenshot 1
* XUL pack 1

This revision allows the beginner to use the left menu to get the first probably most interesting results, it displays descriptions of options (if there are ones), it allows to search through descriptions, pref id's and human readable names.

It does not touch design! I also don't care about the implementation. I'm working on the layout, information architecture, user workflow and experience.

A few notes:

* When you hover a category in the left menu, the description should change to describe the category
* When you search it should search through descriptions, names and id's

What is missing:

* UI to change the pref. Double-click is totally anti-user, cause nobody double clicks on tree elements. The web doesn't double click at all
* Options to show all preferences or only the already set, or all preferences
* Display human readable names instead of pref id's (Font size instead of "gecko.engine.nglayout._fontSize")
* Column sorting, change order of columns
* UI to change the pref should be simple textbox, or the advanced mode in small dialog with things like color picker, file selector, etc.

And overall - everything can be changed. It's the first approach. If you have any idea, share it. I'm not 100% happy with this layout.

Notes/Ideas/Propositions

If you have sth to add, do it here:

• We should be able to get more types, like "file", "path", "directory", "color picker". [timeless]
• [pkasting] I have a lot of questions about this mockup:
  • What's the difference between "search" and "filter"? Are these orthogonal, or can the be made into one widget?
    • Search is searching through pref names, id's and descriptions. Filter just filters (incremental) the result list of prefs.[gandalf]
  • Some sorting/grouping of options is already exposed by their names ("foo.bar.baz"). Why not expose a tree view based on these (a la the window registry)?
    • Because it would require a lot more clicking, while the grouping names would stay confusing (I prefer to have a tree on the left with names, than to have a tree in result with ids) [gandalf]
  • Are the category buttons on the left really going to be usable? I can think of two use cases for about:config:
    • I'm trying to change a particular single option (because a friend or web page told me to or whatever). I don't care what category it's in, I just want the option itself. Something like the current "filter" box is the most useful to me here (or incremental find).
    • I'm the sort of curious user who pokes through everything, so I want to peer through all the options and read their descriptions. The categories aren't really useful to me here either, since I'll need to go through all of them.
      • Also, user may know what he does want, but not remember the pref name. (search and categories) And also, users may blindly look for the options related to sth (that's for search box). [gandalf]
  • Furthermore, some options may not be easily "categorizable" as they might affect, say, performance as well as user-experience and "the browser", or some other set of items that crosses whatever categories you can think of. Unless you want to allow options to be in multiple categories... in which case that might be confusing for a user.
    • good point. We may leave them in "others" or outside of the main categories then. So they can be reachable via search only. [gandalf]
  • If you want something easily editable, why not stick each option's value into a textfield? Then users can simply edit it immediately if they want to, without any other UI. When the user hits enter or changes focus, validate the entry and complain (or do something smart) if it's not valid.
    • I don't know if I can put a textbox/checkbox inside the tree cell in XUL, but that may solve it [gandalf]
      • Checkboxes are not a problem. The tree has built-in support for them starting with Gecko 1.8 (treecol type="checkbox"), the images are missing in the default theme however (at least Firefox, SeaMonkey has them). Text boxes on the other hand require quite a few hacks (Adblock Plus 0.7 has inline editing in its preferences dialog - it works). Generally, editable trees have been discussed quite a few times already, maybe we will finally see them in Gecko 1.9. But still - I don't think it will be possible to display a textbox for every single row of the tree at the same time, this would be a waste of memory. All that I expect is an editor for one row once the editing mode has been activated. [Wladimir Palant]
  • Overall I guess I would say that working from the current UI, but changing to a treeview, allowing options to be more easily edited, and adding descriptions of all the items (visible at top/bottom for whatever item is selected) would go a long way toward addressing the shortcomings of about:config. Perhaps a few buttons (for adding/deleting an option, or editing one? maybe this is a better replacement for doubleclick than the textfield idea) at top would be good too.
• I don't think descriptions/human readable names or categorization are viable ideas, both require more effort then can be justified here (as has been noted in mozilla.dev.apps.firefox several times). And "beginners helper widgets" are a non-feature - whoever goes to about:config is an advanced user by definition. Improvements on a lower scale might still be fine, especially better editing of preferences. Search should be the usual find bar, no need to reinvent the UI here. Optional presentation as a tree might also be useful, especially if you don't create useless containers containing only one pref. Possible issues: a container in the tree might be a pref itself, sorting is problematic. [Wladimir Palant]

Gerv's Thoughts

As I understand it, about:config gets the list of prefs programmatically from Mozilla, rather than having them in a master list of its own somewhere. If that's true, how are you going to know which pref goes in which category?

In fact, categorisation can make things less findable, because you have to look in each category instead of quick-filtering a master list, as now. (This is why Dave Allen's excellent productivity book "Getting Things Done", recommends having a single A-Z filing system rather than subdividing it by category.)

[I also think that having both Search and Filter is confusing and that "General" and "Advanced" are terrible names for tabs.]

Task-based analysis

The mockup doesn't actually address the actual usability issues in the current about:config. Looking at it from a task-based perspective, the two tasks users will do are "find a pref" and "change a visible pref".

"Find a pref" is almost always done when they know the pref they are looking for - from a web page, security announcement or whatever. So the Filter: box on the current about:config should be labelled, or have a grey hint inside it saying "Enter all or part of a preference name".

"Change a pref" is what happens once they've done "find a pref". The right way to do this would be to have the right widget inside the tree - checkboxes, text fields etc. But I'm not sure if our tree implementation permits that. If not, an extra column with an "Edit" button, which does the same thing double-clicking does now, would probably do the trick.

So I think that we could improve the usability of the current about:config more by doing less - i.e. what I suggest above.

Target

* Flock
* Firefox
* Thunderbird
* Others?

Status

This is my private project. Neither Firefox nor Flock project managers said that it will be ever used in those browsers, but I believe that if we can come up with something good, I hope they will make a wise decision :)