The center for all Wikitravel images!

Tech:Table of contents makes too much whitespace

From Wikitravel Shared
Revision as of 02:55, 11 May 2007 by (Talk)

Jump to: navigation, search

Moved from en:Wikitravel:Bug reports by Evan


What happens

The table of contents in a page makes a lot of whitespace right at the beginning of an article (see for an example). It would be nice to move it to the left nav area or to a new nav area on the right side of the screen. See en:Wikitravel talk:Table of contents location for more discussion on the issue.

It would be nice to make this optional per-language version. For example, de: users seem really opposed to it and are happy with other solutions for working around the whitespace problem. --Evan 16:41, 17 June 2006 (EDT)

There's now a review version up for consideration. It's in very raw form and I'm still testing it, but it's worth looking at. Compare: --Evan 13:03, 29 June 2006 (EDT)
There's now a review version with twist-down menus on . --Evan 12:15, 16 November 2006 (EST)
Wow! Looks sleek. I like it. Maj 12:57, 16 November 2006 (EST)
It's all messed up in IE 7. Check out this screenshot and this one. The actual article is pushed down below the TOC and left side menus. I like the look in Firefox, but have to say it's a no-go until the IE issues are resolved. -- Andrew Haggard (Sapphire) 16:02, 16 November 2006 (EST)
There are some fairly big and small problems in Firefox that may or may not be caused by the TOC alignment on Review. Most notably, if you click "edit" the edit box is no more than two lines in height. I'll upload a screen shot under Image:Reviewedit.PNG. The other problem I noticed is if you click on the Cincinnati guide in Review. Scroll down to the second image, that's directly below the "Please" infobox. Part of the text gets covered up by the second image. -- Sapphire 16:14, 16 November 2006 (EST)
Agreed about the IE7 stuff -- I'll see if I can fix it. The edit-box problem was unrelated to the menu -- I just hadn't kept the review site code up-to-date with the live site code. I've fixed that now. The Cincinnati page was built to have a whole bunch of stuff on the right side of the page. We're going to see some other alignment and layout problems due to this change; I think we can work around them. (They're the same problems you see now when you close the ToC on the live site, btw.) --Evan 11:33, 17 November 2006 (EST)

New ToC style

There's a new, new review version with the text wrapping around the ToC. I think it looks better on most pages, like, but it looks awful on pages with a quickbar, like . --Evan 13:06, 7 December 2006 (EST)
I don't like how it pushes the lead photograph below the ToC. Anyway to fix that? -- Andrew Haggard (Sapphire) 14:38, 7 December 2006 (EST)
Also in IE it creates far more whitespace than previously. Additionally, 'arrows' come up on IE, but if you close the 'arrows' the whitespace decreases on IE. A quick look over pages with quickbars isn't too bad so I wouldn't be too concerned with that. -- Andrew Haggard (Sapphire) 14:48, 7 December 2006 (EST)
I personally think the TOC on review: looks ugly on most of the articles, we had to reformat most articles to look good. One solution would be to make a wider quickbar or to hide the TOC by default. And it should be possible to hide it on the printable version, too. The best solution would of course be to include it in the toolbar on the left, if that is possible. --Flip666 16:57, 15 February 2007 (EST)
I think putting the ToC in the left-hand navbar is the best place, but you and I are in the minority on that one. --Evan 14:11, 15 March 2007 (EDT)

New, new style

So, I've created a new, new style that's visible on review, see for an example. It puts the ToC in the upper-left-hand corner of the content area. This doesn't interfere with the navigation area, and since we almost always put our quickbars, images, etc. on the right of the page, it doesn't interfere with them, either. I need to figure out some CSS magic to pull the "twist down" arrows out to the right of the ToC entries (so they line up correctly), and tighten up the whitespace inside and outside of the box. But it's where I'd like to go with this.

The only pages where I've seen this cause a problem is when there's a very short lede (first paragraph) and a long list of regions or cities which wrap around the end of the ToC. I'll see what I can do to fix that. --Evan 14:11, 15 March 2007 (EDT)

I, personally, like it. -- Sapphire(Talk) • 17:19, 15 March 2007 (EDT)
It does not look too bad, but only because the first paragraph fits almost exactly to the (collapsed) contents. But e.g. on it looks very bad. I personally think we'll have to hide the contents in the sidebar, if that is possible? Have a look at --Flip666 writeme! • 21:06, 15 March 2007 (EDT)
It's the least bad attempt yet, but I still think it's bad. Is it really necessary to put the TOC above the intro paragraph? Why not keep it right after it with a dedicated block of space, as now, but just in a more condensed format? Also, while the idea of "click to expand" is very good, the current uneven list with big honking triangles is not at all obvious: it makes it look like, say, "Eat" is particularly important for some reason. Headings with and without subheadings should be on the same level, and boxed plus and minus would be nicer: see eg. this for an example of how it should be done. Jpatokal 15:04, 23 March 2007 (EDT)
IMO, the ToC displayed at is aesthetically an improvement on the current version but a leap backwards in so far as it does not allow the position to be customised. I think that you need to be realistic and recognise that, since beauty is in the eye of the beholder, a humna will usually do a more elegant job of placement than an algorithm.
My suggestion would be to have the ToC appear automatically by default in a position to the right of the left hand margin (ie where it is in the Paris example) BUT immediately below the heading of the first section [ie NOT competing with the introduction (and often an infobox)] but then also allow its position to be customized by specific intelligent human placement if that default position produces ugliness or excessive white space on the page. ...Gaimhreadhan (kiwiexile at DMOZ) • 00:43, 24 March 2007 GMT
  • Get rid of the extra whitespace on the left side of the new TOC (I see a margin of about 10 pixels). Following the CSS of en:Template:TOCleft should work.
  • Shrink the expand/condense images.
  • I like The idea suggested above about having the TOC display by default next to the first heading, rather than next to the intro.
Otherwise this new version seems good to me, and something that would be nice to see enabled. -- Ryan 06:19, 24 March 2007 (EDT)
The main reason I want it flush with the first section is because I eventually want to have optional split-page navigation of guides by section (see en:Wikitravel talk:Article templates#The best Wikitravel articles are too damn long and When guides are split into different pages, what is now the Table of Contents will become the menu for navigating between the the section pages. If there's only one section on the page, putting the ToC at the end of that section is going to make it difficult for people to find, and hard to navigate quickly between parts of a guide.
I will update those split-page examples to use the same ToC placement as on review. Actually, I should probably start a feature request here on shared about it. (update: Tech:Optionally split long guides into one page per section.)
As far as a human override: I'm a little nervous about that, since it means that essential navigation bounces around to different parts of the page. It also requires considerably more work on my part, because of how I'm moving the ToC. -- I'm not even sure it's possible. --User:Evan 10:16, 24 March 2007 (EDT)
(Responding to a bunch of things) I'd prefer +/- bullets for collapsing sections; the twirling triangle is a Mac-ism that isn't as clear to the unwashed masses. :) The Munich example does some ugly things to the layout of the text if your font size and screen geometry aren't just right, leaving white space on the left and/or right if the second section has to wrap around boxes on either side. (At least it does in Firefox and Konqueror; Safari's OK, and I don't have IE handy). I really don't like the idea of relocating the TOC on a page-by-page basis; I can tolerate typesetting no-no's like left-aligned text having to follow a moving left margin, but standard UI elements should not move like that; functionality trumps beauty in UI decisions. - TVerBeek 12:18, 24 March 2007 (EDT)

I've had a re-think on ToC's - especially after reading the comments here.

As I see it, you're trying to achieve three things with your new ToC:-

1) Make the page look better.

  • I think you've achieved this first goal which is not a trivial one - it will be important to the price of advertising on the page and users (subconsciously at least) devalue the authority and value of scrappy looking pages. In this regard, I suggest:

