As things stand, I see no way to get a full table of contents for a page with a banner, short of editing it to remove the banner. Have I missed something? If not, can we add one?
For many pages, this is not a problem, but for a large complicated page like Shanghai it does seem to be. Lots of sections there have many subheadings — "Get around" currently has 13! — I've already removed some and will do more, but then I've also added some. There should, I think be some simple way to get at those for easier navigation.
Put a "Full contents list" into the banner? Or just "TOC"? Some sort of icon? Whatever we do should be fairly obvious; regular editors could learn control-shift-right-click to get a contents menu, but we shouldn't have to and in any case that would be of zero value to most readers. Pashley (talk) 20:15, 16 May 2013 (UTC)[reply]
Or just a perhaps-not-well-thought-out suggestion, but for cases where there are a lot of subsections, we could put a sub-index at the top of each section in the article body, using the same tocbox format:
I think having a sub-index at the top of a subsection might be the best way to go for now. The banner doesn't display the full contents well, and for guides like Shanghai, it would probably make the TOC box so large it would overlap with the title (the TOC box starts at the bottom and moves up). Although, any sub-index would have to be set up manually. The Mediawiki software only allows the __TOC__ command to be used once per page. -Shaundd (talk) 04:46, 22 May 2013 (UTC)[reply]
I think ideally we'd like to have a CSS dropdown on each ToC link in the banner, but I don't know how feasible that is. LtPowers (talk) 12:55, 22 May 2013 (UTC)[reply]
If that (CSS dropdown) means what I think it does, that would be a good solution. There are travel topics which are now a bit tedious to navigate with the truncated single level TOC. Other than that, the banners really give the articles a fresh new look. • • • Peter (Southwood)(talk): 09:13, 10 June 2013 (UTC)[reply]
...or we could revisit the "section heading / banner" thing and see if perhaps there indeed is a workaround there. One like Nicholas proposed (below) would come in handy in case there are many subsections:
Again, I think we come up against the current technical impossibility of automatically populating the subsection list. This is not something that would be feasible to implement and maintain manually. Texugo (talk) 14:14, 10 June 2013 (UTC)[reply]
I guess this will be a problem for any solution that would be based on generating a TOC out of headings in a article section, which is what I understand all of the above proposals are. PrinceGloria (talk) 16:13, 10 June 2013 (UTC)[reply]
Yep. I think it's pretty much idle daydreaming unless someday a new version of mediawiki comes along that allows multiple TOCs to be generated and manipulated. Texugo (talk) 17:10, 10 June 2013 (UTC)[reply]
I may be the only one, or close to it, but I find drop-down menus obnoxious. For example, moving horizontally, point at "Eat" and you get a vertical menu with "budget", "mid-range" "splurge"; the screen is cluttered with stuff you may not want, especially if you are just going past Eat to reach another main heading or you just want to click on Eat. For that matter, I do not like the TOC with little + signs to expand sections; just show me the damn TOC already, don't make me mess about before I can see it. Again, this may well be a minority opinion.
Given those preferences, the options proposed so far come out in this order:
section banners, obviously far the best as a user interface. What do we need to make them practical?
my original suggestion; a "full TOC" button in the banner
drop-down menus
As I see it, any of these might be fine as a quick fix if it is easy to do, but only the first is worth any significant effort. Pashley (talk) 17:43, 10 June 2013 (UTC)[reply]
As I was saying, none of those options are possible at this time because Mediawiki software does not permit any method of automatically creating secondary or additional TOCs with javascript, css, or anything else. Texugo (talk) 17:49, 10 June 2013 (UTC)[reply]
Well we managed to get the top-level headings displaying at the top; seems like it's at least plausible that we'd be able to finagle the lower-level headings to display as submenus thereof. We wouldn't need "secondary or additional" TOCs in that scenario; we'd simply be using the single primary TOC differently. To Texugo: There are ways of implementing dropdown menus that alleviate your concerns; after all, windowed operating systems have been doing just that with considerable success for decades now. LtPowers (talk) 18:01, 10 June 2013 (UTC)[reply]
Pashley, you aren't the only one. Without having seen it, I'm inclined to think no subsection links are better than subsection links as drop down menus, because I have trouble imagining how they would avoid looking ugly and potentially interfere with mouse navigation. But that is of course without having seen it. --PeterTalk18:17, 10 June 2013 (UTC)[reply]
While we are waiting for a better solution I have made an alternative page banner template {{Altpagebanner}} which omits the horizontal ToC which I am using on articles which really need a full ToC to be reasonably user-friendly. It could be implemented in the original page banner template by adding an optional parameter to turn off the ToC, but my template-fu isn't up to it, and just forcing a ToC is ugly. I really like the page banners, but this is something that needs short term and long term solutions. • • • Peter (Southwood)(talk): 14:21, 12 June 2013 (UTC)[reply]
That's debatable. Using a second template instead of parameterizing the main template is confusing and makes maintenance much harder. Interface-wise, retaining the page banner but not the TOC feature violates the expectations of the user and is confusing both for users and editors not familiar with the change. And all this for an extremely limited benefit -- the ability to jump straight to the "By bicycle" section of "Get around"? It's not like it's hard to find from "Get around" -- how many readers do you think will take the time to expand the TOC just to go straight to a subheading? LtPowers (talk) 15:27, 12 June 2013 (UTC)[reply]
I'm with LtPowers. I think the disadvantages far outweigh the advantages here. I'd rather see us keep to a single template (without ability to turn off the horizontal TOC), so things are presented consistently. The ability to jump straight to subsections will be neato when we have it, but I think it's being a bit overrated in terms of how often people actually use it, and I don't think it is essential. Texugo (talk) 15:42, 12 June 2013 (UTC)[reply]
edit conflict *** I second LtPowers' reservations. To me, even though I had much experience with the MediaWiki engine, it wasn't even quite obvious that subheadings can be accessed by clicking the "+" in the contracted TOC. I believe it adds confusion and limits the benefit. If your sections are vast and some subsections are really important, why not either elevate them to a higher heading level or link from the body in the introduction. If you fear the user may not be able to navigate a section, why not give it a lead with links to further subsections within it? PrinceGloria (talk) 15:44, 12 June 2013 (UTC)[reply]
Could you all please take a look at the problem before deciding that a solution is not necessary? Go to Scuba diving, and without using the expanded ToC, find the entries on any 3 randomly chosen countries of your choice. (Make your choices before starting). Then do the same using the expanded ToC. Then come back and tell me if you think there is a need for a temporary measure or not.
I did mention that I don't know how to parameterize the main template, so I didn't mess with it. I quite agree that it would be better that way, which is why I suggested it. • • • Peter (Southwood)(talk): 16:37, 12 June 2013 (UTC)[reply]
I was mainly addressing Shanghai. Scuba diving is indeed hard to navigate, which is an indication that it needs to be overhauled. The fact that continents are third-level headings but enlarged to be bigger than the second-level headings is indicative of a serious problem in its organization. The difficulty in finding specific countries within the article is merely a symptom of that larger problem. LtPowers (talk) 17:32, 12 June 2013 (UTC)[reply]
Scuba diving could use some good ideas for re-organisation. Constructive comments always welcome. There are other travel topics with similar problems of large numbers of subsections, but fewer formatting issues. Cheers, • • • Peter (Southwood)(talk): 18:25, 12 June 2013 (UTC)[reply]
If an article absolutely must have subheaders shown in the ToC (and still, they're hidden behind that plus sign that readers may miss), I think it would be better to remove the pagebanner altogether. Having an "empty" pagebanner at the top is confusing and a little jarring. --PeterTalk18:33, 12 June 2013 (UTC)[reply]
I don't see the lack of horizontal TOC in the banner as confusing or jarring, less so than leaving the pagebanner off a few pages, which would be far more confusing and jarring to me. However, tastes differ, and if there is a consensus to leave the pagebanner off for pages that need a fully functional ToC, I would accept it with some amazement, but no big deal in my life.
I would also like to like to see the stated aims of the expedition realized;
create a clean start to the page by having a lead image and horizontal TOC at the top before the article begins
make the first impression of our guides more eye-catching
give our guides a fresh and more modern look
but not at the cost of making some pages unduly awkward to navigate, as that is not putting the traveler first.
I am suggesting the alternative page banner with ToC layout as a temporary measure, for those articles where it is functionally necessary, only until the technological problems of doing it properly are ironed out. I think the best option suggested so far is the drop down menus, but would accept any of Pashley's suggestions, as either temporary or permanent solutions. • • • Peter (Southwood)(talk): 20:04, 12 June 2013 (UTC)[reply]
I definitely agree that some pages are special and it may be necessary to show lower level headings. Scuba diving may be one, but UNESCO is one of the better examples imo; without being able to jump to individual countries, it makes the list very hard to navigate quickly. However, the examples are few. It would only be the odd travel topic. Normal destination pages like Shanghai shouldn't need TOC access to their third level headings; if it does, there may be too many of them and the article should be changed. James A ▪ talk13:39, 13 June 2013 (UTC)[reply]
UNESCO is far too long and the title is quite misleading. It would best be broken up into "UNESCO World Heritage sites in Africa" etc., per continent. If the top-level headings are not enough to navigate through the article, it is time to break it up IMHO. PrinceGloria (talk) 13:54, 13 June 2013 (UTC)[reply]
Per continent will reduce the article length, but have you counted the number of countries in each continent? Africa: 40, Asia: 38, Europe: 46, others fewer.That would be another challenge for a horizontal ToC, particularly for display on a narrow screen. • • • Peter (Southwood)(talk): 17:55, 13 June 2013 (UTC)[reply]
Don't quite understand how "UNESCO World Heritage List" is misleading, as that is precisely what it is. The article is quite long, but it would not serve the traveller if we were to break it up. Wikipedia does that, because they have a mini-description and photo of each, and it makes it confusing. The one, unified list makes it simple to find particular sites and countries, and to print. Instead of proposing splits and renames, the solution is a proper TOC. James A ▪ talk07:48, 15 June 2013 (UTC)[reply]
(od) Another possible arrangement - and again I have no idea how it would be done, but this is how my bank's website does it - is horizontal dropdowns. If you click on a top level ToC item, it highlights the active item and opens up the sub table as a horizontal ToC. This could be done for as many levels as necessary, each level only going down one row vertically. It does mean that only one sublevel of any given level can be open at a time, but that is a lesser problem. Cheers, • • • Peter (Southwood)(talk): 20:19, 12 June 2013 (UTC)[reply]
There's lots of good ideas and issues being raised here, but I think the only feasible short-term solutions are:
Leave the banner as-is and accept there won't be subheadings
Use the old-style ToC, with or without the banner, when considered necessary (as proposed by the two Peter's above).
Leave the banner as-is and use a manual horizontal list or navbox to create sectional ToC's for those instances when it is considered necessary.
Of the options above, I'd prefer 1 or 3, but can live with any of them. For #2, I agree with Peter Southwood and would prefer to see a ToC-less banner with the old-style ToC, over no banner at all.
Drop-down menus would be nice to have but I'm really not sure they can be implemented without an extension being built. The information is in the page source code, but the Mediawiki software doesn't structure it in a way that makes it easy to say that's the Get in section subheadings so you can manipulate them. It may be possible, but it's beyond my skill level. -Shaundd (talk) 05:09, 13 June 2013 (UTC)[reply]
Quickest fix would be dropdown menus, since the table of contents is already fully there. I've mocked something up here, using Shanghai and Scuba diving as examples. Can't quite get it to work in WV, probably because of CSS conflicts like an explicit rule to not display second/third level headings. It does seem like it won't be to everyone's taste, but it's quite common because of its relative simplicity. Oh, and I disabled it for narrow screens too, or there'll be overlapping sections otherwise. Section headers would be interesting and could probably work since the data is there, but will need Javascript of sorts and a fair bit of work. -- torty3 (talk) 12:18, 13 June 2013 (UTC)[reply]
Of course it could use some tweaking, but I like the mock-up. So you know how to make it automatically extract that info to build the submenus? Texugo (talk) 13:11, 13 June 2013 (UTC)[reply]
I'd be interested to hear how you built that TOC with drop-downs. It looks like some form of html and javascript that wouldn't work within a MediaWiki configuration, which is what we're constrained by. Either way, it's a neat idea. James A ▪ talk13:39, 13 June 2013 (UTC)[reply]
Entirely CSS, based on Shaun's hard work and design, and making greater use of the nested lists. So it should be able to work here, just that the Mediawiki:common.css is given priority somewhere and I can't find the conflict. There's actually quite a bit of extra code there that isn't needed at all. Anyway, check User:Torty3/common.css if you want to look at the code more carefully. Is there some place easier to test it though? -- torty3 (talk) 14:48, 13 June 2013 (UTC)[reply]
Do the dropdowns overlay the content text or push it down? The test page doesn't show. Overlay would be preferable I think, or the contents will be bobbing up and down like a yo-yo. • • • Peter (Southwood)(talk): 17:55, 13 June 2013 (UTC)[reply]
That's cool, and the test page you linked to above worked on the different browsers that I looked at (Chrome, Firefox and IE8). Re the second/third level headings, there is code in common.css that sets second level headings and below wrapped in an hlist div to display=none. Not sure of the best way to test the dropdowns though since changing the current hlist css will impact all banners. I'm away for the weekend but I can take a look at the code when I'm back to see if there are any conflicts (if it hasn't been fixed already). -Shaundd (talk) 14:45, 14 June 2013 (UTC)[reply]
I was leery of dropdown menus, but this mockup looks great. The only hitch I can think of would be when a banner has more than one row of section headers, but then again, does that really happen? --PeterTalk21:12, 14 June 2013 (UTC)[reply]
It depends a lot on screen resolution. On my home computer, which is 1366 pixels wide, Country TOCs fall onto two lines but everything else is usually one row. My work computer is around 1600 or 1700 pixels wide and I haven't seen any TOC take more than one line. I find it becomes more of an issue around a resolution of 1200 pixels. -Shaundd (talk) 23:01, 14 June 2013 (UTC)[reply]
You do realize that with the exception of "Drugs and prostitution", every one of those is a standard section as expected in a country article? Nethertlands has somewhat unusual drug and prostitution laws and enforcement policies, so I guess it was considered appropriate to make that a top level section as well.
Are you proposing as an alternative layout to the one which has been pretty much the standard for years, or just moving the one non-standard section into one of the others? • • • Peter (Southwood)(talk): 21:12, 19 June 2013 (UTC)[reply]
>> indent reset << I am not proposing anything, was just looking for an example since you asked (and I knew I saw quite a few) and found one today. And, as you noticed, we need only one (longer) heading over the "standard" ones to corrupt the banner on many screens. As concerns the solution, I believe "drugs and prostitution" could just as well go into "Stay safe" as two headings. Most countries have something unusual. A country known for unusual cuisine or drinks will probably have an unusually large "eat" or "drink" section, perhaps with subsections devoted to particularly peculiar and interesting phenomenons. Perhaps Mongolia should have a large subsection on accommodating oneself in a yurt, but I would still keep it within "Sleep". As a sidenote, I do not believe that something being a "standard for years" automatically makes it good. Things tend to stick around not only because they work, but also out of inertia. This is not a very lively or successful project as of now. I would be wary of canonizing tradition here and believe we should be open to revisiting every rule, guideline and standard at any time. Kindest, PrinceGloria (talk) 21:30, 19 June 2013 (UTC)[reply]
In this particular case your solution looks reasonable at first glance, and your point about inertia is taken, as I have made that point myself in the past. Technically all rules guidelines and standards are open to revision at any time. All that is required is a proposal, a discussion, and a consensus to change. Since anyone can make a proposal, and getting a few people into a discussion is seldom difficult, the major barrier to change is generally consensus. Getting consensus for a change can be difficult if there are a few people who oppose it, as the bias is solidly in favour of status quo. That is why I oppose uneccesarily rigid rules in the first place, particularly where there may be unforeseen consequences. Cheers, • • • Peter (Southwood)(talk): 06:17, 20 June 2013 (UTC)[reply]
To get back to the point of dropdown menus. There appear to be two possible ways forward.
Get the dropdowns to work over a folded first layer horizontal ToC (minimal long term repercussions)
Force a first level ToC with so few items that it fits in one line of text no matter how narrow the screen or how large the user magnification settings (rather difficult to decide what that would be, and requiring a major rewrite or rearrangement of almost all articles after achieving a consensus on a major change to the MoS)
My inclinations are toward the first option if it is technically possible, but it might be worth looking at the possibilities and implications of the second option as a fallback. • • • Peter (Southwood)(talk): 06:41, 20 June 2013 (UTC)[reply]
The first doesn't seem too possible, though the second seems nearly as much. I've actually disabled dropdown menus for screens that are too small since they are the ones most affected by the two layer ToC, though I suppose they might be the ones that need it the most. I've had further thoughts about section headers: while doable within the site itself, the best way worth doing would be through an extension. I've also found the conflict, which is caused by the TocTree javascript. Uninstalling that extension would also increase the speed of loading and remove the issue I noticed in File:Article without Javascript.png. Should we go ahead and request that anyway, now that all articles have pagebanners? -- torty3 (talk) 03:32, 27 June 2013 (UTC)[reply]
We talked about uninstalling the extension earlier. It also impacts talk pages, the Pub and any other page that doesn't use the banner. Not sure if anything has changed since that discussion. -Shaundd (talk) 03:54, 27 June 2013 (UTC)[reply]
Nothing in this section since June, and no change visible in the TOC display. It is November. Is there a way forward? Or is TOC handling permanently broken? Pashley (talk) 01:41, 5 November 2013 (UTC)[reply]
It looks like we have a consensus to remove the TocTree extension so long as doing so doesn't break anything else. Unfortunately, the only way to know for sure is to try it. LtPowers (talk) 20:59, 6 November 2013 (UTC)[reply]
I do not know, but we should do something. As I see it, an important piece of site functionality has now been obviously broken for many months. Pashley (talk) 02:04, 28 March 2014 (UTC)[reply]
Bump! It has been more than a year and, as I see it an important piece of site functionality has been badly broken all that time, but apparently nobody cares.
If it were actually impossible to keep the banners and have a properly functioning TOC, I'd say scrap the banners. That would be painful, but in my view it is more important that the site be easily navigable than that it be pretty. I'm certain, though, that it is possible to have both; there are several plausible mechanisms suggested above. Pashley (talk) 15:45, 10 September 2014 (UTC)[reply]
I agree it is quite annoying when you cannot navigate directly to the subsections. Would it be technically possible to keep the banner but return the old style TOC in its old place? ϒpsilon (talk) 19:28, 10 September 2014 (UTC)[reply]
I think that would be fairly easy to do, just remove NOTOC in the banner code. I doubt it is a good idea, though. We would then have redundant TOCs, one in the banner & one below; that strikes me as both ugly and a waste of screen space. Also, the old TOC had problems such as ruining the formatting of bulleted lists, which introducing banners solved (hooray!). We do not want to bring those back.
My original suggestion was a button to bring up the full TOC. Others have suggested a drop-down list attached to each main heading. Either of those might work & would be better than just putting the old TOC back in. There is discussion above.
The suggestion I like best by far is User:Shaundd's idea, adding subheadings in section banners. I think that is much better both visually and as a user interface than the alternatives. It looks harder to do technically, though. Again, see discussion above. Pashley (talk) 19:57, 10 September 2014 (UTC)[reply]
I would not want to loose the banners, this is optically a great addition to the site. Bringing back the full TOC permanently on the site would also be a backward step, however can see the advantage of getting to sub-sections easier. If we could have pull-down in the banner that would be great. Other idea, could we have a floating collapse TOC, say bottom left of the browser window? (guess would have to be a javascript). --Traveler100 (talk) 05:51, 11 September 2014 (UTC)[reply]
Do not know if this is technically possible (tried but failed to get two TOCs on one page), but what about as well as the pagebanner toc also a collapse one on the right of the page under banner level with first two lines of text. Mock-up here. Also dded some general text that should help with search engine key word results. --Traveler100 (talk) 05:48, 12 September 2014 (UTC)[reply]
I'd support happily either pull-down from the banner TOC items or a second collapsible TOC. Any of these would be a great improvement. However I can't contribute with any technical skills in this area. If we agree on usefulness of such solutions, we should discuss the plan in the pub to get general support, and include this plan into the Roadmap or even better WV wishlist at meta to attract attention of those who can help technically. Danapit (talk) 07:37, 12 September 2014 (UTC)[reply]
Hello all. I'don't know this wiki very well so i hope this is the right place to speak about that. I made a lot of new banners (more than 200) for fr.wikivoyage article. I thinks some of them, could also be added to en.wikivoyage. If someone has time to adapt them .Inkey (talk) 21:55, 26 August 2013 (UTC)[reply]
You are in the right place! :) Those banners look great - it would be good if we could somehow incorporate them here. --Nicktalk22:09, 26 August 2013 (UTC)[reply]
Great! There are some really excellent ones in there. I have gone through a little over half the list (in the order on the contribs page linked above) and put them into articles here which did not have banners yet (some of the French destinations do not have articles yet so I skipped them). If anyone wants to take over starting from Pontivy banner.jpg and continuing down the list, please vouch for it here so we don't duplicate efforts. Otherwise, I may come back and finish it a little later. Thanks again, Inkey! Texugo (talk) 22:57, 26 August 2013 (UTC)[reply]
Got to the top. Most of the banners which are not used on en: are for articles which don't exist on en: though there are also a few where there is already an alternative in use on en: I have categorized in more detail where I could and changed a few names to make it easier to identify where they can be used. A very nice assortment of banners. • • • Peter (Southwood)(talk): 15:48, 27 August 2013 (UTC)[reply]
Whoo Nice relay race ! I will continue to made banner later.In fact, i've got already lots of banners in stock (i worked on all the «A…» banner for fr.wikivoyage), but uploading… is so annoying with derivateFx (not made for batch processing).I will come later with a bunch of banners.File:BXP135677.jpgInkey (talk) 17:50, 27 August 2013 (UTC)[reply]
I find derivativeFX very slow at times, and it seems it can't deal with some licences, but it is still faster than doing it manually in most cases. As you say, no good for batches. • • • Peter (Southwood)(talk): 19:23, 27 August 2013 (UTC)[reply]
Talking about derivateFx: is it only my impression or was is changed recently? Now I have to fill in all the information (source, author, date, license) again by hand, it's not taken over from the original image anymore. Danapit (talk) 11:15, 31 August 2013 (UTC)[reply]
I found it cannot deal with some non-standard formatted pages, and possibly some licenses (particularly some PD licenses), while doing others without any difficulty. This was a few days ago, and may have changed more recently. • • • Peter (Southwood)(talk): 11:25, 31 August 2013 (UTC)[reply]
Yes, I also noticed the PD license problem. The change with the new form for filling the information happened 1-2 days ago. Danapit (talk) 11:37, 31 August 2013 (UTC)[reply]
Is it the case that the banner template inhibits images and flags from the 'quickbar' template? At present, they don't seem to be appearing for me and I'm not quite sure of the cause. --Nicktalk17:10, 14 September 2013 (UTC)[reply]
Am I right in thinking that 'disambig=yes' in the banners replaces the {{otheruses}} template? If so, is it worth using a bot to replace the latter with the former across the site? --Nicktalk17:32, 15 September 2013 (UTC)[reply]
I'm not sure the 'disambig=yes' option is for the pages themselves, but for articles where another destination of the same name exists (like Manchester). Setting that parameter as yes renders the normal 'other uses' text and places a question mark icon on the banner itself. --Nicktalk22:02, 15 September 2013 (UTC)[reply]
I would like to propose that we do not include banner images on disambiguation pages. The enormous block of bright blue distracts from the important part of the page: the links to real articles. We want users to get to their correct article ASAP, not have to search for the right link amidst bells and whistles. LtPowers (talk) 21:01, 4 October 2013 (UTC)[reply]
A handful of country articles which lack custom banners[edit]
According to a quick catscan, there are only 11 country articles left which don't have custom banners, if anyone wants a quick and satisfying little project:
All right, all right. I've been putting it off because I can't decide whether including the Tree of Life on the Animal Kingdom article is kosher or not. (Technically it's a copyrighted sculpture. But then we have Chicago/Loop which also shows a copyrighted sculpture, so...) LtPowers (talk) 23:39, 28 September 2013 (UTC)[reply]
I'm sure you can make banners far better than the ones I've made, but thanks for the compliment! =) If you'd like me to have a go, I'm more than happy to try and do something similar for the other parks? --Nicktalk00:21, 29 September 2013 (UTC)[reply]
This is an interesting project for me, as I enjoy searching for images, also outside of commons. However, the progress will be slow, I have urgent matters outside WV these days. Danapit (talk) 08:36, 2 October 2013 (UTC)[reply]
Tip on looking for images. Try FIST. Change site to wikivoyage, scan from category to article and enter article name in box, also change List option at bottom to all. --Traveler100 (talk) 08:46, 2 October 2013 (UTC)[reply]
Thank you, it works for me now. I don't see much advantage over searching for free images with google or directly at Flickr. Maybe I am wrong though and can't use the whole potential of the program. Danapit (talk) 15:14, 2 October 2013 (UTC)[reply]
Just out of curiosity, how many in-banner icons do we currently have, and what is the maximum number of them that can appear on one article? I like the idea somewhat, but I worry that the bigger the pile of icons in up in the corner, the uglier it will be... Texugo (talk) 16:56, 12 September 2013 (UTC)[reply]
There's a third as well - if you set 'disambig=yes', the banner replaces the usual disambiguation template and features a question mark icon. See it in action here. --Nicktalk13:36, 14 September 2013 (UTC)[reply]
I think it's possible that you could have them all in use at once, yes, but such occasions would be very rare. As far as I'm aware, it's just used as a replacement for the old template, though it doesn't seem to have been done en masse by a bot for some reason. --Nicktalk14:15, 14 September 2013 (UTC)[reply]
This discussion kind of died off, but it is a great idea. Any objections to me implementing it? It's a fairly minor change that won't have any immediate ramifications. If we add a category, it might also help us keep track of articles that describe worth heritage destinations as part of the expedition. James A ▪ talk09:35, 4 November 2013 (UTC)[reply]
Just a detail to adding the icons: in case we don't have an article for the actual UNESCO destination, should the icon be added to the region article, when it mentions the UNESCO destination? Example, UNESCO sites Monasteries of Haghpat and Sanahin in Armenia don't have an article, but are mentioned in Northern Armenia. I would say NO. Danapit (talk) 10:21, 6 November 2013 (UTC)[reply]
It's a difficult one. Are the monasteries in towns, or just the middle of nowhere? I had a similar issue with the first UNESCO site on the list: Al Qal'a of Beni Hammad in Algeria. It is basically in the middle of nowhere. So, do we:
Danapit, the Monasteries of Haghpat and Sanahin are covered in Alaverdi, about 6 km away, along with several similar sites. I'm not sure they would sustain their own article. Texugo (talk) 12:19, 6 November 2013 (UTC)[reply]
I don't even think you'd stay in M'Sila, as it seems there's nothing there for tourists at all, although I'm no expert on the area. Another example is Jam. That's just a ruined minaret in the absolute middle of nowhere, and there's no hope of filling out any of the other sections apart from Get in. So that's a violation of the 'Can you sleep there' thumb rule, but is there an alternative? At the end of the day, we're trying to do what's best for the traveller, and sending them on wild goose hunts looking for where certain monuments are described might not be of great help. James A ▪ talk12:28, 6 November 2013 (UTC)[reply]
Well, redirects can take care of that part pretty easily. I'd say that sites not complex enough to make much of an article and with no place to stay should be covered in the article for the place a tourist is most likely to be visiting from, i.e., where the tourist will likely stay the night before/after the visit. Then we create appropriate redirects so that the information can be found more easily. Texugo (talk) 12:46, 6 November 2013 (UTC)[reply]
I can see that working in some cases, but what about, say, Jam. The article mentions it's a common stopover on the way from Kabul to Herat by road, so you could assume the few tourists that visit would've slept in Kabul. Are we really going to write about the Minaret of Jam in the Kabul article, which is 595km/9 hours away? James A ▪ talk12:55, 6 November 2013 (UTC)[reply]
I would imagine that with pop. 15,000, Chaghcharan should probably get an article though and it could be covered there. Of course, all of this has to be on a case-by-case basis, but we've always tried to cover rural attractions in the nearest articles whenever possible, and with redirects, it nearly always works out somehow. Texugo (talk) 13:12, 6 November 2013 (UTC)[reply]
Fair enough. I could see that setup working. Would it go in the See or Go next section? I think it would work better as its own header under Go next with logistical and relevant info, while keeping See just for attractions actually within the town limits. Although I don't believe that is the current process. James A ▪ talk13:22, 6 November 2013 (UTC)[reply]
Texugo, thanks for pointing to Alaverdi! Otherwise I would like to avoid adding icons to region articles. Instead, either we should create own articles if there is a chance of staying over night or describe the sites in the nearest town or the usual place where the tourists would stay. Off course, often tourists stay in capitals and make day trips to UNESCO sites. But linking Jam to Kabul doesn't seem right. Generally, doesn't every UNESCO site deserve own article? There must be at least a B&B nearby ;)Danapit (talk) 13:21, 6 November 2013 (UTC)[reply]
Well, I'm not sure every UNESCO site deserves a separate article. After all, many of them are within sizeable cities. And how much could there be to say about a single isolated minaret? Texugo (talk) 13:32, 6 November 2013 (UTC)[reply]
James, if i remember correctly, we used to put things like that in Go next (Get out, at the time), but it seems like we have shifted toward putting stuff like that in See now. I'm not sure where that discussion is, but I do tend to agree with you. Texugo (talk) 13:33, 6 November 2013 (UTC)[reply]
(edit conflict x2) Well I'm flabbergasted. I just read an old 2007 Lonely Planet PDF guide I had on Afghanistan and it appears there is/was a guesthouse right next to the Minaret!! There is also a village, Garmao, 15km away which has a guesthouse or two. So I guess things aren't always what they seem :P And LP managed to somehow squeeze 3/4 of a page out of the Minaret. If anyone's curious/wants to expand our article, I'm happy to forward the relevant pages by email. James A ▪ talk13:41, 6 November 2013 (UTC)[reply]
I have tried several different browsers, and different printers and have not been able to get the banner to print when I print a page with a banner - either on paper or as a pdf. Is this an intentional feature? AlasdairW (talk) 22:17, 5 November 2013 (UTC)[reply]
If I print using the browser print, or the "Printable Version" link at the left, there is no title - but the breadcrumbs are printed so the title can be seen, but not at a glance. The "Download as PDF" link on the left does give a PDF with a properly formatted title, but no banner. I think that banners should print, and I have wanted to print articles specifically to show the banner to people. AlasdairW (talk) 23:05, 6 November 2013 (UTC)[reply]
It would be good if users had the option to print our guides with or without photos, as sometimes people want to save ink and only need the content. Is that possible? James A ▪ talk00:22, 7 November 2013 (UTC)[reply]
That banner was added because it's on fr:Syracuse, which was incorrectly associated with the English and Dutch articles on the New York city, presumably even before the interwiki links were migrated to Wikidata. The correct solution is to move the banner image definition, and the French Wikivoyage link, to the correct Wikidata item. (As it turns out, that banner is already on the Syracuse, Sicily Wikidata item, but keep it mind for future reference. And the French article link still needed to be moved, which I've done.) LtPowers (talk) 21:55, 30 October 2013 (UTC)[reply]
I don't really use this site on a mobile device, but providing someone can confirm that everything works as expected then I don't see any reason not to enable banners for mobile. -- Ryan • (talk) • 02:50, 19 November 2013 (UTC)[reply]
When I display Montérégie I get a wrong proportion image Lac Davignon Panorama.jpg however when I go to edit the page the pagebanner template is the default one. Can anyone explain this? --Traveler100 (talk) 06:59, 26 November 2013 (UTC)[reply]
This is a relatively new feature, when you have default banner and at the same time wikidata contains Wikivoyage banner record, it shows it automatically. Most of the time it works fine and it allows sharing banners between language versions, but it can cause this kind of problem. I was trying to address it before, because I have found several cases like this by coincidence. We have to crop the banner and correct the wikidata record. I also prefer to set the banner name locally. Danapit (talk) 07:10, 26 November 2013 (UTC)[reply]
Saint-Louis is fixed now. What you do is click on "Data item" in the Tools menu (left sidebar) to view the wikidata page for that topic. Scroll down until you find a box called "Wikivoyage banner", click "edit", then click "remove". Thatotherpersontalkcontribs07:12, 19 April 2014 (UTC)[reply]
Saqib, this looks useful, indeed. I looked briefly, and didn't find two particular functions that would be quite important: 1) Does the tool allow to crop into a given aspect ratio? 2) Can I rotate by a few degrees (often the pictures don't have horizontal horizons, etc.)? Anyway, this might be something we could ask the developers. Danapit (talk) 08:56, 19 December 2013 (UTC)[reply]
Sorry for late reply Dana. Unfortunately, this crop tool is not useful for us since the cropping into a given aspect ratio is not possible. Sorry! --Saqib (talk) 20:03, 12 January 2014 (UTC)[reply]
It is possible to preset a aratio for cropping now! Seems like CropTool became an alternative now for quick and dirty cropping. We should mention it as an option at the Expedition page, what do you think? Danapit (talk) 07:55, 12 October 2015 (UTC)[reply]
I have added the information about CropTool (and removed information about discontinued derivativeFX) to the expedition page. Please feel free to rephrase anything that soounds weird or is unclear. Danapit (talk) 17:48, 21 October 2015 (UTC)[reply]
I very rarely do banners, but for the last few months derivateFx does not seems to be usable, I have to fill all info again.
I don't know much about the matter, but could someone contact the developer about this problem? Otherwise it will hold back banner development. Thanks! Nicolas1981 (talk) 10:27, 1 January 2014 (UTC)[reply]
Hi Nick, there was some brief discussion about the matter in another thread. Others already contacted the developer. As far as I understand from his reply, the tool can not be fixed easily, have a look here. I used to like using the tool a lot, as well. Now I upload from scratch and use derived from template. The other info must be entered manually though. Sadly, I don't know any other easy approach. --Danapit (talk) 13:29, 1 January 2014 (UTC)[reply]
There has been a discussion on Talk:United_States_of_America#Page_banner about whether iconography (as in a notable landmark pictured as a silhouette) should be the preferred way of representing countries. I browsed some other countries such as Mexico, Brazil, Finland and France. The general WV convention appears to be some form of landscape and actually the United States is the only place I see the silhouette employed.
I thought I had made clear that due to the size and importance of different countries, that each county needs an individualized approach. I don't see any reason to assume that because we did something one way on Mexico that we have to do it the same way on the USA article. Powers(talk)19:41, 6 January 2014 (UTC)[reply]
Many country banners are landscape, but others are not. For smaller countries landscape can work well, as it can be typical of what you might see in most parts of the country (e.g. Wales). But for larger countries other images may be more appropriate like India and China. The landscape of Alaska and Florida have little in common. I am not that taken with the silhouette though, and note that most artistic images of the statue has some texture (see Commons:Category:Statue of Liberty in art), and the statue maybe is too "vertical" for a banner. AlasdairW (talk) 23:33, 6 January 2014 (UTC)[reply]
I am with User:LtPowers here - we really don't need any convention here. For every country, something different would be the most appropriate, let's use common sense and talk pages and don't waste time establishing unnecessary rules. PrinceGloria (talk) 06:27, 7 January 2014 (UTC)[reply]
I don't think we need hard and fast rules here either, but it is worth pointing out that the silhouette thing is being presented as a possible solution for at least one instance of a situation which is shared by many larger countries, but like Andrewssi2 and AlasdairW above and others elsewhere, I don't buy it. It just strikes me as a photo that is not lit well enough to be a good; it's too concrete to suggest that it's meant as an abstract representation. Texugo (talk) 13:20, 7 January 2014 (UTC)[reply]
Abstraction comes in different degrees. Aiming for a slight amount of abstraction seems better than eschewing it entirely. Powers(talk)18:54, 7 January 2014 (UTC)[reply]
Tip: Find all big images in a Commons category[edit]
Here is an URL that finds all big images in a Commons category:
Just to let you know, I've now enabled pagebanners on the WV mobile site, following (and slightly tweaking) the suggestions of Jdlrobson and Mark. To see the full saga, you can take a look at my stream of consciousness here. :) --Nicktalk13:47, 5 February 2014 (UTC)[reply]
Yeyyy! All my pages suddenly came alive! I still think it may need tweaking a little more. The contrast between page actions and background is sometimes a little off. But looks so much better! Exciting stuff! Nice consciousness! ;) Jdlrobson (talk) 15:55, 5 February 2014 (UTC)[reply]
That's rather brilliant, even if users on limited-band connections and roaming may not appreciate that as much. I am also forseeing a slight issue - while most banners are made with the assumption that the bottom part will be covered by the TOC-box in the web browser and the top will shine, in the mobile version it is the upper part that gets covered and the bottom exposed. Some banners (e.g. for Munich) look rather weird in this setup. Did you consider (sorry if this IS in the stream of consciousness I have so conveniently decided not to have time to follow) moving the title banner and icons to the bottom of the banner, and/or placing them side-by-side whenever possible? PrinceGloria (talk) 04:43, 6 February 2014 (UTC)[reply]
In response to PrinceGloria's question, I didn't move the title and icons to the bottom as I didn't want to make it look too different from the default without further consultation and, also, we will never find a single position that works for all banners unfortunately. I think we'd struggle to place the article title and action icons next to each other as, on pages with longer titles, the two will run over each other. We could perhaps hide the image icon however as I think we lock that on all pages. --Nicktalk23:25, 6 February 2014 (UTC)[reply]
Hi! How would everyone feel about removing the curved elements on our banners (i.e. the place name and icon box). At present, I think it makes the top of the page look a little cluttered and it would be nice to see a more streamlined version that fits in with the other straight lines that populate the site. --Nicktalk03:57, 25 February 2014 (UTC)[reply]
My personal preference would be to keep the name (London in this example) and remove the icon completely. It is confusing to add the visual element that can mean 'previous destination of the month' or 'UNESCO site'. Andrewssi2 (talk) 05:09, 25 February 2014 (UTC)[reply]
Curved box is infinitely better than sharp-edged box, there is no contest. I firmly object to changing the round edged box. I wholeheartedly support removing the "previous destination of the month", who cares - certainly not the casual reader. We can keep that info in the talk page for reference. PrinceGloria (talk) 05:56, 25 February 2014 (UTC)[reply]
I think I agree with PrinceGloria on excising the "previous x-type of feature" boxes from articles and putting the notice on the talk page, instead. It's a convenience to editors looking for new DotM, etc., to see the notice right there at the top of the page, but this is not a meta site mainly for the benefit of its own editors but a site for the benefit of travelers. But what about the UNESCO symbols? Can they be put as a bolded notice below the banner instead of a symbol within the banner? Ikan Kekek (talk) 06:06, 25 February 2014 (UTC)[reply]
I like the icons as a way of indicating that the article is special in some way - higher quality, world heritage site, etc - but it doesn't necessarily need to be on the banner if someone else has a better place for it. I think it should be near the top of the article though, and not on the talk page. -- Ryan • (talk) • 06:57, 25 February 2014 (UTC)[reply]
My suggestion, then, would be to put it as a bolded announcement directly below the banner, for any kind of distinction, including UNESCO. I think it's probably best to keep the name in the pagebanner, but the banner would look nicer without the name, so to those of you who want to make the banner just a photo with nothing else in it (only Nick so far?), where do you propose to put the place name? Just in the little breadcrumb trail? Ikan Kekek (talk) 07:07, 25 February 2014 (UTC)[reply]
Hi! Sorry, my first post might have been a bit confusing. I'm not advocating removing the place name by any means - just to changing the box it's in to one with corners rather than rounded edges as I believe it looks cleaner and fresher (per the screenshot), whilst in-keeping with the other straight lines that are in use across the rest of the site (like in our loo and the MW interface). I'm sorry if I caused any confusion! --Nicktalk10:37, 25 February 2014 (UTC)[reply]
OK, I understand. However, unless I'm missing something, the differences in the shape of the nameplates are so small that they almost seem like optical illusions. If I look very carefully, I can see that the edges of the nameplate currently have tiny diagonals or perhaps curves instead of right angles, whereas your mockup has only 4 sides with right angles between each pair of sides. What's much more noticeable is that your nameplate doesn't overlap with the building to the left, whereas the banner in the London article does (which makes yours better). I also see that your table of contents doesn't go all the way from left to right along the bottom of the pagebanner, whereas the TOC in the article does, and for visibility's sake, I'd give the nod to the existing format in this respect. Ikan Kekek (talk) 10:56, 25 February 2014 (UTC)[reply]
I think that's probably a result of different screen resolutions rather than pagebanner itself. As the banners resize dynamically, I imagine almost everyone's display will look slightly different. --Nicktalk11:15, 25 February 2014 (UTC)[reply]
(2x edit conflict) Ikan, the apparent differences in overlapping the bridge and the TOC going all the way across are simply because the screenshot above was taken on a larger screen size than the one you see the page with. Like Ryan, I don't see a particular need for a change here. And I don't like the idea of a bolded announcement just under the banner because there will be plenty of cases where it would start to look like a stack of things at the lead, in combination with the banner plus the various hatnotes and style/merge tags or region/district discussion tags that sometimes occupy that space. Texugo (talk) 11:21, 25 February 2014 (UTC)[reply]
My preference would be to keep the curved boxes and icons because they looks pretty to me. Btw, I just realised that boxes are curved in IE7, article and icon boxes background is black and TOC links not working as well. --Saqib (talk) 11:47, 25 February 2014 (UTC)[reply]
I think the sharp-edged version of the name box Nicholas suggests looks a bit too harsh and prefer the current one. When it comes to the icons I have no strong opinion whether to keep or discard them. It would be good to hear the opinion of people who've come up with the icon idea and implemented it before removing the icons, though. ϒpsilon (talk) 14:58, 25 February 2014 (UTC)[reply]
I just did what I always do when this happens: I asked Kizar :-) I also documented that "procedure" at the end of the present article, so that anyone can do it directly. Nicolas1981 (talk) 01:43, 28 February 2014 (UTC)[reply]
Seems like the user might not be active anymore. Perhaps we need to find someone to develop another bot doing the same job. How can we do it? Danapit (talk) 14:01, 17 February 2015 (UTC)[reply]
I can confirm, Powers. It does screw up the TOC. At the bottom left part of the banner a small gray rectangle appears and the TOC doesn't have the shaded background.--Danapit (talk) 19:01, 6 March 2014 (UTC)[reply]
After taking a quick look through the wikitech news, seems like the WMF is going to un-beta the Typography Refresh on the 3rd of April, which makes any fixing of this to be essential. Anybody to dig through the CSS? -- torty3 (talk) 04:20, 30 March 2014 (UTC)[reply]
This change should partially resolve the issue. To get rid of the extra gray box below the TOC, once the typography refresh goes live we'll need to modify MediaWiki:Common.css to change the following style:
The first section above, #Add_a_.22full_TOC.22_button.3F, raises what I think is an important problem; the banners improve some things, but they break others. The horizontal table of contents is a large improvement visually and it works very well for smaller articles with a simple heading structure, but it fails miserably for more complex articles since it denies access to lower-level headings.
This was originally raised in May last year, but has not been fixed yet. Am I alone in thinking it is important?
My preferred solution would be the one described at #Per-section_index above, because it does not complicate the banners and is visually consistent with them, maintaining the horizontal theme. Pashley (talk) 13:06, 2 April 2014 (UTC)[reply]
Personally, I have never found this issue to be of the utmost importance. Yes, technically it "denies access" to lowest-level headers, but I would venture that it is far less than 1% of our sections where regular section headers won't show you all the subsections on the screen at the same time anyway, and in the cases when they don't, a half-scroll of the mouse will usually suffice to get you to the rest without any significant hunting. Plus, since almost all of our subsections are standardized (By car/By bus/etc.) there is very rarely an enormous disadvantage in not being able to "explore the TOC" once you realize that pretty much all our pages are structured the same way, so I don't see it as a highly popular and oft-used feature. That said, I would fully support it if someone could create automatic drop-down menus from the banner at the top, like Torty3's mock-up, but the #Per-section_index idea has some problems, not least of which is the technical impossibility at this time of creating and manipulating multiple TOC instances in an automated manner, but almost as serious to me would be the bizarre visual stripe effect that turning headers into horizontal bars would have on the 95+% of our articles which have sections with little or no content, and its consequence of emphasizing those empty sections by highlighting them with multiple bars in a row. Texugo (talk) 13:26, 2 April 2014 (UTC)[reply]
If we did find a way to do per-section TOC bars it would certainly be necessary to automate them since doing it manually would be a maintenance disaster. Given that, it should not be hard to prevent them appearing unless there are (two or more?) subheadings. On the other hand, that would make the section headings look quite different in the two situations, which might be fairly ugly.
There is likely a way around this — perhaps just eliminating the black bar? — but I am not certain what it might be. Pashley (talk) 16:11, 2 April 2014 (UTC)[reply]
Don't think I could support any solution where some headers look different from others. Anyway, aren't we a lot closer to being able to do dropdown menus than we are for per-section TOCs? Texugo (talk) 17:21, 2 April 2014 (UTC)[reply]
Without knowing more about the way TOCs are generated, yes. Regarding the changing headers, I think the better solution would be to utilize a simple navigation strip below the header, including it only where necessary (not just any section with subsections but only where it's deemed essential for navigation); that means that headers will all look the same (as they should) as well as remaining harmonized with other WMF wikis. If we take that route, the number of instances may be small enough to be worth doing manually. Powers(talk)14:27, 3 April 2014 (UTC)[reply]
Over at Talk:Lille and some other pages we have examples of equally good banners that we could use for some articles. I guess it would be good to discuss if we can use the rotating banner feature for articles as well. I cannot find a reason why we shouldn't, but perhaps somebody can. Do excuse me if this was discussed and I missed it. PrinceGloria (talk) 22:02, 6 April 2014 (UTC)[reply]
I guess my reaction is that it could be a good thing to do, though it's more important for good pagebanners to be created for articles that don't have any. One possible down side is if the images within the article are chosen with the image in the pagebanner in mind, but that hardly seems like a crippling blow. Ikan Kekek (talk) 22:19, 6 April 2014 (UTC)[reply]
If we're referring to the current mechanism used on the Main Page, I'd probably be against such a move. Whilst it's undoubtedly attractive to have a rotating feature, the JavaScript we use is somewhat demanding and implementing it might make mobile compatibility an issue. Unless there is another way to rotate the banners other than an 'action=purge' command which only does so when the page is edited, I'd advise against this. As Ikan says, for the moment, we should focus on filling the large gaps we currently have in pagebanner imagery. --Nicktalk22:34, 6 April 2014 (UTC)[reply]
Would captions keep in sync with the rotating banner? It also might be a little off putting to the casual reader to have a page look different from yesterday if the content has not changed. AlasdairW (talk) 22:39, 6 April 2014 (UTC)[reply]
I agree that a rotating banner would be off putting. It is completely appropriate for the main page with multiple destinations but not for a specific destination. Andrewssi2 (talk) 23:09, 6 April 2014 (UTC)[reply]
Part of the purpose of the banners is visual identification. That goes out the window if we're continually changing them. Powers(talk)00:41, 7 April 2014 (UTC)[reply]
Oh, I missed the part about the banner being so important for identification. Many sites that use stuff akin to our banners do use features similar to our rotating banner feature. Besides, we do change banners on the fly, when we decide on the talk page there is a new, better banner idea. If the user visits the article only once, they'd have no chance of noticing. If they happen to visit twice, they'd be just as confused. If they visit multiple times, which is likely, they will surely find out how the feature works quickly - I saw it used elsewhere, as I said, and never did it confuse me.
The JavaScript used for the carousel feature is more work-intensive for users' systems than the JS for the banners at present. By making such a change, we make all of our pages slower to load. At present, the mobile version of the Main Page does not feature any images, whilst our articles have their banners intact (compare https://en.m.wikivoyage.org/wiki/Main_Page and https://en.m.wikivoyage.org/wiki/England). There is also the issue of what to do with the associated Wikidata class and how many is too many. I think we probably need to just decide on a banner and go with it - we can always change it later on anyway. --Nicktalk15:35, 7 April 2014 (UTC)[reply]
Just a clarification - I do not mean a carousel like in the main page, but rather displaying randomly one of the few given banners, like we do atop the main page of this Expedition. Is this just as resource-intensive and impossible to implement as the carousel? I also believe it is not impossible to let more than one image be designated as a Wikivoyage banner in Wikidata. The only question is how and where that data is used. Finally, I think there are destinations where we will have more than one brilliant banner idea because they are quite popular and picturesque, but I don't believe we will have too many of them, or more than two-three equally brilliant banners for each. Just as well we will continue to have destinations for which it will be hard to find any banner-suitable imagery at all. It would simply be a shame to lose any of the brilliant banners just because only one can be THE one. PrinceGloria (talk) 16:03, 7 April 2014 (UTC)[reply]
If you use the random image method (as at the top of this page), then there shouldn't be any issue with resource-intensive JS. That said, as far as I'm aware, a new image is only selected when the page is purged, which happens most commonly at the same time as editing. As such, onp ages that aren't edited very regularly, it could be many days between changes. --Nicktalk16:29, 7 April 2014 (UTC)[reply]
I don't think this would be a problem - if anything, the voices above were concerned if the banner changed too often. I also believe most of the destinations which stand a chance of getting more than one brilliant banner are those which will see most frequent edits, so the feature won't be left unused. PrinceGloria (talk) 17:16, 7 April 2014 (UTC)[reply]
Yes, some of our articles change banners occasionally as new, better ones are found; presumably the situation will stabilize as they're rolled out. But given the relative prominence of the images over the title of the article, I think maintaining relatively consistent imagery is important to visually signify to readers the identity of the article they're reading. Powers(talk)19:58, 7 April 2014 (UTC)[reply]
It's also worth pointing out that sometimes an important site is depicted in the banner image and nowhere else on the page (to avoid redundancy); this is difficult to maintain if the banner image is unpredictable. Powers(talk)20:00, 7 April 2014 (UTC)[reply]
I find the latter situation to be wrong. Very few landmarks/POIs lend themselves well to presentation in the 7:1 banner form. I find those being impressions, not depictions. In the articles I edit, I make a point of including a different, more "matter of fact" picture of same landmark/place in the appropriate section, if a particular one is indeed in the banner. I just avoid repeating the same or similar view in both banner and one of the pictures in the article.
Again, I don't think users will have issues identifying where they are given that the pages still have prominent titles, and there are many travel sites using "rotating" imagery. I never felt lost using them. And, on the contrary, I believe that the number of new banner proposals will RISE as our user base will grow, and anticipating that, I would hate to lose good proposals (or good "old banners"). PrinceGloria (talk) 05:03, 8 April 2014 (UTC)[reply]
Hello there Wikivoyage community. AndreCarrotflower notified me on my talkpage last week while I was transferring a few of Wikivoyage's freely licensed banners to Wikimedia Commons that I ought to leave local versions of the banners on the English Wikivoyage without deleting them, per the notice at the top of Wikivoyage:Destination of the month candidates/Banners. Of course, I respect the English Wikivoyage's independence from Wikimedia Commons, a practice sometimes exercised also on the English Wikipedia, but I am curious as to the original reason this not-so-well-documented line of policy was introduced. I was pointed to Talk:Main Page#PNG but the reasoning introduced there did not clarify exactly why hosting the files locally is better than hosting them on Wikimedia Commons. Perhaps it was an issue regarding bandwith issues, but could someone also elucidate the technical details of that to me? If it was something else altogether, I noted the existence of commons:Category:Wikivoyage banners already created on Commons for the purpose of hosting banners across language editions of Wikivoyage, which would be an argument for transferring to Commons rather than against, wouldn't it? TeleComNasSprVen (talk) 08:45, 17 March 2014 (UTC)[reply]
It's worthy of note that User:Peterfitzgerald, the one who originally proposed that banners be hosted locally rather than at Commons, is no longer active on Wikivoyage and is very unlikely to be reachable through his talk page. -- AndreCarrotflower (talk) 10:58, 17 March 2014 (UTC)[reply]
Keeping mind we're only talking about main page banners here (our 7:1 article banners should be on Commons where possible)... I would suggest that we keep the local uploads temporary for protection purposes. Once the feature is over, the banner can be uploaded to Commons (so that we can use it on our Previous DotM (etc) page(s)), while alternative banner suggestions can be deleted. Powers(talk)18:11, 17 March 2014 (UTC)[reply]
I believe that it may be possible to have them protected on Commons (but it's done by bot); en.wikipedia does it, and you must be an admin to upload over the fullprotected file here. But, they may not be willing to do this as we're not en.wikipedia, and thus 1) not such a huge target of vandalism and 2) only a medium-sized wiki. --Rschen775421:00, 17 March 2014 (UTC)[reply]
That would require protecting the name on both wikis, as otherwise a locally-uploaded file overrides a shared repository. K7L (talk) 01:12, 18 March 2014 (UTC)[reply]
IMO, this is rapidly approaching "more trouble than it's worth" territory. The current system of uploading banners locally has not been an issue thus far, and frankly I'm not exactly sure what problem we're trying to solve here. -- AndreCarrotflower (talk) 02:18, 18 March 2014 (UTC)[reply]
Is this a correct reading of what I'm seeing here? As to the bot, I think I can ask Krinkle to modify his script accordingly to auto-protect Main Page banners. Or perhaps better yet ask a bot owner to reupload a banner to Commons after the main page feature is done and then delete the local version. TeleComNasSprVen (talk) 07:20, 18 March 2014 (UTC)[reply]
39 suggested new alternative banners - please participate in the following discussions and vote[edit]
Over the last month or so I have created 39 new alternative banners to existing ones used in various prominent city articles on Eng Voy. I created these banners from exisitng photos on Wikicommons first and foremost for use in the parallel articles on the Hebrew Wikivoyage. In most instances these new alternative banners feature panoramic photographs of cityscapes (and yes, I know not everyone here want cityscape banners to be used in the city articles), as we in the Hebrew Wikivoyage tend to prefer cityscape panoramic banners to panoramic banners of flowers, bushes, fishes, or other individual objects which are not necessarily unique to a certain place and do not necessarily help the travelers get an idea of how the destinations they plan on traveling to actually look like (we usually add the photos of important individual objects to the relevant segments in the articles instead).
Please participate in the following 39 discussions and indicate in each of the discussions whether you prefer the existing banners or the new suggested banners.
Excuse me but I find this kind of shopping around quite disgusting and counter-productive. If you don't like a banner, make a better one, start a discussion in the talk page, see where it goes. It is not a "vote", it is a discussion. If you want voting, try Eurovision.
Secondly, if you believe you have superb banner-making skills and want to put them to good use, look around for articles to go without a banner, of which we still have shiploads.
If you just want to be appreciated, do note that this is a collaborative project and not a talent contest. Appreciation comes in the form of having created a better, more complete, more useful, more frequently visited and used, and also nicer to look at, site. Mediawiki sites, even those with well-developed badge/barnstar and whatnot systems, are some of the worst places to go to if you want to shine and receive massive expressions of awe and appreciation. This is the uttermost opposite of X-Factor.
If you want the kind of appreciation Wikivoyage can provide you with, start with articles that need help the most, as this is where making a meaningful and visible impact is the easiest. The appreciation you can provide yourself with looking at an article that started out as neglected, outdated stub and is now a full-blown guide is the best thing ever. Or at least the best thing on Wikivoyage. PrinceGloria (talk) 20:36, 6 April 2014 (UTC)[reply]
I actually thought that this was a healthy way to promote collaboration between language versions. Even if none of the new banners are used here, it's interesting to see what other languages prefer, and it's at least worth discussing the possibility of changing to a potentially better banner. -- Ryan • (talk) • 20:48, 6 April 2014 (UTC)[reply]
Yeah, I don't understand what the down side is. And some of the new banners are a major improvement (while others are not). Let 100 flowers bloom. Ikan Kekek (talk) 20:54, 6 April 2014 (UTC)[reply]
We've had those banners suggested in the talk pages for some time now and they have generated instantenous reactions, though some not favourable for the user who posted. I fail to see why this needs to be brought to the attention at the pub, I am seeing this kind of discussions quite often (i.e. suggestion of a new banner, also from other language versions). The fact that the user refers to their preference regarding panoramas and refers to a "vote" made me think they perhaps want to shop for "votes" for their proposals, which I find counterproductive.
I also believe that while diversity and multiple choices are always better, we may want to direct our attention to more creative issues. There was a fair share of discussions in the talk pages, why do we need to encourage more participation in bulk? If somebody is particularly keen on or knowledgeable about Leeds, they will probably have had the article on their watchlist and have or will see the discussion about its banner. If somebody isn't, why bother them. It is a local issue, not a global one, and not a pressing one requiring more attention from the community. The French and Italians are also using different banners oftentimes. PrinceGloria (talk) 21:40, 6 April 2014 (UTC)[reply]
Yes, and we had a bunch of beautiful banners from French Wikivoyage proposed some time ago. I found your tone unnecessarily hostile. I don't see it as harmful that this notice was posted here, and I also don't see it as harmful that ויקיג'אנקי has pride in their banners or that they posted about their philosophy of what makes a good banner to them. Ikan Kekek (talk) 21:46, 6 April 2014 (UTC)[reply]
I see nothing wrong with ויקיג'אנקי's actions here. Even if in most of these cases I preferred the existing banner to what was proposed, it's nice to see other options presented and have these pleasant little discussions about what we look for in a good banner. No harm done, and I think we're a stronger community for it. PerryPlanet (talk) 22:47, 6 April 2014 (UTC)[reply]
I agree that it is a worthwhile exercise to see alternative banners. ויקיג'אנקי made some suggestions and if it helps improve one English destination article then that is great.
It does actually raise another question. Since the Hebrew site apparently doesn't use Wikidata as the reference to banners it means all changes have to be suggested in this manner. If it was the French site then basically our banners would change with no discussion (or even change notification), and this is true vice versa. Has anyone considered how we work with other language sites that use Wikidata for banner references? Andrewssi2 (talk) 23:43, 6 April 2014 (UTC)[reply]
First of all I want to apologize if anyone was offended becuase I did not choose the right words (I chose to use the word "vote" instead of "discussion" or "consensus based discussion"). English is not my primary language and therefore occasionally I may end up formulating sentences which do not take into account different nuances and sensitivities.
I must also clarify that contrary to what someone suggested above, in addition to these 39 alternate banners I created, over time I have also created many banners for articles which have no banners at all (both in Heb Voy and Eng Voy). In the future I definitely plan to also help create even more banners for articles that don't have any banners. Either way, I have made many banners in the past and I'll continue to make many more in the future (first and foremost for usage in Heb Voy), and in my opinion no harm is done by having the Eng Voy community (and maybe also other Wikivoyage communities) discuss using some of these alternative banners here as well. On the contrary - I believe that permitting discussions of this kind help us improve the quality of our articles over time.
I will also note that I have noticed that many of the users in Eng Voy whom have created banners in the past tend to be very proud of to their creations, and some of them I believe might even assume that their banners would continue to be used in the Eng Voy articles forever. In practice, Wikivoyage banners, as well as any of the other elements appearing in the articles, are open to discussion at any time now and in the future, and of course in the future instances in which specific new alternative banners would actually end up being favored by a majority of community members in a discussion, existing banners might very well end up being changed based on the new consensus reached. Based on my experience with Wiki culture, most likely, in 5 years, or 10 years or 20 years from now, most of the banners currently used in Eng Voy would probably end up being replaced by more much more successful and spectacular panoramic photos, whether you like it or not (this would most likely happen when the En Voy community would become much larger and diverse).
Regarding the original note I added above, in which I invited the Eng Voy community to take part in the current 39 discussions being held over these alternative banners... I chose to post this invite here mainly because this practice is widely acceptable in many wikis as it promotes fairness and it help us make sure that the final decision actually corresponds to the prevailing opinion amongst the Eng Voy community.
Anyway, I am glad that so far at least some of the alternative banners I created have gained support/consensus of the community and would probably end up being used in Eng Voy as well.
Finally, regarding Andrewssi2 last question about the instances in which foreign wikis would use Wikidata to display banners - I can confirm here that we in Heb Voy community do display banners according to what is defined in Wikidata by default, NEVERTHELESS, in the instances in which we rather display other alternative banners than what is defined in Wikidata - all we need to do is edit the banner code of a specific article in Heb Voy and specify that a different banner would be used there, and as a result, that article only doesn't use the banner which is associated with that article in Wikidata. ויקיג'אנקי (talk) 05:17, 7 April 2014 (UTC)[reply]
Hi ויקיג'אנקי, you took the initiative to help improve WV and I personally don't think you need to explain yourself at all. Many thanks again for the alternative banner suggestions. Andrewssi2 (talk) 07:44, 7 April 2014 (UTC)[reply]
This is at least the second time you offered a lot of alternative banners. Last time, you presented some great ones, too, and this time, you waited for more people to pass judgment on them, so I think that's great, and I know that most of us will welcome you whenever you come again with more banners for us to look at. And we'll look forward even more to pagebanners for articles that have none. Ikan Kekek (talk) 09:12, 7 April 2014 (UTC)[reply]
I think the pub is a nice place to get opinions, because some destinations may not generate conversation if it is left to the talk page. Plus, since users who make banners are all proud of their work, discussion is probably better than plunging forward to replace everyone else's banners with one's own. That way no toes are stepped on. ChubbyWimbus (talk) 14:22, 7 April 2014 (UTC)[reply]
Method which may allow you to find many additional spectacular panoramic photos to be used as Wikivoyage banners[edit]
I wanted to share with the community an interesting method which may allow you in many cases to use certain spectacular panoramic photos of specific destinations around the globe as banners in certain travel destination articles on Wikivoyage.
As far as I have gathered, nowadays when most Wikivoyage banner creators want to create a banner for a specific travel destination they would most likely begin their search for a good panoramic photo (which they would later crop to the resolution 2100 x 300 and then re-upload) on WikiCommons. Although there are a lot of free photos of travel destinations available to use on Wikimedia Commons, in many cases you would not be able to find there even just one good panoramic photo of specific destinations (or a good photo you could turn into a good 2100x300 banner). From my experience, as a result of this lack of variety in available free spectacular panoramic photos to certain destinations, in many cases Wikivoyage banner creators whom are unaware of additional sources of free panoramic photos may often, as a compromise, create banners from existing photos on Wikicommons which don't produce the best quality Wikivoyage banner.
1. First perform a global search on Flickr's vast photo database (make sure that the search would be done on all their photos, including the ones which do not have a free license) for panoramic photos of specific travel destinations. On this search page, you would be able for example to search for "Panorama Disneyland Paris" or "Panoramic Disneyland Paris' (check it out here for yourself and you will notice that there are far more spectacular panoramic photos available on Flickr for this specific destination than those available for this specific destination on Wikicommons).
2. After you find one or multiple non-free panoramic photos you think would look well as a Wikivoyage banner (the free ones you can of course import easily using this Wikimedia foundation tool), go ahead and send the creator of that photo on Flickr the following message:
Subject: May we use one of your photos in Wikivoyage?
Content: Hi (Write the Name or Username of the Flickr Photographer you are addressing). I am a volunteer writer for the free travel guide website Wikivoyage (the latest creation from the creators of Wikipedia). I am working on the article (Write Name of Travel Destination Article) (en.wikivoyage.org/wiki/NameOfTravelDestination) which currently has no panoramic picture in the banner. I am emailing you to request that you license one of your photos Write the URL of their specific Flickr photo you liked under the Creative Commons Attribution-ShareAlike 3.0 license (CC-BY-SA), a license which permits others to reuse your image as long as they provide proper attribution to you. Your credit would be attached to the image, along with a link back to either your Flickr profile or other website of your choice. The contents of the CC-BY-SA license can be found at creativecommons.org/licenses/by-sa/3.0/
If you are willing to contribute your image under the terms of the CC-BY-SA license, you can change the license by going to the image's Flickr page and under Owner settings clicking edit License and choosing "Attribution-ShareAlike Creative Commons".
3. Usually, when you send the above message to between 3 to 5 different photographers on flickr, whose photographs you found by making a global search on Flickr, in most cases, after a day or two at least one photographer would respond and tell you they approve of your suggestion and that they changed the license.
4. After the Flickr photographer changes the license of their photo, you would now be free to (A) import the photo to Wikivoyage using this Wikimedia Foundation tool (B) create the banner image using an Image editing program such as Photoshop or Paint.net and be able to upload the new version as a separate derivative work (the free license terms of the photo would of course allow you to do so).
5. Write back Flickr photographer and thank them.
Using this method, and thanks of course to the generosity of Flickr photographer CetusCetus, I have created not so long ago the banner which now appears at the top of the article Disneyland Paris (surprisingly I did not find any existing spectacular panoramic photos for this popular destination on Wikivoyage, but Flickr on the other hand had many different good panoramic photos of this specific destination). After I sent the above message to the Flickr photographer CetusCetus she changed the license of this brilliant picture and as a result I was able to create a banner from it. ויקיג'אנקי (talk) 23:06, 26 May 2014 (UTC)[reply]
Hi, everyone. With your permission, I'd like to prioritize the Guide articles that are still lacking in custom pagebanners. The list is here. Once all these articles (well, possibly excluding Isha Yoga Centre, which many of us thought should have been merged and redirected) have pagebanners, I intend to add a requirement for a custom pagebanner to the criteria for advancing an article to Guide status. Ikan Kekek (talk) 13:18, 5 August 2014 (UTC)[reply]
I wouldn't say nothing much has changed. The list was at 97 items the first time I checked right after you posted it here, and is now down to 54 items. That's 44% completion in six weeks, compared to the banner project as a whole where it took a year and a half to reach 27% completion. Thatotherpersontalkcontribs09:48, 13 September 2014 (UTC)[reply]
Anyone knows how to make the black TOC background less transparent (darker)? I'm asking this for the Dutch WV where they find the white text difficult to read on some banners. Globe-trotter (talk) 12:05, 8 September 2014 (UTC)[reply]
The only option I know about is TOC box option. (Enter box=black for the TOC to appear in a translucent black box with white type. Enter box=white for the TOC to appear in a translucent white box with black type. Enter nothing for the default solid grey box with black type.) Might that help? --Danapit (talk) 13:23, 10 September 2014 (UTC)[reply]
Hi, everyone. I believe that all Guide-level articles should have custom pagebanners, but right now, 97 do not. So your mission, if you choose to fulfill it, is to create pagebanners for one or more of these Guides. While we're at all, adding at least one well-chosen photo for the body of the article, if there isn't already one there, would be a great thing to do as well. Ikan Kekek (talk) 13:21, 5 August 2014 (UTC)[reply]
Do not like it myself but should we allow attribution text in banner images? See Skomer, I asked the contributor to remove copyright text from the image, which was done, only to be replaced by copyleft text. Do we want to have what appear to be advertising a business in images? --Traveler100 (talk) 15:35, 28 October 2014 (UTC)[reply]
I noticed this edit (since reverted) by User:ויקיג'אנקי, who provides the rationale in the change of banner as to it being larger than the 'standard size' of 2100x300.
Looking at the guidance seems a bit ambiguous. It does seem to suggest that 2100 x 300 is recommended, but if a banner is (say) 7000 x 1000 in size, is this truly a problem?
The benefit of larger banners is that they scale better to higher resolution screens (such as Apple Retina laptops), and logically screens will increase in resolution more in future.
The disadvantage is that the full size image gets downloaded, thereby increasing rendering and download time.
I think the 2100 x 300 was a recommendation. The important part was maintaining the 7:1 ratio. If the image quality permits, I've started to make banners at 2800 x 400 to take into account higher screen resolutions. -Shaundd (talk) 06:08, 19 December 2014 (UTC)[reply]
Right, but I think User:ויקיג'אנקי (and perhaps others) are taking 2100 x 300 to be the recommended size, no smaller and no greater.
Can we change the guidance to reflect the bold text below?
Image size (Proposed)
Banners have a 7:1 width to height ratio.
Banners need to be at least 1800 pixels wide to accommodate wide screens (images do not scale up to fit the size of the screen). The recommended dimensions are a minimum of 2100 x 300 pixels.
I didn't write the right description in the summary and as a result I was misunderstood - you see, I fixed this new banner, instead of that which شاملو created, mainly because his banner wasn't a 7:1 (and that's what i should had written in the description) - it was a 6.3897 x 1 (and the resolution was 2,000 x 313). ויקיג'אנקי (talk) 06:56, 19 December 2014 (UTC)[reply]
I will add though that at the Hebvoy community we have discussed in the past what the banner resolution should normally be, and only after I made a couple of banners in high resolution PNG files and got many complaints from Hebrew Wikivoyagers whom told me that these banners took too long to load, we at Hebvoy decided to only create compressed JPEGs which are around 180 KB in size, and usually have a resolution of 2100 x 300 (or smaller if I can't find a good source photo). ויקיג'אנקי (talk) 07:01, 19 December 2014 (UTC)[reply]
Ah, I see. I think we need to have the same conversation here since most of us were not party to that discussion on Hebvoy :)
I hold the position that banner image sizes should be as high in resolution as they can in order to look good on Wikivoyage in 5 years or 10 years time when people are using much higher resolution screens. I understand that image size could be an issue from a bandwidth perspective, therefore what should be a maximum size? I would suggest four time the size of the recommended minimum, i.e. 8,400 x 1,500 --Andrewssi2 (talk) 07:27, 19 December 2014 (UTC)[reply]
Français
Italiano
