Wiktionary:Votes/2010-01/Setting ToCs to be on the right hand side by default

Hello, you have come here looking for the meaning of the word Wiktionary:Votes/2010-01/Setting ToCs to be on the right hand side by default. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Votes/2010-01/Setting ToCs to be on the right hand side by default, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Votes/2010-01/Setting ToCs to be on the right hand side by default in singular and plural. Everything you need to know about the word Wiktionary:Votes/2010-01/Setting ToCs to be on the right hand side by default you have here. The definition of the word Wiktionary:Votes/2010-01/Setting ToCs to be on the right hand side by default will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Votes/2010-01/Setting ToCs to be on the right hand side by default, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.

Setting right hand side ToCs to default

  • Voting on: Changing the "Table of Contents" boxes to be aligned to the right hand side of the page by default.


  • Vote starts: 00:00, 24 January 2010 (UTC)
  • Vote ends: 24:00, 22 February 2010 (UTC)

Support

  1. Support Yair rand 01:35, 24 January 2010 (UTC) Although Bequw raises some points on the talk page that will have to be taken care of before this is switched on. --Yair rand 01:35, 24 January 2010 (UTC)
  2. Support Vahagn Petrosyan 08:42, 24 January 2010 (UTC)
  3. Support Assuming the obstructing issues are taken care of before the actual switch is made. --Bequw → ¢ • τ 20:08, 24 January 2010 (UTC)
  4. Support DCDuring TALK 22:50, 24 January 2010 (UTC) With reasonably fast implementation.
  5. Support weakly, see talk page for my thoughts. Mglovesfun (talk) 22:59, 24 January 2010 (UTC)
  6. Support because DCDuring supports: he seems to be our most usability-focused editor, so if he thinks this will be a boon for usability, then I'm inclined to take his word for it. —RuakhTALK 04:08, 25 January 2010 (UTC)
  7. Support Conrad.Irwin 20:03, 26 January 2010 (UTC) I had this enabled for many months and noticed nothing outrageously awful. (so much so I forgot I had it turned on :) Conrad.Irwin 20:03, 26 January 2010 (UTC)
  8. Support because, despite the current conflicts, I'm certain that this is going to be the pivotal element in the most elegant solution. DAVilla 07:06, 16 February 2010 (UTC)

Oppose

  1. Oppose Neskaya contribs – talk? 03:00, 25 January 2010 (UTC) I see no good reason for this change. Having the ToC at the right hand side makes it more clunky to use, and for the people who want to have it there, there is WT:PREFS. --Neskaya contribs – talk? 03:00, 25 January 2010 (UTC)
  2. Oppose More problematic than useful. I see this vote as the desire to simply have another vote while there are more important things to be done. — opiaterein — 23:38, 25 January 2010 (UTC)
  4. Oppose Fixes a problem by creating another one. It would be much more effective if we allowed content to flow around the left-side ToC. -- Prince Kassad 20:00, 26 January 2010 (UTC)
    Do you actually like it? I've browsed that way and find it very unpleasant. The English entry is usually squashed to the right. It's even more squashed when there's RHS elements because then the page has four "columns" (left-side panel, ToC, super-skinny contents, and RHS elements). The RHS ToC at least keeps the same vertical line for the left side of content where someone starts reading. --Bequw → ¢ • τ 20:53, 26 January 2010 (UTC)
    It keeps all navigation-related elements to the left, increasing efficiency and reducing mouse movement, also it avoids conflicts between different RHS elements (and trust me, the results are *very* unpredictable). The content being squished should not be a problem as our content is usually very narrow anyway (only single words and sentences). -- Prince Kassad 21:06, 26 January 2010 (UTC)
    There's a way to have the contents flow around the LHS ToC? How? I don't see an option for it in WT:PREFS... --Yair rand 22:10, 26 January 2010 (UTC)
    There's no option for it but you can enable it yourself through your monobook.css, if you're experienced enough in CSS. -- Prince Kassad 22:18, 26 January 2010 (UTC)
  5. Oppose Most scripts are read from left to right. The ToC should be the first thing you see on a page overloaded with information, and having it on the left seems to be the most sensible thing to do. Jamesjiao → T ◊ C 21:13, 26 January 2010 (UTC)
  6. Oppose EncycloPetey 16:59, 30 January 2010 (UTC)
  7. Oppose Razorflame 17:00, 30 January 2010 (UTC)
  8. Oppose, though I'd probably support having the ToC collapsed by default (as Yair rand proposed, as an option, at the very beginning) instead. --Thrissel 22:14, 31 January 2010 (UTC)
  9. Oppose --Dijan 07:00, 7 February 2010 (UTC)
  10. Oppose Ƿidsiþ 19:59, 8 February 2010 (UTC)

Abstain

  1. Abstain —Internoob (Disc.•Cont.) 04:10, 24 January 2010 (UTC) until it is clear to me how we are going to handle right-floating elements in the same entry.
  2. Abstain with Internoob.​—msh210℠ 16:43, 8 February 2010 (UTC)
    See also WT:GP#RHS_elements_in_IE8. Things need to be ironed out before this is enacted.​—msh210℠ 18:49, 10 February 2010 (UTC)