a) reduce considerably the padding inside the left and right margins of the box so that it becomes considerably narrower (I congratulate you on wrapping individual headings within the ToC already and using two smaller fonts for headings and sub-headings which are both a big improvement).
b) increase the padding outside the right hand ToC border.
[If you expand the subdivisions of the ToC at and then scrutinise things you will find that the right hand border of the ToC is then butting right up against the bullets of the list in "

  • The Ile de France is the region surrounding the French capital, Paris.
  • The North is one region where the world wars have left many scars. It includes Nord-Pas de Calais, Picardie, and Haute-Normandie...etc, etc"

2) Make the ToC more helpful and usable for users

  • Here you need to default to the most useful configuration for naive and/or non-perceptive users. This means you need to:

c) default to ToC fully expanded right down to third level sub headings
d) Retain the ability to "hide" and "expand" the whole ToC fully (with the default condition set as "expanded")
e) Have the word "Contents" moved inside the ToC, keep this word "Contents" black not blue and centre it in the largest font you use in the ToC CSS
f) Have the following phrase in blue and smaller font and centred just below this: "(hide for printing)" If you do this then you will remove the need for custom ToC placement altogether since experienced and/or perceptive users will twig that they can save paper by hiding the ToC before printing
g) retain the arrows but have them in outline with a minus sign visible within to denote that they can be clicked to collapse a particular heading [-] and a plus [+] inside the arrow to denote it can be expanded if clicked.
h) for most users the directions the arrows point are presently counter intuitive: they should point downwards to denote that one can "drill down" or expand a heading and point upwards to denote that one can go up or contract a section. Arrows facing horizontally are confusing to most and I for one did not even realise they were clickable until I did some playing around - I thought they were just highlighting an important section...

