Wikimedia Bugzilla is closed!

I'm not sure what the purpose of the down arrow menu is unless its use is making twinkle and friendly harder to use. I find that it makes the wiki more annoying. Should we give a preference on the down arrow "tabs" being across or hidden? <sorry for the sarcasm>

This is not the intended design, and would introduce other issues.

Re-opening this until there's some sort of justification for this design decision.

Having a drop-down with a single item doesn't make any sense. It's similar to having a list of items with only A) and no B).

I don't understand how this improves usability for our users to require extra clicks to access something that doesn't need to be hidden in the first place. If anything, it's deliberately introducing an accessibility issue, from what I can see. This bug needs further review.

You may also have a second link: Watch. [Why isn't the watch star on trunk?]
When people isn't autoconfirmed then they will only have watch, so there's a point on people not noticing that they have a new tab and copying & pasting articles to move them.

I already thought on one wiki, after the change to vector, that I didn't have sysop rights any more, since I wasn't seeing a delete tab.

(In reply to comment #4)
> You may also have a second link: Watch. [Why isn't the watch star on trunk?]
It is, it's just not enabled by default. Set $wgVectorUseIconWatch = true;

Another thing about this dropdown is that tabs may be folded into it as the screen narrows, which is why it's always supposed to be there, even if empty (I don't know if the latter is currently the case, but it should be).

I wrote some JS (see my user JS on Commons) that takes all tabs out of the dropdown and puts them in the tab bar, which results in one or two being folded back in in some cases, even on my rather mainstream resolution (1440x900 or some such, I think). I guess this behavior could be made default: use the dropdown only when it's needed to save space. I'd like to hear Trevor's opinion on this.

That seems sensible. Note that if you reduce the screen width, tabs don't go into the dropdown menu, they go instead behind Page & talk tabs and under the logo. So if it wasn't always like that, it's a regression.

The benefit of taking items that would be tabs and tucking them into a menu which is visible on hover (not click as has been misrepresented here) is that it reduces clutter. The purpose for reducing clutter is to allow for isolation of the most important items to occur. This is the same reason we separated the tabs - it provides more space around the Read/Edit/History tabs making them more visible. We've seen noticable improvements of users' ability to locate the Edit tab over Monobook already, and we are looking for ways to make the edit tab more visible, not less - which expansion of the drop-down menu out to full tabs would certainly do.

It should be noted that the software we've written detects the "collapsible" class on list items which are in the tab or menu lists and automatically collapses and expands them when there's enough room for them. We mark the history tab collapsible by default because it's a less used view than read and edit, but bringing items like move and protect up is specifically undesirable, as it's adding clutter to the tabs, reducing the relative visibility of any one tab - a.k.a dilution. If you have a table with only 3 items on it, you can nearly instantly identify any one of them, the more items you add the longer it will take.

Additionally, reducing the number of tabs across the top of the page serves to reduce the minimum screen width required to properly render the skin. Because we have a dynamic-width site, people often see lots of space between the left and right tab sets and think it's a waste of space, not taking into consideration the experience that users with netbooks or older machines will encounter.

> bringing items like move and protect up is specifically undesirable,
> as it's adding clutter to the tabs, reducing the relative visibility of any 
> one tab - a.k.a dilution.

Not all users will have the same needs. Some would favor having a block tab "ready to use" to having an edit tab they never click (I usually access there with keyboard).
Maybe a case for adding a new preference. 


> It should be noted that the software we've written detects the "collapsible"
> class on list items which are in the tab or menu lists and automatically
> collapses and expands them when there's enough room for them.

I have enough space, and the tabs don't move out of the menu.

If I resize the window, View history, doesn't go into the menu.

(In reply to comment #8)
> I have enough space, and the tabs don't move out of the menu.
> 
> If I resize the window, View history, doesn't go into the menu.

The UsabilityInitiative/Vector extension will add this functionality. Also, as I mentioned, most items are not marked as "collapsible". The History tab will get tucked away when there's not enough space, and If you don't have $wgVectorUseIconWatch set to true then the Watch/Unwatch tab will get brought up when there's room.

If making all items able to be collapsed/expanded is something advanced users appreciate, then perhaps this and other Vector tweaks that server these users could be made into a Gadget.

> The UsabilityInitiative/Vector extension will add this functionality. Also, as
> I mentioned, most items are not marked as "collapsible". The History tab will
> get tucked away when there's not enough space, and If you don't have
> $wgVectorUseIconWatch set to true then the Watch/Unwatch tab will get brought
> up when there's room.

require("$IP/extensions/UsabilityInitiative/Vector/Vector.php"); isn't making a difference here.

> If making all items able to be collapsed/expanded is something advanced users
> appreciate, then perhaps this and other Vector tweaks that server these users
> could be made into a Gadget.

We should really have a central gadget repository.

(In reply to comment #10)
> require("$IP/extensions/UsabilityInitiative/Vector/Vector.php"); isn't making a
> difference here.

Is Vector.combined.min.js included in the page? If it is, look for a json object around line 85 in the output where wgVectorEnabledModules is defined. Ensure that the "collapsibletabs" key is set to true.

I thought that you meant line 83 of Vector.combined.min.js, while it only has 16.
I disabled $wgUsabilityInitiativeResourceMode = 'raw';, Vector.combined.min.js is loaded. wgVectorEnabledModules is only checked on that file, not set.

The page html output include:
<script type="text/javascript">var wgVectorPreferences = {
	"collapsiblenav": {
		"enable": null
	}
};
var wgVectorEnabledModules = {
	"collapsiblenav": true,
	"collapsibletabs": true,
	"editwarning": false,
	"footercleanup": false,
	"simplesearch": true
};</script>

alert(wgVectorEnabledModules.collapsibletabs) shows true

(In reply to comment #9)
> If you don't have
> $wgVectorUseIconWatch set to true then the Watch/Unwatch tab will get brought
> up when there's room.
> 
> If making all items able to be collapsed/expanded is something advanced users
> appreciate, then perhaps this and other Vector tweaks that server these users
> could be made into a Gadget.

I'm not sure why you asume only 'advanced users' find it annoying that resizing a window smaller causes tabs to be unclickable or there to be wasted space and an extra hover required, when resizing it bigger.

Seems a no-brainer to me.

See also https://bugzilla.wikimedia.org/show_bug.cgi?id=22986

It seems that you are calling for a "show as much as you possibly can as tabs" approach, which is not what we want for the default user interface, but could potentially be supported as an option.

The software that automatically hides/shows items needs to be improved a bit to support this. Right now only tabs marked as "collapsible" will be collapsed, but marking drop-down items as "expandable" does not yet work. Adding that functionality as well as a line of JavaScript that sets all drop-down menu items as expandable would do the trick.

Again however, exposing more controls does not equal more usability any more than hiding more of them does. There's a balance that needs to achieved between cluttering the screen with every possible button and hiding all buttons behind menus.

The point you make is a good one, I agree that a screen like the one I attached may appear overwhelming to a new comer and is not very clean and simple.

However, I'd like to point out that aside from the Move-tab (where this bug is mainly about) and users with special rights (such as Delete for administrators) and logged in users with user scripts have extra tabs and buttons. Also scripts can always decide for themselfs whether to add their stuff to the menu or the tab-bar and to allow expanding and collapsing. I do think that all the default tabs should be collapsible/expandable with no exception to Move, Delete and Protect.

Now that we're on it, I should note to myself to add support for the collapsible/expandable classes in the new mw.util.addPortletLink.

Also if you think it will be usefull to have but don't have the time/priority to do it yourself (yet) to work on the "expandable"-script . I do have commit access so I'm willing to write it myself - not changing any defaults - just adding the functionality.


--
Krinkle

While yes, scripts can do whatever they like, advanced operations like delete and protect are loaded into the drop-down, and that's where they should be since they are less commonly used tools (maybe we can get some stats on that?).

(In reply to comment #16)
> Also if you think it will be usefull to have but don't have the time/priority
> to do it yourself (yet) to work on the "expandable"-script . I do have commit
> access so I'm willing to write it myself - not changing any defaults - just
> adding the functionality.

Feel free - it's in the Vector extension's ext.vector.collapsibleTabs module. I'm sort of focused on some other things right now.

Created attachment 7804 [details]
Example screen

I forgot to attach the image earlier.