about:config in Firefox
Zbigniew Braniecki
I was thinking about it, every time I read some "workaround" to some bug
or some "suggestion" for Joe Average to do something there. I think it
might be really bad experience for the user if he'll have to touch this
UI now.
So, I started redesigning the UI for this:
http://wiki.mozilla.org/User:Gandalf/About:Config
I'd like to get as much suggestions as possible before updating the UI,
so please, tell me what you think :)
Greetings
Zbigniew Braniecki
super...@gmail.com
Benjamin Smedberg
I think this is a bad idea. If Joe Average has to use about:config we've
already lost the battle. Spending any amount of time categorizing the
about:config UI is IMO time wasted that could have been put to use somewhere
better.
--BDS
Brett Wilson
> I think this is a bad idea. If Joe Average has to use about:config we've
> already lost the battle. Spending any amount of time categorizing the
> about:config UI is IMO time wasted that could have been put to use
> somewhere better.
I kind of agree, although arguing that something should deliberately be
kept crappy makes me a little uncomfortable.
I think there's a danger that about:config will be the new options
dialog if we make it too nice. People will be even more likely to put
options and stuff in there rather than design a good UI with proper
default settings. Soon it will be like Suite's which is so huge it's
useless.
Brett
Peter Kasting
> Benjamin Smedberg wrote:
>> I think this is a bad idea. If Joe Average has to use about:config
>> we've already lost the battle. Spending any amount of time
>> categorizing the about:config UI is IMO time wasted that could have
>> been put to use somewhere better.
>
> dialog if we make it too nice. People will be even more likely to put
> options and stuff in there rather than design a good UI with proper
> default settings. Soon it will be like Suite's which is so huge it's
> useless.
The question is, does about:config serve a useful purpose or not, and
what is that purpose?
If it does not, it should be removed.
If it does, it should be a suitable tool to accomplish that purpose, and
the effort/priority it should receive should, in theory, be
proportionate to its relative impact on users, compared to other features.
As far as I know, about:config serves the purpose of exposing
configurability that we think is too obscure for the main preferences
dialog but which we believe should still be end-user configurable. If
that is the case, then the intent is that at least some small set of
users actually USE about:config, and therefore I see no idealogical
reason not to make it usable.
There are two practical reasons not to do so, stated above, both of
which seem flawed to me:
(1) Work done on about:config could be better spent elsewhere.
This is true, IF the "user impact" of a poor about:config UI is less
than the "user impact" of some other feature that the people working on
this would otherwise work on. However, that doesn't mean someone
otherwise uninolved couldn't work on this, or someone couldn't have this
as a background task, etc. The original statement also seems to assume
that the actual user impact of the current UI is minimal ("we've already
lost" --> we don't care), which comes back to the question I've stated
above.
(2) Improving about:config will lead to overdependence on about:config.
To me this feels like the wrong place to address this issue. The
question of whether a pref should exist, or should be exposed in
about:config, seems like it should be addressed when the pref is added,
by that patch's reviewer, in the context of an overall desire to
minimize the dependence on about:config (in other words, reviewers
should be skeptical towards expansions of the prefs in about:config).
That doesn't mean those prefs that DO "deserve" to be there shouldn't be
exposed via a usable UI.
Once again, all of this comes down to: what SHOULD be in about:config?
Why does it exist? If we have a good answer to that we should be able
to get an idea of what its future direction should be -- and while it's
perfectly reasonable to say "this purpose is to make our browser more
usable by 0.5% of the user base, and deserves an accordingly low
prioritization", that feels different to me than "let's keep this
purposefully bad".
PK
Zbigniew Braniecki
> Zbigniew Braniecki wrote:
>> Hi all. I started working on new UI for about:config.
>>
>> I was thinking about it, every time I read some "workaround" to some bug
>> or some "suggestion" for Joe Average to do something there. I think it
>> might be really bad experience for the user if he'll have to touch this
>> UI now.
>>
>> So, I started redesigning the UI for this:
>> http://wiki.mozilla.org/User:Gandalf/About:Config
>>
>> I'd like to get as much suggestions as possible before updating the UI,
>> so please, tell me what you think :)
>
> I think this is a bad idea. If Joe Average has to use about:config we've
> already lost the battle.
Of course. But why should we try to loose two of them?
We can't pretend that our users never use about:config. They do. They do
when they hit the bug and someone propose workaround, they do when we
have security issue, and before the release, we offer a workaround by
changing sth there, we do, there can be other ways that lead user to
look there.
> Spending any amount of time categorizing the
> about:config UI is IMO time wasted that could have been put to use
> somewhere better.
Let me just say, that I did it on sunday, during BarCamp, I was tired
and pissed of by everything around, and had about:config open ;)
I do agree, that it's not high priority, and thus I do not propose a bug
for this, or try to ask any developer from Mozilla to focus on that.
I'm asking volunteers, who might want to help and I'll try to manage it.
It's also my testcase of how to deal with Bugzilla UI management later ;)
So yes - do not waste your time on this please, but if you feel it's not
a waste of time, help me :)
Greetings
Zbigniew Braniecki
Zbigniew Braniecki
> I think there's a danger that about:config will be the new options
> dialog if we make it too nice. People will be even more likely to put
> options and stuff in there rather than design a good UI with proper
> default settings. Soon it will be like Suite's which is so huge it's
> useless.
That's bad way of thinking about it. It's like "if we'll make crash
dialog cute, people will create bugs just to look at it".
If anyone who has influence on how UI looks like will change the
decision about UI for the option because about:config will be less ugly,
then he probably should never touch UI.
Greetings
Zbigniew Braniecki
Zbigniew Braniecki
> This looks absolutely awesome. But can the search box say Search
> instead of Filter.
Search is in top right corner.
Filter is just a method to filter the result list onLive. So when you
have a list of options related to browser, you can start typing "tabs"
and it'll filter only those options from the result list which has
"tabs" in the name.
> And shouldn't the "General" tab have easier language for the entries.
> Maybe like customized to " Tabs Fastback should remember for" for
> "xxx.fastback.xxx"
yes, I mentioned it in the Wiki, that we should present user the pref
name, not the pref id if possible.
(it should fallback to pref id if there's no name for it).
Greetings
Zbigniew Braniecki
Brett Wilson
>> I think there's a danger that about:config will be the new options
>> dialog if we make it too nice. People will be even more likely to put
>> options and stuff in there rather than design a good UI with proper
>> default settings. Soon it will be like Suite's which is so huge it's
>> useless.
>
> That's bad way of thinking about it. It's like "if we'll make crash
> dialog cute, people will create bugs just to look at it".
I certainly never said people would create options just to look at them
in the config dialog. I said that having an easy way to expose options
to normal people where you can dump unlimited amounts of options creates
a situation where developers feel they have permission to create options
without figuring out the correct behavior.
Creating a better about:config would need to be done hand-in-hand with
cleaning up all the crap that's in there now, and being much more
vigilant about not adding more. In this way I kind of agree with Peter
above.
I'm concerned that you want to make it nice without doing these other
necessary things.
Brett
Zbigniew Braniecki
> If it does not, it should be removed.
It was added because in the rare situations when Mozilla had to ask
users to change sth, they had to ask them to open prefs.js file and edit
it manually. Which sucks. I don't believe that we want to revert to that
state.
> As far as I know, about:config serves the purpose of exposing
> configurability that we think is too obscure for the main preferences
> dialog but which we believe should still be end-user configurable. If
> that is the case, then the intent is that at least some small set of
> users actually USE about:config, and therefore I see no idealogical
> reason not to make it usable.
Yes. That's the case. There are situations when we even ask experienced
users to use it. And what I'm doing is just to make sure that we don't
break the user experience if he'll have to touch about:config.
> (1) Work done on about:config could be better spent elsewhere.
> This is true, IF the "user impact" of a poor about:config UI is less
> than the "user impact" of some other feature that the people working on
> this would otherwise work on. However, that doesn't mean someone
> otherwise uninolved couldn't work on this, or someone couldn't have this
> as a background task, etc. The original statement also seems to assume
> that the actual user impact of the current UI is minimal ("we've already
> lost" --> we don't care), which comes back to the question I've stated
> above.
>
I really appreciate how much Benjamin and you care about me. ;)
> Once again, all of this comes down to: what SHOULD be in about:config?
> Why does it exist? If we have a good answer to that we should be able
> to get an idea of what its future direction should be -- and while it's
> perfectly reasonable to say "this purpose is to make our browser more
> usable by 0.5% of the user base, and deserves an accordingly low
> prioritization", that feels different to me than "let's keep this
> purposefully bad".
Nah. We have purpose for this, and I don't think that anyone would like
to remove this feature. It's a front-end UI to prefs.js and will stay
like this.
Priority for this is very, very low. That's why I'm working on this - as
a volunteer in Mozilla (and it's also out of my scope in Flock) just
because I want to make it better. Last I did talk with Mozilla devs
(which was 3 days ago at XTech ;)), the "We're accepting patches" policy
was alive, so, here I am, help me or ignore, but don't try to kill :)
Greetings
Zbigniew Braniecki
Zbigniew Braniecki
> If it does not, it should be removed.
It was added because in the rare situations when Mozilla had to ask
users to change sth, they had to ask them to open prefs.js file and edit
it manually. Which sucks. I don't believe that we want to revert to that
state.
> As far as I know, about:config serves the purpose of exposing
> configurability that we think is too obscure for the main preferences
> dialog but which we believe should still be end-user configurable. If
> that is the case, then the intent is that at least some small set of
> users actually USE about:config, and therefore I see no idealogical
> reason not to make it usable.
Yes. That's the case. There are situations when we even ask experienced
users to use it. And what I'm doing is just to make sure that we don't
break the user experience if he'll have to touch about:config.
> (1) Work done on about:config could be better spent elsewhere.
> This is true, IF the "user impact" of a poor about:config UI is less
> than the "user impact" of some other feature that the people working on
> this would otherwise work on. However, that doesn't mean someone
> otherwise uninolved couldn't work on this, or someone couldn't have this
> as a background task, etc. The original statement also seems to assume
> that the actual user impact of the current UI is minimal ("we've already
> lost" --> we don't care), which comes back to the question I've stated
> above.
>
I really appreciate how much Benjamin and you care about me. ;)
> Once again, all of this comes down to: what SHOULD be in about:config?
> Why does it exist? If we have a good answer to that we should be able
> to get an idea of what its future direction should be -- and while it's
> perfectly reasonable to say "this purpose is to make our browser more
> usable by 0.5% of the user base, and deserves an accordingly low
> prioritization", that feels different to me than "let's keep this
> purposefully bad".
Nah. We have purpose for this, and I don't think that anyone would like
Axel Hecht
> Brett Wilson wrote:
>> Benjamin Smedberg wrote:
>>> I think this is a bad idea. If Joe Average has to use about:config
>>> we've already lost the battle. Spending any amount of time
>>> categorizing the about:config UI is IMO time wasted that could have
>>> been put to use somewhere better.
>>
>> I think there's a danger that about:config will be the new options
>> dialog if we make it too nice. People will be even more likely to put
>> options and stuff in there rather than design a good UI with proper
>> default settings. Soon it will be like Suite's which is so huge it's
>> useless.
>
> The question is, does about:config serve a useful purpose or not, and
> what is that purpose?
>
> If it does not, it should be removed.
>
> If it does, it should be a suitable tool to accomplish that purpose, and
> the effort/priority it should receive should, in theory, be
> proportionate to its relative impact on users, compared to other features.
>
> As far as I know, about:config serves the purpose of exposing
> configurability that we think is too obscure for the main preferences
> dialog but which we believe should still be end-user configurable. If
> that is the case, then the intent is that at least some small set of
> users actually USE about:config, and therefore I see no idealogical
> reason not to make it usable.
I think that both Benjamins and Bretts comment indicate that they think
that this is not the case.
about:config is a workaround for bugs and edge cases. Bugs would be
wrong thinking about the quality of default settings and their general
availability. Or other bugs, like, oh, yeah, we have this odd bug with
usenet name abbreviations on optim-static-intel-macs, but hell, nobody
uses them, and you can either run them under rosetta or switch the pref
in about config.
If there is a pref that should be exposed to the user, it should be
exposed. But really, a lot of prefs shouldn't.
> There are two practical reasons not to do so, stated above, both of
> which seem flawed to me:
> (1) Work done on about:config could be better spent elsewhere.
> This is true, IF the "user impact" of a poor about:config UI is less
> than the "user impact" of some other feature that the people working on
> this would otherwise work on. However, that doesn't mean someone
> otherwise uninolved couldn't work on this, or someone couldn't have this
> as a background task, etc. The original statement also seems to assume
> that the actual user impact of the current UI is minimal ("we've already
> lost" --> we don't care), which comes back to the question I've stated
> above.
The biggest burden of gandalf proposal is the documentation and l10n
work around it. Making a good UI requires that you actually can find a
localizable and human readable name and a description (and a category?)
for *each* and *every* pref in mozilla, even those funky mailnews
account pseudo tree prefs.
So this not only tends to involve some contributors waste of time, it
needs maintainance, too. (And l10n, though gandalf called that optional
in the wiki discussion).
> (2) Improving about:config will lead to overdependence on about:config.
> To me this feels like the wrong place to address this issue. The
> question of whether a pref should exist, or should be exposed in
> about:config, seems like it should be addressed when the pref is added,
> by that patch's reviewer, in the context of an overall desire to
> minimize the dependence on about:config (in other words, reviewers
> should be skeptical towards expansions of the prefs in about:config).
> That doesn't mean those prefs that DO "deserve" to be there shouldn't be
> exposed via a usable UI.
>
> Once again, all of this comes down to: what SHOULD be in about:config?
> Why does it exist? If we have a good answer to that we should be able
> to get an idea of what its future direction should be -- and while it's
> perfectly reasonable to say "this purpose is to make our browser more
> usable by 0.5% of the user base, and deserves an accordingly low
> prioritization", that feels different to me than "let's keep this
> purposefully bad".
Any pref is in about:config, extension prefs, user set prefs, deprecated
and not-used-anymore Netscape-profile prefs. Everything.
If we want to improve about:config, the first and foremost thing would
probably be editable tree cells ;-)
Maybe an extension that overlays about:config with a wiki-based
webservice that can give rich information on hover? If such an overlay
is easier to do with a rewritten about:config, that'd be fine. But I
wouldn't like to have to maintain that information inside the mozilla
CVS and ship it.
Axel
Mike Connor
> Hi all. I started working on new UI for about:config.
>
> I was thinking about it, every time I read some "workaround" to some bug
> or some "suggestion" for Joe Average to do something there. I think it
> might be really bad experience for the user if he'll have to touch this
> UI now.
>
Having to change some pref to work around a bug is the real problem.
about:config with step by step instructions is only marginally worse
than step by step instructions via the pref panel, but if such an action
is needed, I'd love to get that changed for everyone, and not just those
who find something via Google.
The bug itself is the real problem, and we should focus on being
responsive to addressing as many of these issues as possible, instead of
treading this slippery slope. about:config exists for the same reason
the Registry Editor exists on Windows, because there is a desire for an
advanced configuration editor for developers/testers/advanced users.
It does not and should not need to be beginner-friendly, as prefs that
don't have UI are often hidden for a reason, and there's plenty of prefs
that potentially do bad things that seem like great ideas, like pipelining.
> So, I started redesigning the UI for this:
> http://wiki.mozilla.org/User:Gandalf/About:Config
>
>
You tried to claim farther into the thread that "this isn't going to
affect others, so please don't kill it", but if this is going to be a
part of the toolkit, its going to require buy in from all developers
across any app that uses about:config, along with the backend
developers, because they will have to at the very least get someone to
document things for them, if they don't do it themselves. Then you have
localizers having to translate hundreds of descriptions, and keep up for
every pref that gets added. That seems like a significant timesink, for
more than just people who would be otherwise uninvolved, unless you're
going to sign up an extra translator for each locale. Look at the
source for Preferential, its a massive set of strings, and a lot of
overhead, and not surprisingly, not a single translation. And they're
not even getting into categorization, which is just another layer of
complexity to the system.
> I'd like to get as much suggestions as possible before updating the UI,
> so please, tell me what you think :)
I think its a resource hole, with questionable benefit, that would
involve constant awareness for all developers dealing with
adding/changing/removing prefs, and push a lot of work that should be
unnecessary on localizers. For the amount of effort involved, let's
just push builds with fixes for the bugs that people have to use
about:config to work around instead, and do the right thing without
requiring a ton of upfront effort from at least 50 people, based on the
current localization count.
To be absolutely clear, this is a non-starter (given that I happen to
own this area of toolkit, and bsmedberg is the overall toolkit owner).
We're certainly accepting patches, as long as they don't do more harm
than good. Adding a large resource draw for something like this seems
like something we should reject as quickly and painlessly as possible.
The Preferential guys might be interested, of course!
-- Mike
Mike Connor
> As far as I know, about:config serves the purpose of exposing
> configurability that we think is too obscure for the main preferences
> dialog but which we believe should still be end-user configurable. If
> that is the case, then the intent is that at least some small set of
> users actually USE about:config, and therefore I see no idealogical
> reason not to make it usable.
Ideology is about as much use as as a soup ladle in building a great
application. This is just scarcity of resources at work.
The purpose is actually to provide a relatively simple means of tweaking
hidden prefs, for testing, tuning, or high-risk tweaking, and for that
its certainly good enough. It is not intended as a secondary
prefwindow, or even as a user-exposed feature. In terms of current
Firefox UI, about:config isn't linked or mentioned anywhere, quite
deliberately. Its like the profile manager, it serves a small subset of
people in a pretty major way, and the inconvenience of removing the
feature for those users is greater than the benefit of removing that
hidden feature to the rest of the userbase.
> There are two practical reasons not to do so, stated above, both of
> which seem flawed to me:
> (1) Work done on about:config could be better spent elsewhere.
> This is true, IF the "user impact" of a poor about:config UI is less
> than the "user impact" of some other feature that the people working
> on this would otherwise work on. However, that doesn't mean someone
> otherwise uninolved couldn't work on this, or someone couldn't have
> this as a background task, etc. The original statement also seems to
> assume that the actual user impact of the current UI is minimal
> ("we've already lost" --> we don't care), which comes back to the
> question I've stated above.
As I said to gandalf, there is no free lunch to be had here. To make
this work worth doing, it would require significant buy-in from
localizers and all levels of Mozilla development to ensure that
everything is accurate and complete. There are literally thousands of
unfixed bugs in Firefox that deserve more consideration since they have
a bigger impact and require far less effort across the board.
> (2) Improving about:config will lead to overdependence on about:config.
> To me this feels like the wrong place to address this issue. The
> question of whether a pref should exist, or should be exposed in
> about:config, seems like it should be addressed when the pref is
> added, by that patch's reviewer, in the context of an overall desire
> to minimize the dependence on about:config (in other words, reviewers
> should be skeptical towards expansions of the prefs in about:config).
> That doesn't mean those prefs that DO "deserve" to be there shouldn't
> be exposed via a usable UI.
The app should not depend on about:config at all. It is a useful
testing and tweaking tool, that beats the hell out of editing user.js
and restarting, but that's about it. Prefs that are really useful
should have real UI, users should never require about:config.
> Once again, all of this comes down to: what SHOULD be in
> about:config? Why does it exist? If we have a good answer to that we
> should be able to get an idea of what its future direction should be
> -- and while it's perfectly reasonable to say "this purpose is to make
> our browser more usable by 0.5% of the user base, and deserves an
> accordingly low prioritization", that feels different to me than
> "let's keep this purposefully bad".
I don't think Benjamin is saying "let's keep this purposefully bad" as
much as "this is not a big win, and will take cycles from people that
could do much much more good elsewhere." Even just for review/checkin
bandwidth, that is certainly far above nonzero, and I don't want to take
patches that will create their own gravity around themselves.
-- Mike
Zbigniew Braniecki
> You tried to claim farther into the thread that "this isn't going to
> affect others, so please don't kill it", but if this is going to be a
> part of the toolkit, its going to require buy in from all developers
> across any app that uses about:config, along with the backend
> developers, because they will have to at the very least get someone to
> document things for them, if they don't do it themselves. Then you have
> localizers having to translate hundreds of descriptions, and keep up for
> every pref that gets added. That seems like a significant timesink, for
> more than just people who would be otherwise uninvolved, unless you're
> going to sign up an extra translator for each locale. Look at the
> source for Preferential, its a massive set of strings, and a lot of
> overhead, and not surprisingly, not a single translation. And they're
> not even getting into categorization, which is just another layer of
> complexity to the system.
1) I'm not in hurry. I wanted to start sth, because I wanted to come up
with a better approach. I'm perfectly happy with this not getting to
toolkit today, tomorrow, this month or year.
2) On the other hand, I think there's nothing bad in working on this
during two or three Sundays, and putting online so once (in, let's say 3
years) Mozilla folks will decide "Hey! Maybe we could redesign UI of
about:config" - for any reason, it'll be there. Ready and waiting.
3) QA/review is of course a problem. But localizers aren't. It matches
my vision that the panel will stay in english forever. (descriptions
etc.) - it's advanced, hidden, and it can stay english if l10ners have
no time/resources for this.
4) In my approach, I'd like to solve pending bugs that are at the moment
in Bugzilla against about:config. It should also be smaller than current
approach.
> I think its a resource hole, with questionable benefit, that would
> involve constant awareness for all developers dealing with
> adding/changing/removing prefs, and push a lot of work that should be
> unnecessary on localizers. For the amount of effort involved, let's
> just push builds with fixes for the bugs that people have to use
> about:config to work around instead, and do the right thing without
> requiring a ton of upfront effort from at least 50 people, based on the
> current localization count.
> To be absolutely clear, this is a non-starter (given that I happen to
> own this area of toolkit, and bsmedberg is the overall toolkit owner).
> We're certainly accepting patches, as long as they don't do more harm
> than good. Adding a large resource draw for something like this seems
> like something we should reject as quickly and painlessly as possible.
I'm ok with this. It's just an approach. I hope to come up with sth good
enough for you to rethink but if I wont - hell, it's my problem (and as
I'm not going to find it a problem).
So, I really understand that it's not that trivial to check in. But you
are thinking in a bug driven way - a problem - a solution - qa - checked in.
I'm more about create it and let it wait somewhere waiting for better
times ;)
> The Preferential guys might be interested, of course!
Maybe, I'm not discussing the ways to deliver this solution, I'm at the
stage of working on it (well,during sundays ;)).
Greetings
Zbigniew Braniecki
Gervase Markham
> So, I started redesigning the UI for this:
> http://wiki.mozilla.org/User:Gandalf/About:Config
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.)
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.
I also think that having both Search and Filter is confusing and that
"General" and "Advanced" are terrible names for tabs.
Sorry to be negative - but I don't really see this as an improvement :-(
Gerv
Michael Lefevre
> Zbigniew Braniecki wrote:
>> So, I started redesigning the UI for this:
>> http://wiki.mozilla.org/User:Gandalf/About:Config
>
> 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?
> 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".
You're missing a third one, which I think may actually be at issue here.
There is also the task of "find out what I can fiddle with that might
makes things better for me". That task may not be something that the
Firefox developers wish to facilitate, in which case this may might be
better off with other things that aren't wanted in the browser itself, as
an extension. But there's no denying that people do that - having UI for
those people would make things better for them - the existing set of
UI/webpages/extensions are failing to do so...
For example... disabling gif animation is something I usually do. There is
an extension to do this ( https://addons.mozilla.org/firefox/157/ ) but it
hasn't been updated for Firefox 1.5, and the comments on the page all say
"what's the point in having an extension when you can do this with
about:config?"
--
Michael
Peter Kasting
> On 2006-05-23, Gervase Markham <ge...@mozilla.org> wrote:
>
>> 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".
>>
>
> You're missing a third one, which I think may actually be at issue here.
> There is also the task of "find out what I can fiddle with that might
> makes things better for me".
I made both these comments, as well as others that match what Gerv is
saying, on the wiki page -- which is probably where actual discussion of
the quality of the design itself should stay.
I did want to also chime in with agreement on Zbigniew's comment that
this doesn't necessarily _require_ localization. Having a set of
descriptions one person puts together in English is better than having
no descriptions at all -- frankly, I've long thought that at least that
much of Preferential should just ship with the browser by default.
While I respect the desire to not let any language be more of a "first
class citizen" than others, I wonder if mconnor's rejection of this as
"requiring too much localizer work" is letting the perfect be the enemy
of the good.
I _am_, however, in total agreement that categorization is bad from an
implementation/time-sink/maintenance perspective, not just a usability
perspective. I'd like something to get in here, but it needs to be a
patch that _doesn't_ "create its own gravity".
Incidentally, on the topic of what about:config is for, I can personally
vouch that it is NOT just to 'work around bugs". There are many
preference decisions that have been made that may be right for many
users but not all. about:config is the place where users for whom
something other than the default behavior would serve can tweak things.
In that sense it has served, and does serve, as a "second pref panel"
for a long time -- purposefully not made obvious so only those who need
it will find out about it. I simply don't think we have the bandwidth
to exhaustively review all the prefs in about:config and strip the
rarely-used ones, change the app defaults on some others, and leave the
remaining as user options. Until we do, for people like me who, say,
want to use a standard Google search as a keyword.URL, about:config is
the only option.
PK
Henrik Gemal
Sometimes it would be nice if I as a extension developer do do something
like:
pref("extensions.launchy.developer", false, "Show debug information in
the JavaScript console");
have a theird parameter to the pref which would describe the pref. This
would then show up in about:config
--
Henrik Gemal
Mozilla Evangelist
Mozilla Blog with news, devinfo, links, etc:
http://gemal.dk
Ian McKellar
> Sometimes it would be nice if I as a extension developer do do something
> like:
>
> pref("extensions.launchy.developer", false, "Show debug information in
> the JavaScript console");
>
> have a theird parameter to the pref which would describe the pref. This
> would then show up in about:config
This functionality is invaluable in GConf on Linux. Applications install
schema files that describe the defaults and give short and long
descriptions of the keys.
Ian
Ctrl¤/Alt¤/Del¤®
Mr. Braniecki,
Perhaps you should take a look at Opera 9.0 and the about:config
interface that has been implemented within that browser. It is
amazing, truly amazing. Surely Firefox would not pass up a chance to
have something even remotely similar to what Opera now has if you keep
developing what you are developing. If you haven't already seen it, it
never hurts to borrow a few ideas from here and there.
Alt
Gervase Markham
> You're missing a third one, which I think may actually be at issue here.
> There is also the task of "find out what I can fiddle with that might
> makes things better for me".
I think the number of people who approach this task using about:config
(as opposed to say, searching the web) must be very small, even among
those people who use about:config at all.
> For example... disabling gif animation is something I usually do. There is
> an extension to do this ( https://addons.mozilla.org/firefox/157/ ) but it
> hasn't been updated for Firefox 1.5, and the comments on the page all say
> "what's the point in having an extension when you can do this with
> about:config?"
If those comments also give the name of the pref, then this is another
case of "find a pref" and "change a pref".
Gerv
Michael Lefevre
> Michael Lefevre wrote:
>> You're missing a third one, which I think may actually be at issue here.
>> There is also the task of "find out what I can fiddle with that might
>> makes things better for me".
>
> I think the number of people who approach this task using about:config
> (as opposed to say, searching the web) must be very small, even among
> those people who use about:config at all.
Obviously in proportion to the number of Firefox users, it's a small
number. But just because someone searches the web, doesn't mean they won't
also browse through about:config and fiddle with stuff without first
having read about it on a web page.
>> For example... disabling gif animation is something I usually do. There is
>> an extension to do this ( https://addons.mozilla.org/firefox/157/ ) but it
>> hasn't been updated for Firefox 1.5, and the comments on the page all say
>> "what's the point in having an extension when you can do this with
>> about:config?"
>
> If those comments also give the name of the pref, then this is another
> case of "find a pref" and "change a pref".
Indeed. The point was that the extension isn't getting updated and so for
that audience, web pages telling them to tweak prefs are currently the
solution rather than extensions or browser UI. I'm just asking if web
pages and the current about:config is the way those things are supposed to
happen... the Mozilla web pages promote the value of extensions, they
don't promote the value of browsing addons.mozilla.org in order to find
out how to tweak about:config...
--
Michael
Mike Shaver
> 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".
The third task, possibly even more likely to affect non-power-users,
is "find out what the value of a pref is, to help someone diagnose a
problem". That's more 90% of the times that I find myself in
about:config, and I often send people there when I'm trying to help
them fix something. Making sure that the feature they want isn't just
preffed off by some long-uninstalled extension or ancient profile is
an important step in many of those cases.
"Type 'about:config', then type 'viewers', then tell me what the value
on the right is."
Mike
Gervase Markham
> The third task, possibly even more likely to affect non-power-users,
> is "find out what the value of a pref is, to help someone diagnose a
> problem".
I'd say that's basically the same task as my "find a pref" task; it just
has the added component of being able to read the current value of the
pref to someone down the phone.
But that does raise a valid point: if pref values aren't selectable and
copyable, they should be. This is useful in the context of
debugging-by-email or IRC.
Gerv
Gervase Markham
> Obviously in proportion to the number of Firefox users, it's a small
> number. But just because someone searches the web, doesn't mean they won't
> also browse through about:config and fiddle with stuff without first
> having read about it on a web page.
But we don't _want_ people to browse through about:config and fiddle
with stuff without first having read about it on a web page. That leads
to broken browsers, unhappy users, and shaver being called up and having
to ask people to go to about:config and read values to him down the
phone. ;-)
> Indeed. The point was that the extension isn't getting updated and so for
> that audience, web pages telling them to tweak prefs are currently the
> solution rather than extensions or browser UI. I'm just asking if web
> pages and the current about:config is the way those things are supposed to
> happen... the Mozilla web pages promote the value of extensions, they
> don't promote the value of browsing addons.mozilla.org in order to find
> out how to tweak about:config...
This question is unrelated to the usability of about:config, right?
I'd say that if there's a pref many people want to change, the change
should probably be wrapped up in an extension. But I'm not about to go
out, find what those prefs are, and write extensions for each.
Gerv
Michael Lefevre
> > Obviously in proportion to the number of Firefox users, it's a small
>> number. But just because someone searches the web, doesn't mean they won't
>> also browse through about:config and fiddle with stuff without first
>> having read about it on a web page.
>
> But we don't _want_ people to browse through about:config and fiddle
> with stuff without first having read about it on a web page.
As I said:
: You're missing a third one, which I think may actually be at issue
: here. There is also the task of "find out what I can fiddle with that
: might makes things better for me". That task may not be something that the
: Firefox developers wish to facilitate
I was fishing for the answer you've just given, because you seemed to be
getting into the details of usability based on an assumption that the use
cases did not include people "browsing" about:config, while the UI seems
to be aimed at exactly that case.
>> I'm just asking if web pages and the current about:config is the way
>> those things are supposed to happen... the Mozilla web pages promote
>> the value of extensions, they don't promote the value of browsing
>> addons.mozilla.org in order to find out how to tweak about:config...
>
> This question is unrelated to the usability of about:config, right?
Is it? I would think that working out the intended use of about:config
would be essential to assessing how usable it is.
> I'd say that if there's a pref many people want to change, the change
> should probably be wrapped up in an extension.
I think that's the general idea, and it seems to me like a good one.
> But I'm not about to go out, find what those prefs are, and write
> extensions for each.
And neither is anyone else, so people are encouraged to fiddle with stuff
in about:config instead, with or without good instructions as to what they
should or shouldn't do in there...
--
Michael
Chris Ilias
> I was thinking about it, every time I read some "workaround" to some bug
> or some "suggestion" for Joe Average to do something there. I think it
> might be really bad experience for the user if he'll have to touch this
> UI now.
>
> So, I started redesigning the UI for this:
> http://wiki.mozilla.org/User:Gandalf/About:Config
>
> I'd like to get as much suggestions as possible before updating the UI,
> so please, tell me what you think :)
Usually, if a user has a problem that can be fixed by editing a hidden
pref, my response would go something like, "Enter about:config in the
location bar. Search for the pref |foo|, and change the value to whatever."
I find myself spending more time trying to explain how to change the
value of a pref. Boolean is easy: double-click. Integer or string
require a right-click -> Modify. I think the first and most basic
problem with about:config is that modifying a pref value is somewhat
difficult. (drop-down menu, text field on the page, etc.)
Of course, compared to editing the prefs.js, the current way is a
Godsend. :-)
After that, a user sometimes responds back with "Wow, that's cool. Where
can I find out what all the other lines are for? Is there a master list?"
The usual answer to that is
<http://kb.mozillazine.org/Firefox_:_FAQs_:_About:config_Entries>
The only way a person will come across about:config, is by seeking help
online (FAQs or forums), rather than exploring the UI. If someone has
made it that far, going to a document online, which explains each pref,
isn't much of an extra step. About:plugins (not about:plug-ins ;-) ) has
links to <https://pfs.mozilla.org/plugins/> and
<http://plugindoc.mozdev.org/>.
I think about:config should have a link to an online document, that will
explain each pref.
Sometimes that user posts a week later, saying, "I've fiddled around
with about:config entries, and now I'm having this problem..." (usually,
as a result of changing hidden prefs, without the need to)
If you (you = developers in general) are going to add pref descriptions,
you're also going to need value descriptions. There are quite a few
prefs a user may understand by the name, but doesn't know what the
values equate to. This is particularly true with integer prefs. For
example, |privacy.popups.disable_from_plugins| looks obvious, but I
always have to look up the values for it.)
On a personal note, I hate referring to it as "about:config". I'd much
rather give it a name; as in Thunderbird, where it is called "Config
Editor". But that's just me. :-)
--
Chris Ilias
mozilla.test.multimedia moderator
Mozilla links <http://ilias.ca>
(Please do not email me tech support questions)