3) Do a bit of future-proofing for clever stuff to come.

If you follow my suggestion, then you will have substantially eliminated the need for customised ToC placement!
...Gaimhreadhan (kiwiexile at DMOZ) • 22:43, 25 March 2007 BST

Here is my question. Why have we abandoned the idea of putting the ToC on the right? The reason we got into trouble last time was not because folks objected to having the ToC on the right. It was because the ToC placement was screwing up the image-placement tactics that had been adopted to take care of the too-much-whitespace problem. As I see it, wherever we place the ToC, it is going to screw up the placement of the lead image anyway. So why not have a fresh look at the ToC placement on the right? Especially now that we are going to make it a per-language change, so that if the German Wikitravellers do not want to adapt to the change, they don't have to?

The reason I want to have the ToC on the right is that once we have the ToC safely out of the way, we can get it to float. That will be much better for navigation. — Ravikiran r 03:17, 26 March 2007 (EDT)

I abandoned the idea of putting the ToC on the right, inside the content area, because it interfered a lot with the layout of most pages (quick bars, images tend to go on the right side). I don't have a problem with moving it back there if people have the energy to reformat the pages.
Putting the ToC on the right in a separate column had a lot of detractors, not least the people at Internet Brands. That's the most likely spot for a column of text ads in the future, so they asked that I find another place to put the ToC.
Finally, the suggestion that there'd be an exception for de: has lost some currency since the suggester is no longer active on Wikitravel. --Evan 09:43, 26 March 2007 (EDT)

And again

