Last modified: 2014-05-17 08:39:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T57905, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 55905 - user preference to override collapsing of sidebar items in Vector skin
user preference to override collapsing of sidebar items in Vector skin
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
1.22.0
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 44881
  Show dependency treegraph
 
Reported: 2013-10-19 03:16 UTC by Donald Lancon
Modified: 2014-05-17 08:39 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Donald Lancon 2013-10-19 03:16:42 UTC
The user preference to "Enable collapsing of items in the sidebar in Vector skin" has been killed and the collapsing is now forced on everyone (for reasons that I cannot begin to fathom).

Contrary to the idea (apparently) set forth in bug 23807, this needs to be restored to a user preference.  If Vector is the default skin, we should allow people to configure it in their preferences (the normal place to configure things), not rely on users creating personal CSS or JS code to do it.
Comment 1 Bartosz Dziewoński 2013-10-19 10:53:06 UTC
This was removed by Jon when moving the feature to MediaWiki core, on the grounds that almost nobody used the preference (https://gerrit.wikimedia.org/r/#/c/83590/) and per the discussion on bug 46512. I don't think it should be restored myself, either.
Comment 2 MZMcBride 2013-10-19 12:12:16 UTC
What's the use-case for a user preference? I read and re-read comment 0 and I can't find one.
Comment 3 Jon 2013-10-19 18:08:46 UTC
To be clear this user preference was enabled by 0.0008% of all users on enwiki and 0.02% on de.wikipedia
Comment 4 Jon 2013-10-19 18:09:05 UTC
*0.008%
Comment 5 Donald Lancon 2013-10-20 01:33:35 UTC
(In reply to comment #2)
> What's the use-case for a user preference? I read and re-read comment 0 and I
> can't find one.

I can do without the sarcasm.

I'll try to explain exactly what I'm talking about:

When the collapsible sub-menus were introduced in the Vector skin on Wikimedia wikis (e.g., click on "Toolbox" to show links to WhatLinksHere, SpecialPages, etc.), it was made opt-out, in the sense that users could uncheck the box "Enable collapsing of items in the sidebar in Vector skin" if they wanted all the items in the sidebar always visible.

This made sense, since users tend to look in their preferences when something isn't configured the way they want.

A few days ago, this option went away, and now users can no longer (easily?) configure the Vector skin to not collapse the sub-menus in the sidebar.

What I am requesting is an easy, obvious way for users to override the collapsing of the items in the sidebar (/navbar... whatever).

Why do I need this even though the menus stay open or closed when I navigate between pages on the same wiki?  Simple: I don't stay on the same wiki all the time.  I help to maintain m:Wikimedia_News, which requires me to visit "random" WM wikis almost every day, often checking this or that Special page for relevant information.

Now every time I need to get to Special:SpecialPages, I have to click to open the damned "Toolbox" first.  When I had the user preference, my Toolbox would always be open, on every wiki.  Now every time I need something in my Toolbox, I find that someone has closed it.  Not only that, but I'm told I can't leave all my Toolboxes open anymore.  It's not allowed, for some strange reason.

Clear enough?

This might not seem like much to you, but it's extremely frustrating to users when they used to be able to configure something the way they want, and now they can no longer do that.

I'm sure some of the 0.008% of English Wikipedia users (which, if I am interpreting this correctly, is almost 1,600 people) and 0.02% of German Wikipedia users (almost 350) have good reasons for setting it the way they had it, also.

So... if we're not going to get a user preference to do this again, please tell me what I'm supposed to do to prevent the collapsing of the sidebar sub-menus.

Now, if I'm mistaken about any of this, and there's something I'm not understanding, please let me know about it.

(And as for my bug-submitting abilities, trust me: if I never had to submit a bug report about anything else in my life, I would be exceedingly happy.  Don't blame ordinary users for the shortcomings of Bugzilla's user interface.  If there's something you need people to submit along with their bug reports, tell them about it on the bug submission page.)
Comment 6 MZMcBride 2013-10-20 01:48:05 UTC
I understand the backstory here. I agree with Jon about killing this user preference. I'll explain why below. :-)

(In reply to comment #5)
> Now every time I need to get to Special:SpecialPages, I have to click to open
> the damned "Toolbox" first.  When I had the user preference, my Toolbox would
> always be open, on every wiki.  Now every time I need something in my
> Toolbox, I find that someone has closed it.  Not only that, but I'm told I
> can't leave all my Toolboxes open anymore.  It's not allowed, for some strange
> reason.

Global user preferences don't exist, so presumably you needed to set this user preference on every wiki?

The reality is that most power-users use Monobook, which doesn't collapse any sidebar sections ever. But it's fine to use Vector, even though I personally think the sidebar collapsing behavior is probably altogether mistaken.

You can override the default behavior using per-user CSS or JS. If you want a global page, you can set one up on a wiki of your choosing (I set mine up on Meta-Wiki) and then you can easily import it to other wikis, giving you a customized user experience on any of the wikis you visit. A bit tedious, sure, but probably less so than a user preference change on every wiki you visit.

We need global user preferences and global shared CSS/JS pages, however we also have to recognize, when building user interface elements and attempting to guard against user preference clutter, that most users don't hop around between many sites. Your use-case, while completely valid, isn't a typical use-case. There are others like you, to be sure, but power-users sometimes need power tools (such as per-user CSS or JS).

> This might not seem like much to you, but it's extremely frustrating to users
> when they used to be able to configure something the way they want, and now
> they can no longer do that.

We allow on-wiki per-user CSS and JS. And we have local JavaScript gadgets. One day we'll have global versions of all of these things. We definitely allow users to configure the interface the way that they want to unlike nearly any other site. I agree that this is frustrating, though.

> So... if we're not going to get a user preference to do this again, please
> tell me what I'm supposed to do to prevent the collapsing of the sidebar
> sub-menus.

Yes, we need to get better about this. We have [[mw:Snippets]] and we should have done better to ensure that there was an appropriate snippet in place before removing the user preference. Sorry about that.

Jon or Bartosz: can you help out with that, please? It should be pretty trivial JS or CSS to restore the expand all behavior. Probably a single line.

> If there's something you need people to submit along with their bug reports,
> tell them about it on the bug submission page.

We use Bugzilla to track both feature requests and problems with the software. With the former (though asking for restored behavior isn't _exactly_ a feature request...), it's often incredibly helpful to offer a use-case in order to help justify taking the time, energy, and other resources to make the change.
Comment 7 MZMcBride 2013-10-20 02:03:47 UTC
.collapsible-nav .portal .body { display: block !important; }

That will stop the collapsing.

#mw-panel.collapsible-nav .portal h3 { background-image: none !important; }

That will hide the arrows. A few additional lines of CSS can fix the indentation. It'll take a bit of fiddling, but certainly nothing major.
Comment 8 Jon 2013-10-20 02:04:23 UTC
To be fair I don't think MZ was being sarcastic. He was asking a valid question and in your reply I think you have provided that answer so thank you. If the wiki remembered you had opened a section would this solve your problem? This would mean you would never have to toggle open a section again after toggling it once...
Comment 9 MZMcBride 2013-10-20 02:07:12 UTC
(In reply to comment #8)
> If the wiki remembered you had opened a section would this solve your problem?
> This would mean you would never have to toggle open a section again after
> toggling it once...

Vector currently remembers toggle state of collapsible sidebar sections in a per-site HTTP cookie.
Comment 10 Eduard Braun 2013-11-05 00:08:16 UTC
1.  At least some sort of notification would have been nice before removing this setting.

2.  The fact that the (uncollapsible) behavior can not be easily reactivated through user CSS or JS is disappointing.

3.  The new implementation of the collapsiblenav seems to be imperfect: On initial page load the toolbox is not collapsible and all items are expanded. After some delay the collapsiblenav content seems to be loaded (e.g. arrows appear, indentation changes) and some of the items collapse.
It should be collapsible from the start or not collapsible at all - not something in between that gets slowly loaded with notable delay after page load.
Comment 12 José Gomes 2014-01-30 12:15:49 UTC
I hope Jon is not implying all it matters for any wikimedia feature is that it's used on wikipedia. I know the project has that main user but you can't forget the fact that it has grown much more than that and thousands of people run independent wikis nowadays.

I run a wiki with hundreds of daily visitors and I want this option to be disabled by default. What would be the issue with letting it be an admin choice? Disabling a feature just for the sake of disabling it its just alienating more potential users.

Sincerely hope this is re-added to wiki media soon.
Comment 13 Quiddity 2014-05-09 04:36:15 UTC
This can probably be closed, per bug 39035 being solved by the removal of the collapsing feature. (Live at [[mw:]] as of today. Everywhere else next Thursday.)
Comment 14 Nemo 2014-05-17 08:39:23 UTC
Problem solved by bug 39035.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links