Comments

  • Could I point out that although there are lots of alternative possibilities for fixing up the problem of the ToCs pushing the entire page down, there is virtually zero chance that any other than this one could actually pass? Basically, this vote is not about what's the best way to fix it (left-hand float, default collapsed, invisible, or something else entirely), it is whether to either have the ToC float to the right or keep it the same way as we have now. If someone comes up with an better solution than this, they could start a vote for it after. As it is, LhS ToCs/collapsed ToCs are not likely going to happen (though I would support either of them over the current situation). --Yair rand 22:24, 31 January 2010 (UTC)
As you can see, there isn't a lot of chance this will pass either. So we're left with the current situation. I wouldn't mind collapsed/collapsible ToC on the left, but I'm firmly set against it being on the right side, as are a number of other people. The right-hand option as a "solution" is just awful. --EncycloPetey 22:30, 31 January 2010 (UTC)
What would you suggest? Certainly a vote could be started for setting ToCs to float to the left by default, but is there any chance it would pass? --Yair rand 22:40, 31 January 2010 (UTC)
(Another option would be to start a new vote for deciding which way to set the ToCs, having all the options available using the w:Schulze method of voting.) --Yair rand 22:45, 31 January 2010 (UTC)
This proposal is simply about attempting to address the needs of those unregistered and uninformed registered users primarily interested in the English-language portion of entries by increasing the chances that some definitions would appear on the landing screen, "above the fold". Presumably all registered users would have the option of setting the ToC some other way (collapsed, lhs, absent). As we are condemned by the software to have the site navigation on the far left, and as, for English and most languages, folks expect content to be left justified, we are left with only the right side to place entry-navigation aids, such as the ToC, without pushing the top-language definitions off the page.
  • Are those opposed saying that this user population (those interested in English definitions and usage) would not benefit from this change?
  • Or are they concerned about the consequences for some other population of users?
I'm beginning to think that Wiktionary is trying to do too much. It does not seem feasible to satisfy the simple needs of native English speakers (for definitions and basic usage information) and also the needs and desires of the diverse other communities interested in various aspects of English or other languages. Without a large population of native speakers, I don't see how the quality of English definitions can ever be improved beyond Webster's 1913. I suppose this doesn't have to be a problem if we don't care about the relevance of the translations to the meanings the English words now have, as opposed to the ones they had a century ago or the ones resulting from inadequate attempts at modernization that some basic entries have undergone. DCDuring TALK 23:17, 31 January 2010 (UTC)
Well we could have the ToC collapsed by default, but I don't think people will go for that. As an aside, registered users can now right-justify the ToC using the normal Preferences (go to the "Gadgets" tab). Maybe we could do some scripting so that only the languages were shown in the ToC (just L2's). This would make the ToC much shorter (allow for more English definitions on the landing screen) and focus users on the fact that we divide the page up by language. This is quite easy to do (Conrad already did it for his experimental reformat preference). Would this be popular? Maybe more brainstorming and then a Schulze-style vote. --Bequw → τ 00:24, 1 February 2010 (UTC)
I like the idea of ToC including only language names very much. --Vahagn Petrosyan 00:28, 1 February 2010 (UTC)
So do I, especially if we get rid of the numbers in the ToC too. It's still a little too large in some entries though, even with only showing language, so I think we'll still have to float it to the left of right. --Yair rand 05:08, 1 February 2010 (UTC)
Getting rid of the numbers is easy, and something we ought to do IMO, but will not help much. Showing only the language sections would be good, except for English-polysemic words, where the POS is helpful. Further aggravating this is that the POS can be, according to our ELE, L3 or L4 depending on the number of distinct etymologies: this prevents (AFAICT) CSS-based (i.e. sans JS) hiding of the TOC at the deeper-than-POS level, which sounds like a good idea to me.​—msh210℠ 16:59, 1 February 2010 (UTC)
  • I am still wondering whether folks are voting for what they want or whether they are voting for what is best for unregistered users (in the default settings). I have been under that impression that almost any reasonable option could be set in Gadgets (or monobook), so personal preferences should be close to irrelevant. DCDuring TALK 00:43, 1 February 2010 (UTC)
    Agreed. --Bequw → τ 13:50, 1 February 2010 (UTC)
    Well, you can hang around wondering or you can start a discussion where you ask people about it. Hanging around and wondering (and repeatedly stating this) accomplishes nothing except to cast unwarranted aspersions on others in the community. --EncycloPetey 03:55, 3 February 2010 (UTC)
    Well, I admit to doing it myself. It is hard not to without good data (anyone got a usability lab lying around?). Maybe someone could create a gallery of screen shots of what a user would see on a variety of pages with all of the ToC options. We could use a page with few headers (small ToC), a page with the median amount of headers (derived using traffic stats), and a page with lots of headers (large ToC). --Bequw → τ 04:56, 3 February 2010 (UTC)
    Okay, here we go. Take a look at the following Wiktionary screenshots with various table of contents formats:
--Yair rand 02:40, 5 February 2010 (UTC)
In IE8, the addition of another RHS element to an entry with more than one already makes the page display funny, with blank spots in between the tops of the elements, like in eagle. —Internoob (Disc.•Cont.) 04:15, 10 February 2010 (UTC)
I've updated the preference gadget so that IE won't move it to the RHS. One can still do it manually in their own css file, but it won't be across the board.--Bequw → τ 21:34, 23 February 2010 (UTC)

Decision

Wikious
Boobota
Sagapedia