A new version is up on Wikitravel review; see There's still one layout bug -- toc entries that are longer than one line wrap funny -- but otherwise I think this meets a lot of the requirements from above. I've fixed up the whitespace inside and outside the box so it doesn't take too much space nor bump into list items. I've replaced the arrows with pluses and minuses (putting a plus or minus over the tiny arrowheads didn't look very good), and I've made them align to the left of the text. I didn't add a "hide for printing" note; I'm just going to make it so the printable versions don't have a (useless) ToC.

Please give your comments. --Evan 12:04, 5 April 2007 (EDT)

Very quick first impressions: looks good to me, with the caveat that the plus sign takes up a lot of space (it would be better if it was smaller) and the second-level indents could be deeper as it's not completely clear that they are sub-headings. These are minor nitpicks though - the left alignment with text flowing around it seems like a good improvement. -- Ryan 12:36, 5 April 2007 (EDT)
I think it's the best version I've seen. The deeper indent will mean a wider column, so it's a trade off there... Maj 12:38, 5 April 2007 (EDT)
I was about to suggest indenting too. Two spaces should be enough. It looks like the words are wrapped, so it is not that big a trade off. Otherwise this looks production ready. — Ravikiran r 12:40, 5 April 2007 (EDT)
I like it, but there's one thing that slightly bugs me. If you expand the "Get around" section for the USA. There's the sub-header "By Recreational Vehicle (RV)" that looks somewhat weird. Explaining why is a bit difficult, but is it possible to possibly widen the ToC a bit so that the sub-header will fit perfectly, rather than take up two lines? It's the same thing for France under "Get around" you'll see a sub-header about getting visas or something, which confused me because I thought it was a top-level header. If this can't be easily fixed or would cause more conflicts please write my complaints off so we can get this done and over with. -- Sapphire(Talk) • 13:19, 5 April 2007 (EDT)
I'm probably missing something from the previous discussions but can't we just have the TOC hidden/collapsed by default on both the online and print versions? I guess it'd solve most of the whitespace issue, which by the way, doesn't bother me at all. And honestly, I know you've devoted time and creativity to changing it, but I personally like the "old" version better than any of those new proposals. Or maybe I've just gotten used to it anyway. -- Ricardo (Rmx) 14:08, 5 April 2007 (EDT)
I'm kind of with you. I really don't have a problem with the ToC as it is, but I'm not opposed to changing either. Also, I think this is going to be a wiki-by-wiki decision so pt: won't be required to adopt it, right Evan? -- Sapphire(Talk) • 14:15, 5 April 2007 (EDT)
I'd rather not do that, if possible. It makes maintaining the different versions a lot harder for me. --Evan 14:57, 5 April 2007 (EDT)

I think this new latest version is great. Only things I saw and didn't like were already mentioned above... 2nd level needs more indenting, and + signs slightly too big... but I think this is much nicer looking than the current TOC. Would also vote for it being collapsed by default... – cacahuate talk 21:00, 5 April 2007 (EDT)

I like it a lot! Excellent job. I think this is production ready. I agree with some of the comments, but they are very minor and can be fixed as we go along. The funky wrap on long lines does not look that great, but again this can be fixed and improved upon later. The massive white space is gone. I give two thumbs up! Great job Evan. -- Xltel 21:48, 5 April 2007 (EDT)

The "collapsed by default" thing would make a nice preference since a lot of people would probably rather NOT have it collapsed (myself included). Assuming you're using Javascript then it should be reasonably easy to just set a cookie to remember the collapsed-or-not state, but if you're ready to push this live soon then that might make a nice enhancement for later. A more difficult issue is going to be getting all versions to give their OK on this - any thoughts on how to roll this out without starting a revolt? Perhaps an email to the admin list asking admins to add their comments and post a message in the language-specific pubs requesting feedback? Maybe set a planned rollout date of 01-May so enough people can chime in? -- Ryan 00:43, 6 April 2007 (EDT)

It's really hard to get positive sign-off for anything in the Wiki world. It's also not part of our technical infrastructure policy. The main thing I'm concerned about is that everyone gets a chance to comment, that no one feel that their voice wasn't heard and that they didn't get a chance to respond. I'll send an email to the admin-list and I'll leave a message in all the of the various pubs (although it's really the liaison's job to do that...). I don't think waiting until May 1st is necessary or even a good idea. I'd like to make this change next week, Tuesday or Wednesday. --Evan 10:26, 6 April 2007 (EDT)
I might be wrong, but there won't be a revolt over the size of the indents. The last time there was a revolt because the placement of the ToC was upsetting the formatting of all articles. That problem will occur even now and quite frankly, it is not a big deal. The changes to get the formatting in shape are quite obvious and can be handled in the wiki way. The key thing is to get a buy-in. The problems that occurred the last time was more to do with other issues. - Ravikiran.

A distinct improvement, Evan!
Except for one flaw (see below) you have achieved the first objective to Make the page look better.
You are also well on the way to the second: Make the ToC more helpful and usable for users
In my view, this is what remains to be done:
1) Change the word "contents" to either "Contents" or "CONTENTS" and move it inside the ToC box (not abandoned forlornly and semantically orphaned outside), keep this word "Contents" black not blue and aligned left in the largest font you use in the ToC CSS
2) You need to default to the most useful configuration for naive and/or non-perceptive users. This means you need to:
a) default to ToC fully expanded right down to third level sub headings
b) Retain the ability to "hide" and "expand" the whole ToC fully (with the default condition set as "expanded")
and either
c) Have the following phrase in blue and smaller font and centred just below the aligned left Contents: "(hide for printing)" If you do this then you will remove the need for custom ToC placement altogether since experienced and/or perceptive users will twig that they can save paper by hiding the ToC before printing
d) Default to fully expanded on both display and print but initiate a user-settable preference under "skin" (perhaps label it the "treesaver" skin), that hides the ToC when printing.
e) make sure that the appearance of the [+] (expand) and [-] (contract) symbols changes when a user hovers the mouse over them. My suggestion would be to have them slightly smaller in appearance to begin with and then slightly enlarge and in bold font when they are mouse-overed...
Gaimhreadhan (kiwiexile at DMOZ) • 08:32, 6 April 2007 (EDT)
Responses here: 1) good idea. 2a) I think that expanding the ToC fully by default would take up too much space, without much benefit. It's not crucially important that newbies who aren't familiar with twist-down tree controls (which is a pretty small segment of the computer-using population) click directly to second-level headings. If someone can't figure out how to click to "By boat", they'll still be able to click to "Get in". 2b) I'm not excited about having the whole ToC collapsible. In a split-pages scenario (Tech:Optionally split long guides into one page per section), the ToC becomes essential navigation between pages, and hiding it is a bad idea. 2c) I'm going to make it so that the ToC never shows up in print, so this is unnecessary. 2d) same. 2e) I'll try, but again I don't think it's a tragedy if a novice user can't expand the ToC.
What I will definitely do: make the plus and minus smaller; make the second- and third-level headings indent farther; make the text wrapping work a little better; make the ToC a little wider to make text wrap less frequently. --Evan 10:36, 6 April 2007 (EDT)
Uh-oh... almost May 1st! I want my new twisty menus! – cacahuate talk 21:54, 30 April 2007 (EDT)
OK, OK! It's rolled out as of now. Comments welcome, suggestions more so. --Evan 11:22, 10 May 2007 (EDT)
I'm late to this discussion - didn't even know it existed until the roll-out today. So I apologize if it seems like I'm wandering in and taking pot-shots at the hard work you've already discussed and done. I don't like the new ToC. This, for example, seems so busy to me - three sections side-by-side clamoring for my attention as I first glance at the article (four, if you include the standard navbar at far left). That sudden overload puts me off as a reader - I don't know where to direct my attention. Also, as already mentioned, the Understand section on most articles comes running up to get squashed between part of the ToC and the lead image. Visually, it's a really bad first impression to make.
To add something other than complaints to the discussion, here are my two suggestions.
1. Horizontal ToC. Put it left-to-right under the line that underlines the name of the article. Unobtrusive, out of the way quickly (and good for printing) but there if the reader needs it. Shouldn't take more than two lines for any article, one for most. Begin the intro text, lead image and article space below that.
2. Ditch the ToC. I doubt this will be a popular suggestion. But given that we have a standardized format and all significant articles are held to it, why do we really need a ToC? Look at any printed book travel guide - they explain their section structure at the beginning, but they don't have a ToC before every individual article in the book.
Gorilla Jones 12:49, 10 May 2007 (EDT)

