Last modified: 2014-09-10 14:12:35 UTC
https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-searchoptions The "Advanced options" section of the "Search" tab in MediaWiki currently looks like this: --- Advanced options [ ] Search in all namespaces Search in these namespaces by default: [ ] (Main) [ ] Talk [ ] User [ ] User talk [ ] Project [ ] Project talk [ ] File [ ] File talk [ ] MediaWiki [ ] MediaWiki talk [ ] Template [ ] Template talk [ ] Help [ ] Help talk [ ] Category [ ] Category talk [ ] Thread [ ] Thread talk [ ] Summary [ ] Summary talk [ ] Manual [ ] Manual talk [ ] Extension [ ] Extension talk [ ] API [ ] API talk [ ] Skin [ ] Skin talk [ ] Module [ ] Module talk [ ] Translations [ ] Translations talk [ ] VisualEditor [ ] VisualEditor talk --- This list looks silly and excessive. While bug 37878 has requested a layout change, I think we need to reconsider how this list is implemented. What about adding a checkbox to [[Special:Search]]'s advanced search section that looks something like this: [ ] Use these namespaces as my default This would de-duplicate the namespace listing (between Special:Preferences and Special:Search) and would allow the search user preference to be set more easily from the search interface itself. Rather than using Special:Preferences and having heavy user interface exposure, any custom search namespace preferences could be "hidden" user preferences. That is, they'll still be stored if they don't match the site-wide default, but they'll not clutter up Special:Preferences.
I really really like this idea.
(In reply to comment #1) > I really really like this idea. Should we set this ticket as for something we'd like to have in the next release (1.22) then?
*** Bug 37878 has been marked as a duplicate of this bug. ***
Are we still collecting (re)thoughts or is this bug focused on a specific change? Seems the latter, changing subject.
[[mw:Manual:Preferences]] and [[mw:Manual:Hooks/GetPreferences]] are not particularly helpful. To hide preferences from Special:Preferences, should they be made of "hidden" type? Added to $saveBlacklist? Spinned off from Preferences.php completely?
You'll want to use 'type' => 'api' (which is, admittedly, somewhat misleadingly named). One core preference using this is 'watchlisttoken'.
Change 131727 had a related patch set uploaded by Nemo bis: [WIP] Save advanced search namespace prefs on Special:Search itself https://gerrit.wikimedia.org/r/131727
Created attachment 15314 [details] Current appearance of the feature Screenshot of the feature as currently coded. It's just one more checkbox next to a few dozens: the HTML needs to be improved a bit but it's really straightforward from an interface perspective.
The idea is good. Now that I see the implementation, it implies you have to perform the search *after* marking that checkbox for it to be saved in your preferences. Don't get me wrong, I'd also think that you have to mark the checkbox before performing the search, but people not so familiar with web forms may find it not too obvious. A possible solution to this that I'm thinking of: add a button that on click would change the preferences using an AJAX call, with a visual feedback of the settings being saved. Also, a checkbox may look weird if you mark it, and after performing the search it remains unchecked (did I checked it when performing the search? or was it totally ignored?).
The behaviour is similar to what happens with the login checkbox, I can't imagine it being so confusing. Only few users very used to the wiki will set their preferred namespaces before their first search. We can grey out the checkbox when the selection wasn't changed, but that can be done on a separate patch IMHO; a visual confirmation is provided by the checkboxes themselves, which are preserved the next time.
(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #9) and (In reply to Nemo from comment #10) Use Colored-highlights, and a Legend, for * These options are the site-defaults * These options are your customized defaults * These options are selected for just-this-search. This will also solve the "what were the defaults? I (might) want to reset!" issue. My ugly mockup/napkin-sketches, from an unrelated topic, just to inspire further thinking: https://i.imgur.com/IcEWCzF.png https://i.imgur.com/tOJOsXG.png
Well, exact colouring is debatable, however we still have to consider colour-blind and blind users. Thus I believe that colour-highlighting is not a good idea.
Change 131727 merged by jenkins-bot: Save advanced search namespace prefs on Special:Search itself https://gerrit.wikimedia.org/r/131727
Thanks for all the help, Chad and Bartosz. Let's get bug 31881 fixed in 1.24. :)
Why on Earth I must run through lots of pages to set personal configuration for myself on a wiki? I think the best is to keep both central place for changing config in preferences and page specific on appropriate pages.
Also why to do a small change on specific WMF wiki's config it's community must hold 1 weeks discussion but a change concerning to all MediaWiki wikis it being done with no discussion at all?
(In reply to Bohdan from comment #15) > Why on Earth I must run through lots of pages to set personal configuration Lots? As far as I know Special:Preferences contains options for about 3 special pages. It's also less common for users to set preferences for Special:Search without ever having visited it: so the action of tweaking preferences will happen in a visit to Special:Search which would have happened anyway, and the total number of special pages visited should be lower (because it's not necessary to switch to Special:Preferences to save the search options you just selected).
(In reply to Bohdan from comment #16) > Also why to do a small change on specific WMF wiki's config it's community > must hold 1 weeks discussion but a change concerning to all MediaWiki wikis > it being done with no discussion at all? How is the long comment thread above, and the even longer review list on the change itself, "no discussion at all"? There was discussion, you just didn't participate. Config changes are not handled by any of the people who were involved in this, except maybe occasionally. Ask the people who handle them about why they have their requirements.
There's a very similar move of preferences to page proposed at Bug 48615, for Special:Watchlist. As this change has met approval, it would be great if that bug could see movement - not least because this change will now cause a preference location inconsistency, if you see what I mean.
Really? Preferences are preferences and have belonged in ... umm ... "Preferences". Shouldn't such a change have had a wider discussion than between eight and eleven people? Maybe it could have been trialled, and checked through the UI processes. Maybe have used the beta features for testing? This seems a significant change that really could have had better rigour put to it for an implementation. It is disappointing that a cabal effect has taken place to what is a significant change to how things are done around here.
Sucks as UX. Do we really want every special page to be creating and maintaining its own interface for user preferences?
(In reply to billinghurst from comment #20) > It is disappointing that a cabal effect has > taken place to what is a significant change to how things are done around > here. I'm sorry you see it that way; I suspect your attitude about this bug is affected by an unrelated change which got merged and reverted in these days after a MediaWiki RfC with a very obscure title. This is nothing like that. Maybe you missed something: https://bugzilla.wikimedia.org/showdependencygraph.cgi?id=62559&display=tree&rankdir=LR If you did it's not your fault, implementation details discussed in each bug (like this) are just that, details; but it's safe to state that since some time ago there is wide consensus, and a strong push, towards reducing the clutter in MediaWiki by reducing interface complexity in general and Special:Preferences options specifically.
Clutter is removing unnecessary items, redundant items, messy items; clutter is not (re)moving a useful and considered page. So since when is a preference page like Search preference considered clutter? It is clear and specific. Preferences are preferences, please keep them together not scattered around the wiki. My attitude is not about any other item, please don't presume. When I am setting up my preferences for a wiki it is very easy to go into preferences and change the settings that I want. Now you are going to make someone go to the search page to do it, off via other links. That is not more helpful. If the issue that we give (too) much choice to users, and they are confronted about tabs, then produce a simple and an advanced choice plan. Please produce the evidence base for this change. To the "maybe I missed ...". Have you missed the meaning of the word "consultation" and maybe seeking a broader opinion? That it is considered that bugzilla is a suitable place for working out a social solution is less than ideal, and yet it happens repeatedly. That a few didn't think it is worthwhile consulting with the broader community about this is disappointing.
I don't understand how clicking into Special:Preferences and then a subpage to set options for Special:SomePage is substantially less complicated than going to Special:SomePage and setting them there the first time you use it. Given that most changes to search options will be made on the fly during search experiences, requiring users to leave the special page, go into preferences and then come back (or change preferences in a new tab then reload the search) is a degradation of the UX. > Preferences are preferences, please keep them together not scattered around the wiki. "The wiki" is a misunderstanding here. "Preferences" are operational modes for programs, and the special pages are a collection of small utility programs accompanying the core. There's no objective reason why their mode controls should be grouped together remotely with the core's. It's like having the windscreen wiper speed control as a switch on the engine instead of on the dashboard; old-school advanced users of that peculiarly-designed car may be fine with opening the hood to change it because "it's always been there", but that doesn't make doing it easy for everyone. A new car would seem particularly old-fashioned if it were still designed this way, and we should be trying to ensure that MediaWiki lives up to the interface design expectations of modern software. > Please produce the evidence base for this change. Pretty much every UX study ever that's shown that the further away you put a control from what it affects, the harder users find it to interact with, or even find in the first place - especially new users. It's the GUI-side version of [[Action at a distance (computer programming)]]. S (speaking only for myself, I'm not a MediaWiki developer)
I guess there are two things here. 1: Users will primarily care about preferences affecting a specific page when on that specific page. They will be able to most effectively see the effects when on that page, too, so giving them the option to save what works when they're there, seeing that it works, is generally quite useful. 2: Users do tend to expect to find preferences in preferences. A common practice, especially for users who have used the software before but are on a new project, is to go through all of them and quickly configure things how they like them, or think they will. Alternately, if they want to go back and disable something after it behaves weirdly, or if another user tells them to change a setting, the preferences are a likely place to go for that. Yes.
@Isarra So you are saying "both-and", not "eliminate one"? This would probably result in duplication of code and maintenance (which is one of my arguments against moving the preferences in the first place.) The suggested model is not as simple as Scott Martin describes it. Although setting the preference is top menu -> special: preferences -> tab, this is simpler than tools menu -> special:specialpages -> search -> settings because search is not readily found in the special:specialpages page. Yes, *if one has already done a search* you are already on the page, but if you have not, you aren't. I just attempted to land on search from the search box: foo, qux, and quux are redirs, foobar is an article, baz and asdf are disambigs, and foobaz gets me to search.
Ideally we'd have some way to automatically dump settings that appear in the interface elsewhere into main preferences just by telling it 'OY LOOK A SETTING'. May also want a separate page of 'all settings' or 'advanced settings' for a lot of them (it could also appear collapsed or something by default - the point is while this is often not the stuff folks will necessarily be after, it should be there somewhere in case they are), sort of like the extra 'config' heap you see in firefox and whatnot, but hopefully somewhat easier to find and use.
(In reply to Amgine from comment #26) > The suggested model is not as simple as Scott Martin describes it. Actually, it is. To get to Special:Search you click the magnifying glass icon in the search box.
(In reply to Isarra from comment #27) > Ideally we'd have some way to automatically dump settings that appear in the > interface elsewhere into main preferences just by telling it 'OY LOOK A > SETTING'. That's exactly what we did. > > May also want a separate page of 'all settings' or 'advanced settings' We have it: https://www.mediawiki.org/w/api.php?action=query&meta=userinfo&uiprop=options&format=jsonfm
(In reply to Nemo from comment #29) > (In reply to Isarra from comment #27) > > Ideally we'd have some way to automatically dump settings that appear in the > > interface elsewhere into main preferences just by telling it 'OY LOOK A > > SETTING'. > > That's exactly what we did. > > > > > May also want a separate page of 'all settings' or 'advanced settings' > > We have it: > https://www.mediawiki.org/w/api. > php?action=query&meta=userinfo&uiprop=options&format=jsonfm Oh, neat! Very nice.
(In reply to Scott Martin from comment #28) > To get to Special:Search you click the magnifying glass > icon in the search box. Or search for nothing. Sorry for two posts in rapid succession, remembered that a moment too late. (And also had the thought that maybe the magnifying glass thing is a skin-specific feature.)
(In reply to Scott Martin from comment #31) > (In reply to Scott Martin from comment #28) > > To get to Special:Search you click the magnifying glass > > icon in the search box. > > Or search for nothing. Sorry for two posts in rapid succession, remembered > that a moment too late. (And also had the thought that maybe the magnifying > glass thing is a skin-specific feature.) Cool! and of course you have evidence that people just do this, intuitively.
How well those features work is a valid question but it's out of scope for this discussion.
Ah, but then how simple it is to alter the settings is also out of scope. My opinion is the people most familiar with the software are those most likely to wish to modify their search preferences. For those users, their user preferences are the most-likely first place to look to alter their user preferences. That would meet most 'least surprise' requirements. Being able to alter the search prefs elsewhere, as Isarra says, would be very cool. Being unable to set the search prefs via the least surprising interface would, in my opinion, not be cool.
(In reply to Amgine from comment #21) > Sucks as UX. Do we really want every special page to be creating and > maintaining its own interface for user preferences? We want sensible defaults and intuitive, easy-to-use interfaces. For most users, there shouldn't be a need to customize the default search settings. If many users are customizing their search settings, we're doing something wrong. For the few users who want to customize their search preferences, there's now a checkbox in the same place as search. This seems like a good thing to me. Because there's now an additional checkbox that controls per-user search preferences, we can de-duplicate the listing at Special:Preferences, which makes for a cleaner user preferences interface (increased signal, decreased noise). This also seems like a good thing to me. Perhaps a pointer from Special:Preferences to Special:Search would be helpful, but I'm not sure it's needed and I'm not sure where it would appropriately go.
Would those 'few users' happen to be the experienced wikimedians (like those who have piped up here)? the ones who know (well, knew) where to modify their user preferences? This sounds so much like a solution looking for a problem.
(In reply to MZMcBride from comment #35) > (In reply to Amgine from comment #21) > > Sucks as UX. Do we really want every special page to be creating and > > maintaining its own interface for user preferences? > > We want sensible defaults and intuitive, easy-to-use interfaces. For most > users, there shouldn't be a need to customize the default search settings. > If many users are customizing their search settings, we're doing something > wrong. For the few users who want to customize their search preferences, > there's now a checkbox in the same place as search. This seems like a good > thing to me. Nobody has argued about sensible defaults, nor the ability for communities to be able to adjust and modify. I don't see how that introduction is relevant. > Because there's now an additional checkbox that controls per-user search > preferences, we can de-duplicate the listing at Special:Preferences, which > makes for a cleaner user preferences interface (increased signal, decreased > noise). This also seems like a good thing to me. In fact if you follow that logic, we are now cluttering up a search page with an option that is going to be used rarely or not at all, and maybe by a small subset of people ... Making visible an option that is probably used zero times by most user, and maybe once or two by a small number of users. That is perverse. > Perhaps a pointer from Special:Preferences to Special:Search would be > helpful, but I'm not sure it's needed and I'm not sure where it would > appropriately go. Or it could be '''at''' the search page that it says something the lines of "Save this criteria to be your default" and have a link to Special:Preferences. I have no specific issue with an improvement or option at Special:Search, my issue is that Preferences = Preferences and I expect to be able to go there and to be able to set my preferences for search.
(In reply to billinghurst from comment #37) > my > issue is that Preferences = Preferences Too bad this assumption is incorrect. We have plenty of preferences which have never been controlled by Special:Preferences, look https://www.mediawiki.org/w/api.php?action=query&meta=userinfo&uiprop=options&format=jsonfm again. Not to speak of all the preferences which are not even stored in the database, but instead on cookies or URL parameters (hence bookmarks at best).
(In reply to Amgine from comment #36) > This sounds so much like a solution looking for a problem. It was 50/50 that you were going to say that. The other option was "if it ain't broke don't fix it". Both are useless clichés. Your comments are dripping with "me, me, me" privilege-based assumptions. Luckily, MediaWiki development is not based around avoiding advanced users having to have the minor inconvenience of learning a small interface change.
I fall right in the middle of this disagreement. Here's some notes, and an idea. There are good reasons to have the search-option-preferences in both locations (eg. easier-discoverability for newcomers, familiarity for oldtimers), and there are good reasons to centralize/unduplicate at a single location (with Special:Search->Advanced being the reasonable contender because the options-list *has* to appear there). We do need easy-discoverability for newcomers. Searching for help documentation is HELL unless we add the Wikipedia: , Help: , and Template: namespaces to our default search. For the first few years as a new editor, I was constantly searching those namespaces for tools and guides. (Note that the Template: and Category: namespaces aren't included in the "Help and Project pages" output) I'm surprised that we don't already have a link to [[Special:Preferences#mw-prefsection-searchoptions]] anywhere at [[Special:Search]] (advanced tab or otherwise)! How did we miss that, for so long?! Forest, trees. I do also prefer the simple process for "Save" at Special:Preferences. It's not perfect (see bug 55966), but it's fairly intuitive. The new system isn't intuitive. (It makes sense once explained, but an explanation is needed...) I think the problem with the new version, is the physical distance, or dis-connection, of the checkbox from the search button... So, 2 fuzzy/rough suggestions: A) Add a new Blue "Save selection as my default, and Search" button, at the advanced-search tab, instead of the new "Remember selection for future searches" checkbox line. B) leave the "Search" tab at Special:Preferences, but B.1) just link to Special:Search->Advanced from within it. B.2) Or, when clicked, have it open Special:Search->Advanced in a new tab/window. (New tab, because the user might have other unsaved preference-changes, so we can't change the current page. (cf. bug 55966)) Either of these would solve the issues of discoverability and change-aversion. Yes, it'll still leave an annoyingly almost-empty tab, but it's *way* better than the current/old layout, ie. comment #0 -- All 4 links, for your quick comparison: https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-searchoptions https://en.wikipedia.org/w/index.php?title=Special:Search&search=&fulltext=Search&profile=advanced http://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:Search&search=&fulltext=Search&profile=advanced
(In reply to Quiddity from comment #40) > I'm surprised that we don't already have a link to > [[Special:Preferences#mw-prefsection-searchoptions]] anywhere at > [[Special:Search]] (advanced tab or otherwise)! How did we miss that, for so > long?! Forest, trees. That's a very good point, and I've just made it happen on en.wp.
(In reply to Quiddity from bug 52817 comment #40) > Searching for help documentation is HELL unless we add the Wikipedia: , > Help: , and Template: namespaces to our default search. For the first few > years as a new editor, I was constantly searching those namespaces for tools > and guides. (Note that the Template: and Category: namespaces aren't > included in the "Help and Project pages" output) I guess this is an answer to: (In reply to MZMcBride from bug 52817 comment #35) > If many users are customizing their search settings, we're doing something > wrong. Split to bug 66066.
(In reply to billinghurst from comment #37) > Nobody has argued about sensible defaults, nor the ability for communities > to be able to adjust and modify. I don't see how that introduction is > relevant. Amgine asked, "Do we really want every special page to be creating and maintaining its own interface for user preferences?" I was responding by noting that the goal is having a clean, easy-to-use user interface that uses sensible defaults. The goal is not a foolish consistency. > In fact if you follow that logic, we are now cluttering up a search page > with an option that is going to be used rarely or not at all, and maybe by a > small subset of people ... Making visible an option that is probably used > zero times by most user, and maybe once or two by a small number of users. > That is perverse. Well, not quite. :-) Rather than having this feature (the ability to customize search preferences) take up an entire Special:Preferences tab, it's now confined to a single checkbox. This seems proportionate and reasonable to me. If the feature were more important, it might make sense to give it more prominence, but I (personally) don't think it's very important. > I have no specific issue with an improvement or option at Special:Search, my > issue is that Preferences = Preferences and I expect to be able to go there > and to be able to set my preferences for search. My gut feeling is that the real, underlying issue here is that you, me, and others want global (wikifarm-wide) user preferences. In a similar vein to what I wrote in comment 35, as a user, if you're visiting Special:Preferences often, we're doing something wrong. You should only need to visit that page maybe once a year, but it sounds as though you and a few others visit it weekly or daily. (Which is not a criticism of power-users, to be clear, just a workflow observation.) I think we should focus on figuring out how to make it so that (power-)users don't need to visit Special:Preferences on every wiki in a wikifarm.
> It was 50/50 that you were going to say that. The other option was "if it ain't > broke don't fix it". Both are useless clichés. Mmm, actually the third option was "change for the sake of change". They are clichés because they are common, valid issues. And you have not addressed the substance of the comment. I would suggest your response - highly defensive and dismissive - is itself a cliché of "Dev knows best", except I also know the reason it's a cliché is because it's often true. I'm with Quiddity, Isarra, and sDrewth: let's figure out a both-and solution, because it does not need to be either-or.
(In reply to MZMcBride from comment #43) > My gut feeling is that the real, underlying issue here is that you, me, and > others want global (wikifarm-wide) user preferences. Speaking only for myself, I usually modify my search based on my involvement with the specific wiki. My search on a project I'm involved with and editing regularly usually needs the project and often the user namespaces. Ones I'm only occasionally editing need help and project namespaces. The defaults work fine on projects where I'm only a reader. It is a workflow issue.
I am wondering whether the proponents of the change have had the ability to review suggestions made by people who are not in favour of the holistic change and may be able to suggest a compromise position. I have reopened this bug as I do not think that it should be considered fixed in light of this extra opinion.
(In reply to Quiddity from comment #40) > I think the problem with the new version, is the physical distance, or > dis-connection, of the checkbox from the search button... Split to bug 66342. (In reply to billinghurst from comment #46) > I am wondering whether the proponents of the change have had the ability to > review suggestions Yes.
I am sorry, that is a typical dismissive response, and pretty unhelpful. I don't see the issues raised addresses by the bugzilla. BTW no one made you the decision maker, and as it is your code I would think a little less CoI, and some more communication would be preferable.
(In reply to billinghurst from comment #48) This bug is technically fixed: Advanced options preferences are now handled on Special:Search itself, which is the topic of this bug, so please stop reopening it. Also, a "resolved" status doesn't prevent you from commenting. If you detect flaws on the implementation, feel free to open a *new* bug describing the problems of this implementation (see [1]). I'd suggest you to raise your concerns in a mailing list (mediawiki-l seems to be the the best one for your concerns) [2]. Your message will be received by more people that can share their point of view about this, while your messages on this bug report are being received by the same developers that were involved in it. Feel free to put here a link to the discussion on the mailing list if you decide to start a discussion there. ---- [1] https://www.mediawiki.org/wiki/How_to_report_a_bug [2] https://www.mediawiki.org/wiki/Mailing_lists
No, I won't sit down, shut up and enjoy the ride. Really, most other places require consensus and consultation for change. I believe that Erik himself said that in edits relating to Flow. Something along the lines of <quote>... We do strive to communicate, solve problems real users have, and resolve conflicts, especially if there are major points of contention. What are the material issues with the deploy at this time?</quote> So you have * major points of contention * no evidence that this fix actually a major point of contention * communication in a newsletter that points here, but you are not prepared to listen or discuss * no attempt to resolve a conflict * a merged change that is predicted to take place where no consultation has taken place * an opportunity to address matters raised prior to a deployment Have I missed something from that little list? Seems more than a technical fix. It appears to be a change planned to be implemented and you are not allowing broader discussion, or the base challenge to your assumptions. The points have been raised, and yet you forge ahead with your decision without an attempt at consensus, or some conciliation. And the history of bugs is that they are discussed in situ, not fobbed off somewhere else where you can ignore them in all their glory. I would think that it would actually be incumbent on you, those bringing the change forward to mediawiki, to propose and discuss that merged change. But no, instead we hide behind the "technical" barrier. Then expect others to go somewhere and complain "I don't like it." Grow up. The mature adult thing is for me to bring concerns here, to have them reasonably listened to, and to see if we can have a compromise. Seems that the mature approach is not suitable. If you want that change, you take it out and propose it and defend it. You have identified where it should be discussed, so I look forward to seeing it there. That is basically what I said at the beginning. If I don't see it there, then I feel that I am justified in reopening this bug until there is what I consider some reasonable conversation about this bug, and means to explore the matters raised.
So much drama about a single checkbox… get me out of here.
My complaint has "never" been about any checkbox, but the removal of Preferences.
(In reply to billinghurst from comment #52) > My complaint has "never" been about any checkbox, but the removal of > Preferences. Are you able to offer another tab of Special:Preferences and other 35 checkboxes (in the case of en.wiki) to sacrifice instead? Preferences have been in a process of cutting for some time now and there are some rather extreme proposals around where your time would perhaps be better spent: https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferences The path I'm following is the one of least resistance for the biggest result, you'll see that I'm reducing your future pain. :)
Created attachment 15597 [details] Advanced search tab in mediawiki.org as of 1.24wmf8
(In reply to Isarra from comment #27) > May also want a separate page of 'all settings' or 'advanced settings' for a > lot of them (it could also appear collapsed or something by default - the > point is while this is often not the stuff folks will necessarily be after, > it should be there somewhere in case they are), sort of like the extra > 'config' heap you see in firefox and whatnot, but hopefully somewhat easier > to find and use. Is there an open bug report about this? I wouldn't oppose a gated (behind a checkbox, perhaps) advanced user preferences tab. Safari does this as well, I believe, with a preferences checkbox that enables a "Developer" drop-down menu. Similar-ish idea.
