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[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[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[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[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[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[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[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[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[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[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. --PeterTalk 18:17, 10 June 2013 (UTC)Reply[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[reply]
Bravo! I have applied it at Shanghai and it does provide reasonable short-term solution. Pashley (talk) 14:53, 12 June 2013 (UTC) reasReply[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[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[reply]
I also agree—it's confusing to see the pagebanner missing the usual, expected table of contents. --PeterTalk 15:44, 12 June 2013 (UTC)Reply[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[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[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[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[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. --PeterTalk 18:33, 12 June 2013 (UTC)Reply[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[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 ▪ talk 13:39, 13 June 2013 (UTC)Reply[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[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[reply]
You could use continental sections as the top level headers though. Texugo (talk) 19:28, 13 June 2013 (UTC)Reply[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 ▪ talk 07:48, 15 June 2013 (UTC)Reply[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[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[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[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[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 ▪ talk 13:39, 13 June 2013 (UTC)Reply[reply]
I really do like the drop-down menus, though is it something that we could implement on here? --Nicktalk 14:14, 13 June 2013 (UTC)Reply[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[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[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[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? --PeterTalk 21:12, 14 June 2013 (UTC)Reply[reply]
It does all too often, actually. But it is a good sign the article has too many top-level headings :) PrinceGloria (talk) 21:16, 14 June 2013 (UTC)Reply[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[reply]
@PrinceGloria, Could you point us to an example of too many top-level headings please. • • • Peter (Southwood)(talk): 06:07, 15 June 2013 (UTC)Reply[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[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[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[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[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[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[reply]
I don't see a big issue. Talk pages rarely have many subheadings anyway. I say remove it! LtPowers (talk) 11:08, 27 June 2013 (UTC)Reply[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[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[reply]
Bump! It is now February and we still do not have a fully usable TOC. Pashley (talk) 20:06, 14 February 2014 (UTC)Reply[reply]
Do we need a Bugzilla entry to remove TocTree? Powers(talk) 21:54, 15 February 2014 (UTC)Reply[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[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[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[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[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[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[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[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[reply]
You are in the right place! :) Those banners look great - it would be good if we could somehow incorporate them here. --Nicktalk 22:09, 26 August 2013 (UTC)Reply[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[reply]
I'll carry on from there; I'll let you know where I get up to! --Nicktalk 23:07, 26 August 2013 (UTC)Reply[reply]
I'm going to take a break having just finished the first page. :) --Nicktalk 00:49, 27 August 2013 (UTC)Reply[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[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[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[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[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[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[reply]
It seems to be calling a different upload page from commons. It seems now to be virtually useless for its purpose. Most unfortunate. • • • Peter (Southwood)(talk): 20:12, 1 September 2013 (UTC)Reply[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. --Nicktalk 17:10, 14 September 2013 (UTC)Reply[reply]
I think it's the result of changes to the quickbar template that have been discussed for a while. I promise I didn't put any secret code in the banner template to hide other images and flags. :-) -Shaundd (talk) 17:27, 14 September 2013 (UTC)Reply[reply]
Whoops! Hadn't seen that! Thanks for the info Shaun - I never suspected you of crimes against quickbars! :) --Nicktalk 18:50, 14 September 2013 (UTC)Reply[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? --Nicktalk 17:32, 15 September 2013 (UTC)Reply[reply]
It would if we had a strong consensus to start using the banners on dab pages. I think they're excessive, personally. LtPowers (talk) 21:01, 15 September 2013 (UTC)Reply[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. --Nicktalk 22:02, 15 September 2013 (UTC)Reply[reply]
Er, yes, sorry about that. I didn't read carefully enough. (Though I fear that parameter name is a bit miselading.) LtPowers (talk) 00:20, 16 September 2013 (UTC)Reply[reply]
Yeah, I think it should be "otheruses=". Texugo (talk) 02:23, 16 September 2013 (UTC)Reply[reply]
We already have a special banner for dab pages
If we do a bot run, maybe we should change the parameter name at the same time. • • • Peter (Southwood)(talk): 06:03, 16 September 2013 (UTC)Reply[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[reply]
Can anyone find a good image to replace the "bad banner" example under #How to make a quality banner? Obviously a red link is the worst kind of banner there could possibly be, but I don't think that was the type of example intended... Texugo (talk) 11:50, 19 September 2013 (UTC)Reply[reply]
I'd say that's about right. Shall we change it? Texugo (talk) 13:06, 19 September 2013 (UTC)Reply[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:
Nice! Also because it made me click on Niue, a "country" I'd never heard of with a name that -as I know now- means as much as Look! A Coconut!. Great stuff :-)) JuliasTravels (talk) 15:24, 28 September 2013 (UTC)Reply[reply]
A handful of star articles lacking a custom banner[edit]
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[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? --Nicktalk 00:21, 29 September 2013 (UTC)Reply[reply]
I'm a bit busy these days so have at it, as far as I'm concerned. =) LtPowers (talk) 15:20, 29 September 2013 (UTC)Reply[reply]
Down to 303 now. (No thanks to me) Texugo (talk) 18:18, 1 October 2013 (UTC)Reply[reply]
I have done a few. Some destinations don't have any suitable images on commons, and trying to find acceptably licensed images with Google is beyond me. • • • Peter (Southwood)(talk): 08:20, 2 October 2013 (UTC)Reply[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[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[reply]
Sorry, I don't understand "scan from category to article and enter article name in box," could you clarify? • • • Peter (Southwood)(talk): 12:16, 2 October 2013 (UTC)Reply[reply]
I was trying to understand, but I don't get it either. Danapit (talk) 14:16, 2 October 2013 (UTC)Reply[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[reply]
French WV came up with a new UNESCO icon incorporated in page banners. IMO it is a great idea worth considering at English WV, as well. An example is here. --Danapit (talk) 20:37, 10 September 2013 (UTC)Reply[reply]
I like that too. It's definitely worth considering. Nick1372 (talk) 10:56, 12 September 2013 (UTC)Reply[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[reply]
If I understand correctly (see Template:Pagebanner), a destination can have now up to two icons: 1) star and 2) one of DotM/OtBP/FTT. Then we have the geo icon above the banner. --Danapit (talk) 12:37, 14 September 2013 (UTC)Reply[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. --Nicktalk 13:36, 14 September 2013 (UTC)Reply[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. --Nicktalk 14:15, 14 September 2013 (UTC)Reply[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 ▪ talk 09:35, 4 November 2013 (UTC)Reply[reply]
Since there hasn't been any objection raised, and there appears to be support, I'd say go for it. -- Ryan • (talk) • 15:44, 4 November 2013 (UTC)Reply[reply]
Thanks for arranging this. For the actual implementation in banners we might use some kind of table at Talk:UNESCO_World_Heritage_List to see which countries have been done already. Danapit (talk) 09:28, 6 November 2013 (UTC)Reply[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[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:
I'm starting to think the third option is the best in some cases. What do others think? James A ▪ talk 11:56, 6 November 2013 (UTC)Reply[reply]
If you were to visit it, is there anywhere you might logically stay the night besides M'Sila? Texugo (talk) 12:13, 6 November 2013 (UTC)Reply[reply]
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[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 ▪ talk 12:28, 6 November 2013 (UTC)Reply[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[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 ▪ talk 12:55, 6 November 2013 (UTC)Reply[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[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 ▪ talk 13:22, 6 November 2013 (UTC)Reply[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[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[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[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 ▪ talk 13:41, 6 November 2013 (UTC)Reply[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[reply]
The same with me. I don't know if it's a feature or a bug though. Danapit (talk) 10:28, 6 November 2013 (UTC)Reply[reply]
It seems that Template:Pagebanner is enclosed in <div class="noprint">. But does it print a page title at all? Because if it doesn't that may be something to be fixed. Texugo (talk) 12:09, 6 November 2013 (UTC)Reply[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[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 ▪ talk 00:22, 7 November 2013 (UTC)Reply[reply]
Fixed. Someone added the Italian banner to the wrong wikidata item. Now that I removed it, it has no default. Texugo (talk) 20:05, 29 October 2013 (UTC)Reply[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[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[reply]
I think it would be a nice idea as well - I'm all for it! :) --Nicktalk 02:51, 19 November 2013 (UTC)Reply[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[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[reply]
Could someone explain to me how this wikidata works? Very confusing method. Is this why we have a problem at Addis Ababa. --Traveler100 (talk) 19:31, 10 December 2013 (UTC)Reply[reply]
No, Addis Ababa banner was removed from Commons due to copyright violation. I replaced it with different one now. Jjtkk (talk) 21:44, 10 December 2013 (UTC)Reply[reply]
So how do we get article to refer to the default banner if the one on wikidata is no longer there? And how do I see the file name that has been delete? For example with Beijing/Haidian. --Traveler100 (talk) 18:54, 12 December 2013 (UTC)Reply[reply]
Can we remove the use of wikidata? No one will explain how this works to me and I cannot fix broken pages (e.g. Saint-Louis). --Traveler100 (talk) 06:20, 19 April 2014 (UTC)Reply[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". Thatotherpersontalkcontribs 07:12, 19 April 2014 (UTC)Reply[reply]
Thanks for the explanation of how it works. --Traveler100 (talk) 08:13, 19 April 2014 (UTC)Reply[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[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[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[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[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[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[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 am not an expert in aesthetics, therefore I won't try and describe the issue in greater depth. Andrewssi2 (talk) 02:56, 6 January 2014 (UTC)Reply[reply]
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[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[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[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[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[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. :) --Nicktalk 13:47, 5 February 2014 (UTC)Reply[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[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[reply]
From what I understand, mobile users were downloading the banner anyway; they just couldn't see it. Powers(talk) 18:15, 6 February 2014 (UTC)Reply[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. --Nicktalk 23:25, 6 February 2014 (UTC)Reply[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. --Nicktalk 03:57, 25 February 2014 (UTC)Reply[reply]
I wouldn't mind doing it to the notifications icon either... --Nicktalk 03:59, 25 February 2014 (UTC)Reply[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[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[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[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[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[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! --Nicktalk 10:37, 25 February 2014 (UTC)Reply[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[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. --Nicktalk 11:15, 25 February 2014 (UTC)Reply[reply]
We could just bump those icons above the banner onto the same line as the breadcrumbs. The map icon has been sitting up there for a while without bothering anyone. Thatotherpersontalkcontribs 11:19, 25 February 2014 (UTC)Reply[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[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[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[reply]
I'd like to keep both rounded edges and icons the way they are. Danapit (talk) 09:08, 26 February 2014 (UTC)Reply[reply]
Who runs the bot to transfer banners to wikidata, please? There are some 200 items on en wv by now... Danapit (talk) 09:12, 26 February 2014 (UTC)Reply[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[reply]
Hello, I tried to contact user Kizar on Wikidata to run xyr bot for transferring the banners to wikidata, but got no reply. He doesn't seem to be very active lately. Is there any plan B? Nicolas, Texugo, any idea? --Danapit (talk) 13:22, 24 January 2015 (UTC)Reply[reply]
Unfortunately, I haven't a clue when it comes to this type of bot. Texugo (talk) 13:32, 24 January 2015 (UTC)Reply[reply]
Me neither... I don't know if it can only be run by one person (the owner) or somebody else, as well. --Danapit (talk) 13:34, 24 January 2015 (UTC)Reply[reply]
I contacted Kizar at his/her home wiki. Is the source of the bot available somewhere? If not we might have to re-implement it (I am busy with other scripts so no time unfortunately) Nicolas1981 (talk) 08:35, 25 January 2015 (UTC)Reply[reply]
So did I a while ago... We could try and ask around about the bot in the wikidata pub if we don't get any reply. --Danapit (talk) 10:58, 25 January 2015 (UTC)Reply[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[reply]
One of the Beta Features WMF is testing is called "Typography Refresh". You can enable it at Special:Preferences#mw-prefsection-betafeatures, but if you do so, it screws up the display of our horizontal ToC on the banners. Powers(talk) 13:47, 3 March 2014 (UTC)Reply[reply]
Or maybe it's just me? Anyone else seeing this? You can always switch the Typography Refresh setting back. Powers(talk) 13:56, 6 March 2014 (UTC)Reply[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[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[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[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[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[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[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[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[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[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. --Nicktalk 22:34, 6 April 2014 (UTC)Reply[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[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[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[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.
I do see that there may be technical issues though. Nick, could you expand in more detail? PrinceGloria (talk) 04:13, 7 April 2014 (UTC)Reply[reply]
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. --Nicktalk 15:35, 7 April 2014 (UTC)Reply[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[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. --Nicktalk 16:29, 7 April 2014 (UTC)Reply[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[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[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[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[reply]
I said "sometimes". Obviously it's not always true. Powers(talk) 14:05, 8 April 2014 (UTC)Reply[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[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[reply]
One point is if hosted locally they could be easily protected by local admins, but I don't think we do it anyway. Danapit (talk) 13:46, 17 March 2014 (UTC)Reply[reply]
Another reason: might these banners be more likely than other illustrations contain non-free content according to our Exemption Doctrine Policy? Danapit (talk) 13:54, 17 March 2014 (UTC)Reply[reply]
Talk:Main Page#Proposed Main Page Specifications indicates that local banner upload is done to allow admins to protect them while they are being featured, thus preventing a main page image from being changed to something that would be extremely embarrassing for the site. -- Ryan • (talk) • 15:21, 17 March 2014 (UTC)Reply[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[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. --Rschen7754 21:00, 17 March 2014 (UTC)Reply[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[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[reply]
That is not correct; only admins can upload a file using the same name as what is on Commons. --Rschen7754 17:55, 18 March 2014 (UTC)Reply[reply]
Pros:
Keeps our list of Special:ListFiles low and manageable, helps to keep track of local Fair Use files and whatnot.
Possible reuse on other language Wikivoyages, and even third-party reusers (InstantCommons) which is what we want per our licensing right?
Cons:
Local upload/create-protection still necessary to prevent overriding the shared repository version.
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[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.
I looked at all banners of destinations I know, but none of the suggestions were an improvement. --FredTC (talk) 19:54, 6 April 2014 (UTC)Reply[reply]
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[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[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[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[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[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[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[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[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[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[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[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[reply]
You could tell the same thing in a brief message. --Saqib (talk) 23:29, 26 May 2014 (UTC)Reply[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[reply]
I think this is a fine idea - go for it! --Nicktalk 21:39, 12 September 2014 (UTC)Reply[reply]
Thanks. I had forgotten all about this! But this should still be a priority, as nothing much has changed. I've added this as a priority under Wikivoyage:Banner Expedition#Goals. Ikan Kekek (talk) 21:55, 12 September 2014 (UTC)Reply[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. Thatotherpersontalkcontribs 09:48, 13 September 2014 (UTC)Reply[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[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[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[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[reply]
Preferably not. We have the summary sections on the file's page on Commons for that purpose. --ϒpsilon (talk) 15:39, 28 October 2014 (UTC)Reply[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.
Which is right? And can we provide clearer guidance on the subject? --Andrewssi2 (talk) 05:07, 19 December 2014 (UTC)Reply[reply]
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[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[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[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[reply]
My understanding of the banner code is that it only loads the 1800px thumbnail and then sizes it dynamically based on the width of the browser window. If that's the case, sizes over 1800px should have no deleterious effect on performance. Powers(talk) 13:26, 19 December 2014 (UTC)Reply[reply]
Large PNG files take long to load. Too many of our users would load these pages + banners at locations around the globe with slow Internet connections. For this reason I do not favor having high resolution 5 mega byte PNG files used instead of compressed 180 KB JPEGs. LtPowers - a 5 MB PNG file takes longer to load. I would recommend that you go aborad and test loading such banners in Wikivoyage from India or something to really realize how much more slower those load than the JPEG banner I created for New York City for example. ויקיג'אנקי (talk) 14:38, 19 December 2014 (UTC)Reply[reply]
That is a ridiculously impractical suggestion. The fact that the banner you created is a JPEG should be completely irrelevant when it comes to load times because the Mediawiki software creates all thumbnails as PNGs. If our banner code is loading a pre-generated 1800px thumbnail, there should be very little difference between banners. Powers(talk) 16:00, 19 December 2014 (UTC)Reply[reply]
Apologies, after checking, it appears Mediawiki only converts SVGs to PNG for thumbnailing. JPEGs remain JPEGs as thumbnails. Nonetheless, the thumbnails are indeed generated and cached at 1800px; you can confirm this by right-clicking a banner and opening the image in a new tab (or saving the image to your hard drive). You will see that the image actually displayed to the user is the 1800px thumbnail, not the full-size original. Powers(talk) 16:09, 19 December 2014 (UTC)Reply[reply]
Right now we recommend a banner of 2100x300, but Template:Pagebanner resizes that to a width of 1800. The trade-off we're facing is that a lower-res banner looks bad on big screens, but a higher-res banner uses up bandwidth unnecessarily on smaller screens. Wikivoyage:Travellers' pub#Would you be interested in a PageBanner extension?* is an attempt to resolve that issue by downloading banners that are sized appropriately for the user's screen, but it might also be possible to implement a Javascript solution to this issue that uses a smaller banner by default and then replaces it with a larger banner for users with large screens. Since that replacement could be done on DOM load the process would likely be transparent to the user. Time permitting I'd be interested in working on a proof-of-concept for such a solution unless anyone sees any holes in that design, and I think it would then allow us to have recommendations to create banners that were as big as people could find (i.e. a minimum width of 2100px for the original), would improve download times for users with small screens since smaller images would be used for them, and would look better for users with huge screens since larger images would be used for them. The experience will be sub-optimal for users with Javascript disabled (we could default to the existing behavior those users encounter today), but I think that holds true for most of the web these days. Thoughts or comments? -- Ryan • (talk) • 17:06, 19 December 2014 (UTC)Reply[reply]
* does anyone know if the proposal to create a module for page banners is moving forward? [1] seems to have gone silent.
It's pretty much waiting for a developer to raise his or her hand and agree to work on it. There's nothing else to move forward on, really. I'm also not clear on whether the proposed module is intended to be coded so that only an appropriately-sized thumbnail is downloaded.
Re: your proposal, I'd like to see some concrete numbers on how big a problem this is. Our banners are currently less than half a megapixel (1800x257); for anyone browsing on a connection slow enough where that's a problem, I would argue they should probably be browsing the web with images off anyway.
Since this is a subject that would affect all the other Wikivoyage communities as well (and on the long run, the EngVoy community should want to have all Wikivoyage communities working together on making and using page banners because there are a lot left to create), I suggest that this discussion would first and foremost be held with users from other Wikivoyage communities as well - maybe in this discussion page? ויקיג'אנקי (talk) 05:57, 20 December 2014 (UTC)Reply[reply]
Isn't this just a very simple thing to solve? If I understand the discussion above it doesn't matter what size the banner is as long as it is scaled 7:1 and is in JPEG format. Wikimedia will apply the appropriate scaling for WV. We shouldn't use PNG format for photos because that is just not good practice.
In future, when somebody rewrites the banner extension then we can take advantage of the higher resolution images that we have. And seriously, in 5 years most people will be using very high resolution screens and we will have to run through ALL the articles and uploading new banners! We want to avoid this. Andrewssi2 (talk) 09:10, 20 December 2014 (UTC)Reply[reply]
The traveller comes first - for this reason, loading huge banner image files while in India for example might be much excruciating for the actual travlers in that region using slow Internet connections to read the India guides (yet you rather support the interest of the Western countries readers that would be loading huge banners at their homes on their wall projectors in 2025). ויקיג'אנקי (talk) 19:52, 20 December 2014 (UTC)Reply[reply]
You earlier mentioned "5MB PNG files" -- can you give an example of an article that has a 5MB PNG banner atop it? Powers(talk) 20:09, 20 December 2014 (UTC)Reply[reply]
The traveller comes first is not a valid response. We have established that using a JPEG banner will result in a scaled image.
Also we should not be using PNG for photos anyway! The format is suited for diagrams and should not be used for banner pictures. Andrewssi2 (talk) 21:33, 20 December 2014 (UTC)Reply[reply]
Just a little real world investigation with Google Chrome developer tools. The banner for Germany is a whopping 6MB in size and following the belief of ויקיג'אנקי this will mean every single visitor will have to download this 6MB file to view the Germany article.
Looking at the actual resources downloaded (Chrome->Tools->Developer Tools->Resources), the Germany article downloads a scaled image of 2560 × 370 with a file size 394 KB on my laptop as well as a second file of 3600 × 520 with a size of 743 KB
This does suggest that the code that renders banners needs to be looked at (why two files?), but it is just wrong to suggest that the original banner image is currently downloaded in full.
The answer is that banners should be JPEGs and can be any large size you want. Why is this so complicated? --Andrewssi2 (talk) 22:06, 20 December 2014 (UTC)Reply[reply]
I tried again and only got one! I didn't clear my cache (sorry). The new (single) image is 3600 × 520 with a file size of 743 KB. This might be explained by the fact I have a MacBook Pro with a Retina display.
Since Chrome has an emulation function I tried a 'generic notebook' with a display of 1280x800 and the new banner dimensions were 1800 × 260 with a file size of 195 KB, so it probably is based on the browser info.
In any case, I think the suggestion above that banner images should be small because they do not scale is a myth. We should use large images as we can because they will be scaled. --Andrewssi2 (talk) 01:51, 21 December 2014 (UTC)Reply[reply]
I believe your Retina display may be upscaling the 1800px banner, because the template code should only be retrieving an 1800px thumbnail. I suggest checking an article where the original file size is much smaller, like Arillas. If that banner also shows up as 3600, then we know it's upscaling (because the original is only 2100px). Powers(talk) 02:00, 21 December 2014 (UTC)Reply[reply]
Powers , perhaps not. The dimensions for the Arillas banner are 2100 × 300 with a file size of 115 KB (I refreshed the page to make sure this was the case). These are also the dimensions of the source of that banner on Wikimedia. --Andrewssi2 (talk) 02:12, 21 December 2014 (UTC)Reply[reply]
Andrewssi2: Can you list the exact steps you're using to get your numbers? The file File:Arillas Wikivoyage banner.jpg has dimensions of 2100x300, but unless there is some code somewhere that I'm not aware of, that file is rendered on Arillas after being resized to 1800px - all of the "File:" calls in Template:Pagebanner include an argument of "1800px". For that file to show up at any other size than 1800px in the Arillas article means that we've got some other call somewhere that is fetching a larger-sized banner image, but so far I haven't found anything that I can see would be doing that. -- Ryan • (talk) • 02:31, 21 December 2014 (UTC)Reply[reply]
I think we are moving into the realm of screenshots :) I will do this later today.
That said, even if WM does provide (slightly) larger images for my MacBook Pro, I think it has little impact on the core of the discussion above in that we can certainly afford to use high resolution Banner images just as long as they use the recommended JPEG format. Andrewssi2 (talk) 03:09, 21 December 2014 (UTC)Reply[reply]
It is understood that Wikimedia will scale down banner images to 1800 pixel width, no matter what the size of the source image is.
I reported seeing a higher resolution banner of 3600 x 520 pixels for the Germany article banner when viewed with Chrome for MacOS Mavericks on a MacBook Pro Retina (13"). I went into 'incognito mode' to be sure nothing was confusing the results. Here is a screenshot:
Interesting. For comparison, I tried to right-click and download the banner pic for Germany and the downloaded photo was 1800 x 260 pix. I am using a Samsung laptop with Win7 and Firefox. Danapit (talk) 10:38, 21 December 2014 (UTC)Reply[reply]
That's exactly what we'd expect to see if we used the image syntax [[File:Ötlingen - Panoramaansicht klein banner.jpg|3600px]], but we're not. We're using 1800px, so that should be the only thumbnail image being transmitted from WMF servers. Powers(talk) 16:03, 21 December 2014 (UTC)Reply[reply]
Thanks Andrewssi2. Based on those screenshots I would assume that there must be some Javascript somewhere pulling in the larger file sizes, but I can't find anything in Template:Pagebanner or in MediaWiki:Common.js that would do so. There is some Javascript on the image that looks like it's for the image viewer, but that's all I've found so far. It would be nice to know what's going on, as this functionality would likely be easy to re-use to provide different file sizes based on screen resolution. -- Ryan • (talk) • 16:46, 21 December 2014 (UTC)Reply[reply]
A bit more investigation. I tried with a standard Windows 7 laptop and I got 1800 x 260 pixels (as you expected)
I then tried the Chrome emulation for Galaxy S4 smartphone, both desktop view and mobile view, and guess what? I got the larger banner size:
Standard Windows 7 laptop:1800 x 260
Samsung Galaxy S4 mobile view: 3600 x 520
Samsung Galaxy S4 desktop view: 3600 x 520
I am guessing that the Template:Pagebanner is instructing all images to scale to 1800x260 when it detects a Windows browser agent. Otherwise (Mac OS, mobile device, etc) it instructs a different scaling.
I would say this is a big issue for anyone using a mobile device, since they are likely downloading a much bigger banner than they need. Andrewssi2 (talk) 23:00, 21 December 2014 (UTC)Reply[reply]
Reproducing your test I'm seeing other images being downloaded as 440px images, where on fullsite they are downloaded as 220px images. This problem is apparently general to all images on mobile devices, and not specific to the page banner. Perhaps @Jdlrobson: can provide some insights. -- Ryan • (talk) • 00:01, 22 December 2014 (UTC)Reply[reply]
Nice detective work. Perhaps Mediawiki doubles all thumbnail sizes on mobile? Powers(talk) 02:25, 22 December 2014 (UTC)Reply[reply]
This is not mobile specific. MediaWiki implements larger images for retina devices. If you look closely at the output HTML, any image tag will have a srcset attribute set. This will scale the image up to 2 times the requested resolution. The only way to get round this in a template is to use background-images instead of image tags.
There are various problems with banners implemented in current form and the more issues I see the more I think we should implement this as an extension. See https://phabricator.wikimedia.org/T77925 (note you can login and comment and help move this along using your Wikivoyage username and password!). Hope this is helpful. Jdlrobson (talk) 21:29, 22 December 2014 (UTC)Reply[reply]
Thanks, I suspected this was not mobile specific although it must impact all high end mobile devices these days. I will try and join the discussion that you linked to. Andrewssi2 (talk) 04:17, 24 December 2014 (UTC)Reply[reply]
A common error when making page banners is distorting the aspect ratio during cropping process. As avoiding the distortion doesn't seem to be obvious and I didn't find anything on this matter in the project page, I suggest we add it, for example in this section (the suggested new sentence is bolded here):
Make a good composition. Most images, ... have to be corrected when found. Resize image without distortion (keeping aspect ratio).
Any objections? Can anybody help me to re-phrase the sentence, if it is not understandable? Thanks! Danapit (talk) 09:15, 17 February 2015 (UTC)Reply[reply]
Good addition! I might rewrite "When resizing images you should ensure that you keep the correct aspect ratio in order to avoid distortion" Andrewssi2 (talk) 10:09, 17 February 2015 (UTC)Reply[reply]
Feedback for pagebanner extension for wikivoyage[edit]
Hi all, there's a discussion on a project for developing the functionality provided by the pagebanner template into an extension here, with a purpose to make the banners render well on mobile in addition to desktop. It would be great to get feedback as well as if someone could help along, in providing valuable suggestions as to the look and feel of the banners in the new extension as the project progresses. Thank you!-Sumit (talk)
Earlier this year we had an interesting discussion around page banner guidelines. It appeared that Hebrew Wikivoyage were making two major mistakes which were (1) using PNG format for photos, which is generally a bad idea and (2) limiting the sizes to 2100x300 because Wikimedia can't resize PNG. We also discovered that high definition screens had larger banners renders automatically by Wikimedia, even if it was a small device like a phone.
Anyway, I think now that the facts are known, we should clarify the advise to:
Banners must use JPEG format
Banners must have a 7:1 width to height ratio
Banners should be as wide as possible and need to be at least 1800 pixels wide to accommodate wide screens. The recommended minimum dimensions are of 2100 x 300 pixels
That sounds fine to me, but it if the guidance is updated it would be helpful to include an explanation about why JPEGs are being recommended in case people wonder. -- Ryan • (talk) • 05:35, 23 March 2015 (UTC)Reply[reply]
I thought those were already our preferred guidelines. Powers(talk) 19:14, 23 March 2015 (UTC)Reply[reply]
Are the guidelines called out somewhere other than on the expedition page? Banners have moved far beyond the expedition phase at this point, but Template:Pagebanner just points to the expedition and Wikivoyage:Banners doesn't exist. If we don't already have a policy page for banners then one should be created. -- Ryan • (talk) • 19:23, 23 March 2015 (UTC)Reply[reply]
I was thinking that. We only seem to have the expedition page and the Template page itself. Can we start working on Wikivoyage:Banners ? Andrewssi2 (talk) 00:00, 24 March 2015 (UTC)Reply[reply]
I'm not sure I understand what "scaling for different page sizes" has to do with PNG vs. JPEG in the text proposed below. After reading #Banner Size Guidance, it seems like the argument for JPEGs is based on trying to use banners with smaller file sizes and thus faster page load times? As to a Wikivoyage:Banners page, I would very much be in favor of seeing someone start that - it could be easily done by just copying the text from the expedition page that is relevant to banner implementation (as opposed to the bits about expedition members, banner rollout on the site, etc). I think a separate page for that information makes sense, rather that putting it on the image policy page, although the two pages should definitely reference each other. -- Ryan • (talk) • 05:22, 24 March 2015 (UTC)Reply[reply]
I understood from the discussion that a PNG file wouldn't scale, and the full size image would be downloaded regardless. A corresponding JPEG image would be scaled in the same scenario, thereby resulting in smaller file sizes and quicker rendering.
See the example at right - PNGs seem to be scaled properly by Mediawiki. That aside, a pointer to Wikivoyage:Image policy#Image formats, with additional text explaining the file size advantages of JPEGs vs PNGs, would be helpful for whatever banner guidance is created. -- Ryan • (talk) • 05:43, 24 March 2015 (UTC)Reply[reply]
Yes, it seems standard PNG images have no issue to scale. I wonder what the Wikivoyage Hebrew issue was then... Andrewssi2 (talk) 23:41, 24 March 2015 (UTC)Reply[reply]
Occasionally I have added banners which were existing images on commons that just happened to be almost 7:1. To cater for these cases, I would suggest that such existing images must be between 6.8:1 and 7.2:1, and be cropped if they are outside this range. I am also wondering if we should give a maximum size - 21000 x 3000 maybe for performance reasons.
As an example Spiš has a banner which is 12,854 × 1,824 (7.05:1). AlasdairW (talk) 23:22, 24 March 2015 (UTC)Reply[reply]
I'd be in favor of some flexibility on the point of the ratio. At this point we probably want to encourage as many new banners as possible even if the ratio is not completely precise. At the same time we should allow for someone else to later update that image with the 7:1 ratio without major consultation.
Maximum size is interesting... we just don't know what we will be dealing with in 10 year's time. I'd say we should not have a maximum but leave the scaling to Wikimedia, unless that is otherwise a problem? Andrewssi2 (talk) 23:41, 24 March 2015 (UTC)Reply[reply]
A quick look at Spiš on a Windows laptop suggests the downloaded banner image is only 1800 pixels across. The download speed was instant over a 4G network. --Andrewssi2 (talk) 23:45, 24 March 2015 (UTC)Reply[reply]
7:1 only, as far as I'm concerned. The whole point is to keep that banner element as a consistent interface element. Powers(talk) 02:03, 27 March 2015 (UTC)Reply[reply]
With the range of 6.8:1 to 7.2:1, I am suggesting a tolerance of about +/-3%. I have used existing images in the banners for Spiš, Perth and Kinross, Dunedin and Dunbar. Dunbar is the most "out of spec" at 7.12:1. Looking at this on a large screen, I do see a grey line at the bottom of the picture, but this is not a big issue. Dunbar gives a picture of 1800x253, against a standard one of 1800x257, Spiš is 1800x255, and the other two are 1800x256. AlasdairW (talk) 00:16, 28 March 2015 (UTC)Reply[reply]
I think that it should remain firmly at 7:1, however we can make it clear that banners of a slightly different dimension are preferable to having no banner at all. --Andrewssi2 (talk) 21:27, 28 March 2015 (UTC)Reply[reply]
Banners which are not exactly 7:1 should be tagged with a maintenance category. Preferably immediately. I forget the template details. • • • Peter (Southwood)(talk): 03:58, 29 March 2015 (UTC)Reply[reply]
I forgot about that template. {{crop}}
This banner needs to be cropped to the aspect ratio of 7:1 with width ≥ 1800 pixels. Otherwise, it may be reverted.
Banners must use JPEG format in order to allow scaling for different page sizes, as well as general web design best practice
Banners must have a 7:1 width to height ratio
Banners should be as wide as possible and need to be at least 1800 pixels wide in order to accommodate wide screens. The recommended minimum dimensions are of 2100 x 300 pixels
Banners should be as wide as possible and need to be at least 1800 pixels wide in order to accommodate wide screens. The recommended minimum dimensions are of 2100 x 300 pixels
I'd vote for the first option. If people do end up preferring the second, though, it should at least have a lowercase P in policy. Texugo (talk) 23:14, 25 March 2015 (UTC)Reply[reply]
Having just landed at Penang International, I thought I'd look at your George Town article. Huge and informative but lacking a table of contents like Wikipedia or Wikitravel. Since you seem to use the same software is there a good reason for this omission - or is it just an oversight?
218.208.95.130 00:58, 4 May 2015 (UTC)Reply[reply]
Georgetown (Malaysia) does in fact have a table of contents embedded in the banner. Are you not able to see it?
Also what device / browser combination are you using? Thanks, --Andrewssi2 (talk) 01:08, 4 May 2015 (UTC)Reply[reply]
It's rather counterproductive to embed it there since it spoils the hero image and means that many folks will miss it. Your minimalist (but still intrusive) ToC also seems sadly lacking in functionality since, unlike the usual Wikipedia style contents list, I can find no way to expand it to H3 and H4 level headings. If I'm interested in a Splurge level hotel, I don't wish to wade through all the Budget listings to get there. And, of course, it's totally lacking in the mobile view...
I originally used the Chrome browser on an Android LG phone and then, when I eventually got to my hotel, a laptop running Firefox under Windows 8.1 (Ugh!).
Incidentally, this article is named wrongly. Officially (central and local government and UNESCO) it's always been two words George (and) Town since the very first maps were created in the English language. Just because many folks have struggled to use English when their native language was Hokkien, Arabic, Malay or Tamil doesn't mean we should perpetuate the heterodox. 118.101.139.200 01:04, 5 May 2015 (UTC)Reply[reply]
Well, moving it is easy. I used to live in Malaysia in the 70s and remember seeing it as one word most often. I did a Google search and found that the two-word version is used a bit more often than the single-word version, so I'll go ahead and move the article. Ikan Kekek (talk) 01:06, 5 May 2015 (UTC)Reply[reply]
Thanks, (fish soup?). Google often gets things wrong. It's particularly bad on the correct physical location of Spanish cathedrals, for example... 118.101.139.200 01:26, 5 May 2015 (UTC)Reply[reply]
Fish soup is sup ikan. Ikan kekek is a particular type of fish. Ikan Kekek (talk) 06:34, 5 May 2015 (UTC)Reply[reply]
Yes, WV's table of contents implementation has been badly broken for quite some time. There has been a lot of discussion; see Wikivoyage talk:Banner Expedition#Renew TOC discussion and elsewhere on that page, but no solution implemented. I'm not sure what it would take to get this fixed. Pashley (talk) 11:33, 5 May 2015 (UTC)Reply[reply]
The Wikimedia Foundation's technical staff has expanded greatly in numbers and competence in recent months. You might try asking for technical assistance to implement a horizontal, hierarchical and expandable table of contents at https://phabricator.wikimedia.org/tag/phabricator/
For people in locations with slow and/or expensive metered connections a good ToC may be thought important. On that topic, you might also ask them to ensure that text is loaded very first and before any resource hungry resources such as images and maps. 175.138.97.134 11:42, 8 May 2015 (UTC)Reply[reply]
Hello Wikivoyagers. I have been experiencing the same problems as the original IP user for a couple of weeks now on all articles. The banners are there but there are no tables of contents on any of the articles I view or edit. Since this doesn't appear to be an issue for many / any other users (I haven't come across any other discussions on the matter) it is presumably an issue with my browser, which is just bog-standard Chrome. Any ideas or suggestions? Warmest regards, --ThunderingTyphoons! (talk) 14:41, 18 May 2015 (UTC)Reply[reply]
Apparently they don't work without Javascript? K7L (talk) 15:15, 18 May 2015 (UTC)Reply[reply]
Thanks for the suggestion, though I do have Javascript enabled. :-) --ThunderingTyphoons! (talk) 22:35, 18 May 2015 (UTC)Reply[reply]
Dubious guideline - can we not show people in banners?[edit]
The following guideline was just added:
"To respect privacy, avoid pictures of identifiable people"
Some of my banners have clear pictures of people. What is meant by 'identifiable' in this respect?
I think travel would be be dry if we only looked at monuments, with no life around them --Andrewssi2 (talk) 11:10, 4 June 2015 (UTC)Reply[reply]
The person should not be the main focus of the image (unless you have had permission), faces at a distance as part of the overall scene should be OK. --Traveler100 (talk) 11:50, 4 June 2015 (UTC)Reply[reply]
I would avoid images where the person's face is taller than the article title that appears on the banner. It might come as an unpleasant surprise to some readers if they saw a photo of themselves as they looked five years ago. In some countries permission is required to publish a photo of an identifiable person see: Commons:Commons:Personality rights. In a couple of cases I have edited a banner image to remove a conspicuous face, but that now appears not to be allowed according to Wikivoyage:Banners, which has different guidelines to those here. AlasdairW (talk) 22:26, 4 June 2015 (UTC)Reply[reply]
The paragraphs has been clarified. Of course, banners can feature professionals, performers and other people who are part of an attraction; see Religion and spirituality and Manhattan/Theater District. I made a Respect banner where faces were blurred to be safe better than sorry; there are probably better solutions. /Yvwv (talk) 22:53, 4 June 2015 (UTC)Reply[reply]
Thanks, a strict interpretation of the previous wording would have made it near impossible to use any people at all!
In terms of the new wording, we have the phenomenon that digital photographs are getting higher resolution all the time. A crowd of 100 people may probably have many (if not all) their faces visible in high resolution.
I agree that a banner should not focus on one person or small group of people (exceptions for public performers as mentioned above), but do we really need to go for blurring in terms of a large crowd of people? --Andrewssi2 (talk) 23:32, 4 June 2015 (UTC)Reply[reply]
Shouldn't the banner policy align with our image policy? I agree the banner shouldn't focus on one identifiable person or small group, but I think blurring faces in a crowd in a public place or only permitting public performers is more strict than it needs to be. -Shaundd (talk) 03:52, 5 June 2015 (UTC)Reply[reply]
Our image policy for people in photos is not particularly useful. The Commons:Photographs_of_identifiable_people is detailed and comprehensive. The banner should focus on the place, not random or arbitrary people. Any photo that requires pixellation or similar to prevent identification is inherently unsuitable for a banner. • • • Peter (Southwood)(talk): 08:26, 6 June 2015 (UTC)Reply[reply]
Generally I agree that banners for destinations should focus on the place. Unfortunately sometimes the best photos on commons do have people in them. Travel topic banners are more likely to need people in them to be relevant to the topic, and blurring may be appropriate in this case, as was done for Respect, as readers might infer that an identifiable person supported the advice in the travel topic. AlasdairW (talk) 14:17, 6 June 2015 (UTC)Reply[reply]
Inferring that an identified person in a banner would support the advice given in the article is rather far fetched. Andrewssi2 (talk) 23:30, 6 June 2015 (UTC)Reply[reply]
Avoid using Nazi monuments for cities in Germany[edit]
There is another guideline which I agree with, but the example used is bad:
"Prefer motives that would make the locals proud, without too much controversy. For instance, avoid using Nazi monuments for cities in Germany."
I lived in Germany for a few years and never once saw a Nazi monument. They were mostly destroyed or covered up after the war, and anyway it is actually illegal to display Nazi symbols in Germany.
Examples of Nazi architecture still do exist (Templehof airport and the Olympic Stadium in Berlin) but I don't see anything wrong in using them.
I don't know how far we should go with this. There's a huge skyscraper in Warsaw that was a gift from Stalin. It's therefore controversial, but it's still an important sight. Should it be per se excluded from a pagebanner? Ikan Kekek (talk) 00:27, 5 June 2015 (UTC)Reply[reply]
Also any skyline of Pyongyang will include the Ryugyong hotel (the massive pyramid structure). It is a constant source of embarrassment to the local population (well, perhaps more the leadership) since it is a showcase building that never got completed. It is nevertheless a defining part of the city.
After reading Ikan's comment, I'm actually now inclined to agree to remove this guideline altogether. --Andrewssi2 (talk) 22:38, 5 June 2015 (UTC)Reply[reply]
How about: Avoid using images that would be offensive to the inhabitants. Examples are not really needed. If an inhabitant finds the banner offensive, they can let us know.• • • Peter (Southwood)(talk): 08:12, 6 June 2015 (UTC)Reply[reply]
The only "Nazi monument" (apart from former concentration camps) that I could think of in Germany is the Reichsparteitagsgelände (Nazi party rallying grounds) in Nuremberg. And while its Swastika was famously blown up by the Americans, it is still recognizable as Nazi architecture. That being said, it is unlikely to be featured in a banner, unless Nuremberg gets districtified, because most non-German visitors will care more about the old town than the Nazi era. That being said, there is some merit in this policy, as it might help discourage edit wars. While North Korean propaganda trolls are probably not our main concern, imagine if for some reason we put up a pagebanner that is perceived as insulting king Bhumibol of Thailand. Even John Oliver got into trouble for being perceived as having insulted the Thai royal family. Hobbitschuster (talk) 11:21, 6 June 2015 (UTC)Reply[reply]
We have at least one example of Nazi architecture banner, for Prora article. I don't find anything offending about it though. Danapit (talk) 14:32, 6 June 2015 (UTC)Reply[reply]
But I do think that Prora is "Nazi architecture" in the sense that no other type of regime would have built something like this... Hobbitschuster (talk) 20:17, 6 June 2015 (UTC)Reply[reply]
The text has now excised all reference to the Nazis (a good idea generally on the Internet) Andrewssi2 (talk) 23:32, 6 June 2015 (UTC)Reply[reply]
Adding the banners was a fine idea in several ways, but it wrecked the tables of contents. Banners show only top-level headings and there is no way to get lower-level ones. Discusssion on this started over two years ago at #Add a "full TOC" button? and was extensive; several solutions were suggested but none implemented. The conversation petered out late last year.
Can we restart the conversation? Or better yet, fix the problem? Pashley (talk) 20:21, 26 June 2015 (UTC)Reply[reply]
I made a list (here) of city entries that I thought need banners. Of course some of them are in more desperate need than others (like Constanța, before Lexington). --AmaryllisGardenertalk 19:00, 7 August 2015 (UTC)Reply[reply]
Just out of interest, why do these destinations require banners in particular? --Andrewssi2 (talk) 23:27, 7 August 2015 (UTC)Reply[reply]
We are about to deploy Sumit's new banners implementation to Wikivoyage English. As the Wikimedia rules stipulate, we need this discussion to show that the community approves the deployment. So, please voice your approval or disapproval below, thanks a lot! Notes:
At first the extension will only target a handful of test pages. So nothing will break overnight because of the deployment.
A demo is available, there are still a few minor bugs that should be fixed in the next few days, but we should not wait until everything is 100% perfect, as the deployment paperwork process will take some time. We will iron out the last details on test pages here.
I am obviously in favour of deploying this extension. Syced (talk) 10:05, 8 July 2015 (UTC)Reply[reply]
The new menu drop downs look really good! I'm concerned about the following however:
1) There is still no menu in the mobile view (tested on Safari on an iPhone 6). Is there plan to introduce?
2) The banner on your test page is very blurry on a Macbook Pro Retina with the Safari browser. The same banner used on Asia looks fine. Therefore this looks like a significant bug. (The Chrome browser is fine for both your test page and Asia.
Personally I'd prefer all significant bugs get fixed before installing, because... well I work in software and I just know it is easier to fix before than after :) --Andrewssi2 (talk) 10:39, 8 July 2015 (UTC)Reply[reply]
Are there any changes beyond the drop down menu? (which I am heavily in favor of, btw). Hobbitschuster (talk) 10:56, 8 July 2015 (UTC)Reply[reply]
From the project page, it seems that Wikidata integration is more flexible (you can specify which Wikidata item to bind to) and a wider range of sizes is supported (not quite sure how it works, but I'm happy to get higher resolution banners) Andrewssi2 (talk) 11:09, 8 July 2015 (UTC)Reply[reply]
What about the categories created with the current template for tracking usage of custom and default banners? --Traveler100 (talk) 11:18, 8 July 2015 (UTC)Reply[reply]
I get an image with low resolution and without any menus (Opera on Debian desktop). Does the functionality rely on specific settings (javascript etc.), perhaps on a site other than the visited one? --LPfi (talk) 14:34, 8 July 2015 (UTC)Reply[reply]
When returning to the page the menus had appeared. Really slow? Still 320x46 image. --LPfi (talk) 14:37, 8 July 2015 (UTC)Reply[reply]
Like User:Andrewssi2, when using the Safari browser the banner looks like something taken with a decade-old cell phone camera. The dropdown menu works fine. On Firefox the banner looks normal. ϒpsilon (talk) 17:58, 8 July 2015 (UTC)Reply[reply]
The review before deployment will still take time, till when I'll keep resolving issues. With respect to workboard, I'm left with this major task on TOC. However, an important part is capturing issues that I might have missed, so feel free to add more of them if you find, the earlier, the better. I've already created a task here to explore the blurry banners issue raised above. I'll add more if needed.
Banner without menus as stated above will be resolved by the above mentioned task(T103569).
On a final note, I'd like to bring your attention to the task T105033 which talks about banners on narrow mobile screens and explores some options. That task is just an initial discussion on the issue and currently not part of the plan. So views on that task will help improve and take forward the issue of small banners on screens as small as 320px width.
So is this command intended to be placed in the existing pagebanner template and then we build round it the category logic and additional icons? If so any issue with the name of this function being the same as the the template? Also documentation use two different spelling for banner. --Traveler100 (talk) 20:11, 9 July 2015 (UTC)Reply[reply]
Thanks for pointing out the typo, it is now fixed! Syced (talk) 08:39, 10 July 2015 (UTC)Reply[reply]
This looks good. Just a couple of comments from me:
The text in the drop down menus can be hard to see (it clashes a bit with the underlying text) -- maybe we should have less transparency in the menu bar once this is implemented (I'm not sure if it's still relying on the local CSS or if it's part of the banner extension)
I'm confused as to how it gets banners. Looking at how the extension is used on the demo page, it seems a user just provides the name of a Commons image; but the project page makes it sound like it's coming from a Wikidata property. Can the extension handle both? -Shaundd (talk) 13:49, 10 July 2015 (UTC)Reply[reply]
Hello! Regarding categories and clash with existing pagebanner:
Extension's magic word is PAGEBANNER which will not clash with pagebanner. In order to incorporate this extension's parser function in Template:Pagebanner, simply call {{PAGEBANNER...}} with options inside the template. For a live example see this template's source whose name is the same as this wiki's Template:Pagebanner and it uses the extension's parser function to render a banner on the page it is used. The page http://pagebanner.wmflabs.org/wiki/Canada uses this template.
Categories for banner pages as a feature are soon to be added and is being tracked at https://phabricator.wikimedia.org/T101229. I've added a few suggestions there myself. Using the extension's {{PAGEBANNER}} inside Template:Pagebanner would preserve the existing category structure.
In reply to Shaundd's second point, user's can add any commons or local image using {{PAGEBANNER:Image_name.jpg}} but in case users do not use any image name, it tries to get image from Wikidata if defined. Check out the source of this example http://pagebanner.wmflabs.org/wiki/New_York.
OK, I decided to give cropping banners a go, even if it's not usually my cup of tea. I have a few questions though, for which I haven't found the right answers on the expedition page (although that might just be me). Hopefully one of you can answer? :)
If I use an image from Flickr, do I need to upload the original file to Commons first, or can I upload only the cropped version/banner?
If I use an image that's on Commons, is it enough to just link the original file as source, or do I somehow need to file it as a derivative work? The expedition page suggests using DerivativeFX, but that tool seems to be offline?
I'm a bit confused about the allowed sizes. It needs to be at least 1800 wide. 2100:300 is recommended, but in the end it's about the 7:1 aspect ratio. So, if I have or create a 7:1 image that's somewhat larger, is that still okay? Or is 2100:300 also a maximum?
To answer your last point, banners can be much larger than 2100:300. I have used 3500:500 for several banners. I think that we did discuss having a suggested upper limit somewhere, but it was not thought to be needed. I would consider down sampling if the image was going to be over 6300:900, but that is partly to reduce the upload time. Also see draft guidelines in: Wikivoyage:Banners. AlasdairW (talk) 23:19, 15 August 2015 (UTC)Reply[reply]
Re #2, I've seen it done both ways. I usually link back to the original image and note the original author, while describing the changes I made. None of the banners I have handled that way has questioned so far. An example is Commons:File:Similkameen banner valley view.jpg. -Shaundd (talk) 04:49, 16 August 2015 (UTC)Reply[reply]
JuliasTravels, I think it is in princliple ok just to upload the cropped version to Commons from Flickr, but it is pity not to have the full picture in Commons once someone uploads anyway. Instead of DerivativeFX I use flickr2commons tool nowadays. It took me a while to make it work, it needed a permission when I used it for the fisrt time and then it only worked when I restarted the browser. But otherwise it works very well. Once the picture is in commons, you should still refer to the original file on Flickr, because when you select the Flickr licese, the picture goes through a review and the commons admins find it easirer to check it if they have the original source. Plus I use template ´´derived from´´. YOu can have a look at this pic I uploaded recetly and the banner I derived from it. Like this it is well documented how the file is further used. The banner can be any size larger than 1800 pix in the correct ratio. This is one way to do it, others might works in a slightly different way. Danapit (talk) 05:06, 16 August 2015 (UTC)Reply[reply]
One pitfall that I encountered was that even if the Flickr source image on which the Banner was based is moved to MediaWiki, you still need to reference the original Flickr location.
Another fun one I saw last week was a slight variation of the CC license of an image used on Flickr (that didn't allow derivative works) resulting in my banner being rejected. Andrewssi2 (talk) 10:41, 16 August 2015 (UTC)Reply[reply]
Thanks for all your comments; it's a lot clearer to me now :-) JuliasTravels (talk) 11:18, 16 August 2015 (UTC)Reply[reply]
Banners extension: all reported bugs have been fixed. Asking again for consensus[edit]
Thank you for all the feedback about the new banners extension! Sumit worked hard for 10 days, and now all bugs you have reported have been fixed! You can try it here: http://pagebanner.wmflabs.org/wiki/Roppongi
This extension is essential to having Wikivoyage display correctly on mobile. It is important that we deploy it well before Sumit's GSoC is over, so that it can be tested in real situation and fine-tuned correctly. For this, we need everyone's consensus below. Deployment will start with a few test pages. Due to paperwork it takes time before consensus and actual deployment, so we would greatly appreciate your cooperation to move forward. Thanks! :-) Syced (talk) 04:09, 17 July 2015 (UTC)Reply[reply]
Comment - I opened http://pagebanner.wmflabs.org/wiki/Culver_City in an iPhone 6 emulator and the banner image is still the 2100px image. Is that expected? I thought part of the functionality was to have smaller banners downloaded on smaller screens? For reference the banner image source that I saw was the following:
Otherwise what I saw in my limited testing looks good. -- Ryan • (talk) • 05:38, 18 July 2015 (UTC)Reply[reply]
Thanks for reporting this! What browser version do you use? In particular, we will have to check whether it supports srcset. For browsers without srcset we just send the default (big) image, a choice which is actually up for discussion. Syced (talk) 10:22, 20 July 2015 (UTC)Reply[reply]
I saw the issue using the most current version of Chrome after using the developer tools to change my user agent to iPhone 6. I use this method for testing different mobile browsers frequently at work. -- Ryan • (talk) • 14:27, 20 July 2015 (UTC)Reply[reply]
You can track progress here and chime in with thoughts - https://phabricator.wikimedia.org/T106523. It's worth noting this is no worse or no better than the status quo (currently banners served via the template are hidden in mobile but still get downloaded). At least with the extension we have more options to work this out. Jdlrobson (talk) 18:29, 20 August 2015 (UTC)Reply[reply]
Well spot! I see that Sumit fixed that bug this morning, thanks for reporting! :-) Syced (talk) 10:24, 20 July 2015 (UTC)Reply[reply]
Support Andrewssi2 - The main thing is that the new template is not worse than the existing one. I would say start the paperwork, but WOSlinker 's bug should be addressed first. Fixing Ryan 's bug will give this a massive benefit over the existing template. Andrewssi2 (talk) 01:42, 19 July 2015 (UTC)Reply[reply]
Support, if the mentioned bugs can be fixed. Thanks for the hard work, Syced and others! JuliasTravels (talk) 09:13, 19 July 2015 (UTC)Reply[reply]
Support, thank you for the effort! Danapit (talk) 17:36, 19 July 2015 (UTC)Reply[reply]
Thanks for the huge support! WOSlinker's issue has been addressed at https://phabricator.wikimedia.org/T106321 and will soon be updated. The issue of a large banner raised by Ryan is a well identified one on browser versions which have poor support for srcset. If "srcset" is supported it loads a responsive image, otherwise goes for the largest banner image as a fallback. Ryan, can you comment, if possible on https://phabricator.wikimedia.org/T105203 with steps to reproduce the issue or something like a screenshot?--Sumit.iitp (talk) 10:18, 20 July 2015 (UTC)Reply[reply]
Is "srcset" supported on mobile devices? A low resolution banner on good desktop screens will make a bad impression, but a large banner on mobile devices will be a huge usability issue when bandwidth is low or costly. --LPfi (talk) 11:21, 20 July 2015 (UTC)Reply[reply]
Thank you everyone! The "paperwork" has now started, with the Mediawiki Admin team performing a security review which will probably take around two weeks. That will leave us around a week before Sumit's GSoC ends, which is quite short, so everyone is still encouraged to play with http://pagebanner.wmflabs.org/wiki/ and report any bug. Cheers! Syced (talk) 05:28, 22 July 2015 (UTC)Reply[reply]
52 suggested new alternative banners - please participate in the following discussions and help decide whether some existing banners would be replaced or not[edit]
Over the last years I have created 52 new alternative Wikivoyage banners (mostly based on existing photos in Wikicommons) to be used, first and foremost, in the articles of the Hebrew Wikivoyage.
I am hoping that the English Wikivoyage community would consider using some of these alternative banners here as well.
Please participate in the following 52 discussions and indicate in each of the discussions which banner you prefer seeing at the top of this article.
I just cast my vote on all of them. Nice work ויקיג'אנקי! :-) Syced (talk) 08:16, 13 August 2015 (UTC)Reply[reply]
A crazy idea/suggestion which might actually help us substantially increase the amount of banners created on a regular basis - by having Wikivoyage Chat Room Banner Creation Parties![edit]
Each time I end up suggesting that the English Wikivoyage community would consider using some of the alternative banners I have created for the Hebrew Wikivoyage (this usually happens only once a year) I am also approached by some users whom tell me they think I should put a higher priority on creating banners for the 15,000 + articles without banners, instead of creating alternative banners to prominent articles with banners which I did not like visually.
For a long while I have been the sole active editor in the Hebrew edition of the Hebrew Wikivoyage, and therefore I tend to focus on many various important tasks, and not just on producing banners. Although there is a big demand for new banners I have also learned to accept that my abilities are limited - it takes me usually around 20 to 30 minutes minimum to create each new banner, and most of the time is usually spent on searching for good panoramic source images with commercial use + mods allowed license (necessary to create derivative works I can upload to Wikicommons) which I then edit in Photoshop, and upload to wikicommons (I actually prefer looking for source images first on Flickr as they have a wider selection than Commons, and because their search engine helps me find good pictures faster). I estimate that every year I end up making maximum only around 100-200 banners, and those are usually only banners which I thought would look well visually (I never produce banners which I do not like visually, just for the purpose of having one less article without a banner but with an ugly banner).
I feel that we have a significant problem - there are still A LOT of banners left to create, and there simply aren't enough people focusing their time on the creation of the 15,000 plus remaining banners. The few "experts" whom do create banners for Wikivoyage articles, can only create so many by themselves, and usually end up not devoting most of their time here to creation of banners as the banner creation process tends to be a long and somewhat exhausting process (just to illustrate the substantial amount of work that is left - if it takes around 30 minutes on average to create a decent banner from a good source image on flickr/commons * 15,000 banners = 7,500 hours of continuous work in total = 312.5 days of continuous work in total). In my opinion it is definitely doable, but we'll still need a lot more people involved in this process (even if you are not Photoshop experts) for us to be able to create most of the missing banners within the next few years.
Yesterday, after the user Andrewssi2 approached me about the need to focus on creating banners for the 15,000 plus articles with no banners at all, I had a crazy idea on how we might be more efficient in creating a more substantial amount of banners over time... by scheduling weekly or monthly Wikivoyage Chat Room Banner Creation Parties.
for this to work, we'll need to have a least 10-20 people taking part in this collaborative effort, coordinated through a chat room, at a specific day + time which works out for everybody involved. From all the participants, around 20-30 percent would have to be Photoshop experts.
Before each collaborative effort takes place, the group would compile a list of 100-200 prominent articles without banners and that list would be the main focus of the group during the actual scheduled collaborative effort. During each scheduled collaborative effort, all the participants whom ARE NOT Photoshop experts, would mainly be focused on searching flickr and commons for good panoramic source photos to create decent banners from - when someone finds a good panoramic source photo, they would send the link to one of the Photoshop experts, whom would be fully devoted to using those photos to create the banners + uploading their work to commons (and making sure to fill in all the necessary text of each banner file license). I believe that if we'll have enough people whom are willing to work together in this way, we'll be able to substantially increase the amount of banners created on a regular basis, and get closer much sooner to creating all of the missing 15,000 plus banners.
I like the idea, but I fear that this will soon fizzle out like most attempts at organized collaborations have in the past...Hobbitschuster (talk) 17:02, 12 August 2015 (UTC)Reply[reply]
It will not "fizzle out" if enough people would sign up for it and make an effort to take part in it. ויקיג'אנקי (talk) 17:19, 12 August 2015 (UTC)Reply[reply]
Would be cool, I hope enough people can participate :-) How can we attract people to join this effort, for instance people who don't hang out here? Syced (talk) 17:21, 12 August 2015 (UTC)Reply[reply]
I am no Photoshop expert and have never made a banner, just FYI. Of course that doesn't prevent me from discussing the merits of banners as compositions, but that's another matter. Ikan Kekek (talk) 23:00, 12 August 2015 (UTC)Reply[reply]
I'm a bit concerned about all this talk of 'photoshop experts'. I wouldn't describe myself as one, but I know enough to produce banners that are at least to the required specification.
The reality is all you need is Microsoft Paint to create a perfectly good banner. I personally use Gimp because it is free and more powerful. We should stop talking about expert technical skills to perform what is a straightforward task. --Andrewssi2 (talk) 23:43, 12 August 2015 (UTC)Reply[reply]
I admit to sometimes going on banner binges, but they come at whims, especially when I feel like Wikivoyaging but cannot get myself down to contribute actual content. And I am OK with working on my own, though input is obviously always appreciated. That said, I think we're pretty well covered when it comes to banners. I'd rather the community effort went towards e.g. upcoming featured articles which often could do with a brush-up, as well as popular destinations who have been slightly neglected for some time. Another great effort would be to help brush up neglected regions of countries like Germany, which was actually underway until the initial enthusiasm gave way to vacations :D PrinceGloria (talk) 19:42, 12 August 2015 (UTC)Reply[reply]
Maybe we should call a general moratorium for new community initiatives during the Northern Hemisphere summer? :-P Hobbitschuster (talk) 19:47, 12 August 2015 (UTC)Reply[reply]
While making banners is my passion here at WV and I possess skills necessary for their editing, plus I enjoy collaborating with others, I cannot promis I will be available for any kind of scheduled event. I don't know if it is at all possible to organize such a party accross time zones. Anyway, I often escape for contributing on WV just for a couple of minutes when I should be doing other things anyway, so scheduling won't work for me. Danapit (talk) 20:19, 12 August 2015 (UTC)Reply[reply]
I also see time zone difficulties, and although I have made a few banners for "random" places, most have been for places that I know a little about (I have been to the same country etc.), and I find it is most fun to create a banner using my own photos (but I do mainly use ones from commons). AlasdairW (talk) 22:06, 12 August 2015 (UTC)Reply[reply]
ויקיג'אנקי - I admire your enthusiasm, but honestly I think you're overthinking this whole banner thing.
The culture of this community has evolved in such a way that the development of English Wikivoyage tends to be slow, gradual, and somewhat piecemeal. I've spoken before about how, with a few exceptions, Expeditions almost invariably die as soon as they're hatched, and the same is going to be true of things like "Chat Room Banner Creation Parties", the banner suggestion lists from a little while ago, etc. For whatever reason, big, splashy initiatives turn us off. Maybe because we're a wiki that's small but has an extraordinarily dedicated group of regular editors, and we'd rather feel satisfied watching the progress we each make individually on whatever we happen to be working on, than feel pessimistic about the future of our site by watching yet another big complicated effort go belly-up due to lack of interest.
You're one of our most prolific banner creators, ויקיג'אנקי, which is a good thing. But here's a few words of friendly advice. Whoever told you it's more important to create new banners for destinations that don't have any yet is absolutely right, but more to the point, it doesn't have to be as long and tedious a process as you seem to think it does. If you want to make a new banner for a destination that doesn't already have one, just put it on the article. 99.9% of the time, the community will be more inclined to be grateful for your contribution than to nitpick over whether there might be a nicer banner image out there somewhere. Meanwhile, if you want to make a new banner for a destination that does already have its own banner, just post a message on the article's talk page saying so and linking to the new image. Most of the time no one will care either way, so if you don't get a response within a few days go ahead and put up the new banner; if you do get a response, then you can start worrying about building consensus and feeling out community opinion and all that jazz. And if you make a whole slew of new banners all in a row and you want to hear what the community thinks about them, go ahead and write about in in the Pub and you're likely to get a short burst of feedback, but please disabuse yourself of the idea that it's going to spark a long-lasting interest in banner-making among the community. In general, whether it's by you or someone else, the banners will get made when they get made.
I'm pretty much where Danapit is here :) I can't schedule anything.
I would also say that the absence of 15,000 banners (or better stated, 66% of English Wikivoyage articles) isn't a major issue as such. My own approach to South Korea is to list all the pages without banners (URL currently down) and pick them off by order of page size. I'm not in a hurry and will hopefully finish off the country this year, but it is more important to choose a banner with care than just crank out as many as I possibly can.
In terms of the banner creation party.. well I would say if you want to try it then more power to you! Even just two people working in tandem would be quite productive. AndreCarrotflower is however right to caution the level of enthusiasm for initiatives such as this. Andrewssi2 (talk) 23:09, 12 August 2015 (UTC)Reply[reply]
Also in terms of the delimitation of responsibilities, you may find many pictures are chosen which don't work. For example I sometimes find a great picture that I think should make a good banner, but after the 7:1 magic treatment doesn't look very good at all. --Andrewssi2 (talk) 04:44, 13 August 2015 (UTC)Reply[reply]
Without a joint effort to create a big portion of the missing 15,000 banners, we have no chance of getting those created before the 2010s are over (in this pace, it they might not be created before the 2020s are over either). I need more volunteers to make this happen. Even if you don't know anything about Photoshop, please join this effort! ויקיג'אנקי (talk) 23:20, 12 August 2015 (UTC)Reply[reply]
I'm happy to be involved in the creation of banner, but sadly, like many of the above, can't really commit to a particular time. Please do continue with your own great work on this - we will get there! --Nicktalk 22:17, 13 September 2015 (UTC)Reply[reply]
Users interested in participating in a such an effort[edit]
Are there any users whom would be willing to take part in such an effort? if so, please indicate that in the list below:
For a while it has been bugging me that the Hebrew Wikivoyage articles have panoramic photo of specific cities/sites in the banners of continents or large regions (for example, there was a banner of Jerusalem in the top of the Middle East article). Because of this, yesterday I replaced all the continents banners (+ the banner of the Middle East article) of the Hebrew Wikivoyage with the following banners:
I am currently considering creating more banners like these for other large regions.
Would the English Wikivoyage community consider using these alternative banners here as well ? ויקיג'אנקי (talk) 19:53, 12 August 2015 (UTC)Reply[reply]
I agree that a panorama of a specific city is not ideal, but unfortunately the new banners look too similar to our regional default banners. I like the banners that we have for Europe and Oceania, which show more of a typical detail for the continent. AlasdairW (talk) 20:46, 12 August 2015 (UTC)Reply[reply]
Banners are supposed to be beautiful and interesting. A satellite image will never be anything but dull. Sorry, I think this is a nonstarter. -- AndreCarrotflower (talk) 21:48, 12 August 2015 (UTC)Reply[reply]
Interesting idea, but can't say the result of the satellite images looks compelling. Andrewssi2 (talk) 22:55, 12 August 2015 (UTC)Reply[reply]
Any ideas on how to make it look more compelling yet not have a photo of a specific site ? maybe making each of those banners have a collage of various photos that are highly representative of each region ? Any other ideas ? ויקיג'אנקי (talk) 23:24, 12 August 2015 (UTC)Reply[reply]