So I'll be honest: once little bugs in the current version of the ToC are fixed, it's going to plummet to the very bottom of my TODO list. It's been a thorn in my side for a year now, and we've had really, really, really long chatter about it. We've tried the ToC in just about any place possible on the page, and this has been the spot that's gotten the most "I like it!"s and the least "I'll kill you!"s.
I don't think the horizontal ToC under the page title will work, since that's where we put geographical breadcrumbs. I'm mixed about ditching the ToC entirely; I think that when we optionally split long guides into one page per section we'll want to have that kind of navigation between sections.
I understand your concern about making a good first impression, but I think we're making a much better first impression than when we had acres of whitespace above the fold (like here). --Evan 13:21, 10 May 2007 (EDT)
Well, my fault for being unaware there was a discussion underway. I know it's brutal to build consensus. Frankly, this is an "I'll kill you!" for me, but maybe I'm alone in that. It's like trying to read a novel written on the Tokyo skyline - I look at it and I have to force myself to read any further. The problem in that San Diego example is resolved as soon as you put a nice lead image in the article - then the white space isn't apparent until the user has already read the intro and looked at the image, and the white space is reduced even more if you use small fonts in the ToC as with the new design. This, however, makes every article equally problematic, and I'm not sure what to do to make them look any better. Seems like we've solved a problem some articles have by giving all articles a problem.
Is it at least possible to not let the Understand rise up like that - force it to stay below the ToC? I still don't like having intro text squashed between ToC and the lead image, since we're now starting the article by asking the reader to read from the center of the page - and then switching to asking them to read from the left of the page - but if that's the way it need be, the less squashing, the better. Gorilla Jones 16:18, 10 May 2007 (EDT)

When it happens

  1. In Firefox and Safari, the bullets do not line up properly in the space to the right of the new TOC. They are in the margin rather than at the margin, and on the OS X version of Firefox 2 they're actually touching the border of the TOC. e.g. en:Estonia - TVerBeek 11:55, 10 May 2007 (EDT)
  2. In IE6, the TOC subtopics are all displayed at first, even though the twist-controls say "+". It takes 2 clicks to close them (one to "open", the next to close). - TVerBeek 11:55, 10 May 2007 (EDT)
So, you shouldn't see bullets at all. Can you force-reload a page so you get the new version of the CSS file? --Evan 12:38, 10 May 2007 (EDT)
I think he does not speak about bullets in the TOC but next to it. See de:München. If your browser window is wide enough the bullet list in the first paragraph will be next to the TOC. The bullets are too much on the left. Make your browser windows smaller so the list will move under the TOC, then you can see how it should look like. If you want, I could make a screenshot. --Flip666 writeme! • 12:46, 10 May 2007 (EDT)
Ah. Yeah, could you? I'm not seeing it. --Evan 13:21, 10 May 2007 (EDT)
OK, I think I fixed the IE problem, and I've put in a little numeric code to force the reloading of the .js and .css files that were modified. I'll see if I can do something about the bullet points in the article text. --Evan 13:21, 10 May 2007 (EDT)
Yes, the IE problem is fixed. The bullets/margins issue is illustrated at Image:bullets-n-margins.png. Whether it's because of a CSS reload or what, the problem is less pronounced on Firefox/OSX now than it was at first (the bullets are no longer touching the TOC), but there's still a rendering glitch there. It also shows in IE6 and FF/Win. I recall that there's a CSS attribute that controls which side of the margin the bullets appear on; maybe that needs to be hard-coded to "inside" rather than letting the browser guess? - TVerBeek 16:36, 10 May 2007 (EDT)
Wow! Nicely illustrated! I'll see what I can do... it's a very interesting problem. --Evan 17:09, 10 May 2007 (EDT)
Ha, I am too late. Thanks, Todd! Exactly what I meant. --Flip666 writeme! • 17:28, 10 May 2007 (EDT)
The keywords __TOC__ __NOTOC__ etc. do not work. See my de: Userpage. On en: it seems to be ok, see here, but maybe only because it does not have so many headlines. --Flip666 writeme! • 21:16, 10 May 2007 (EDT)

TOC and viewing differences

Well, I think the new table of contents looks great. The only problem I see is that it now appears at the top when viewing differences, pushing the differences over so that one has to sidescroll to see everything. Can we suppress the TOC when viewing differences, as we did before? Or simply push it down below the differences into the article where it would normally appear? 17:43, 10 May 2007 (EDT)


Purely an aesthetic-preference suggestion, not a bug: If the word "contents" (or the language equivalent) at the top of the TOC box were omitted (or moved inside the box if we must, but I don't think the label is necessary), the top of the TOC box would line up with the top of the first line of text. I would find that more pleasing to the eye than having it offset downward as it is now. - 22:51, 10 May 2007 (EDT)

What should happen

How to fix it



In other languages