Wikivoyage

Wikivoyage:Roadmap

A long way to go

Ever since our move to Wikimedia Foundation servers, the many contributors of Wikivoyage have brainstormed, discussed and proposed various ideas and features to improve our site. The roadmap was created as a way of organising and keeping track of the various ideas, and centralising new feature discussions in one place. Please plunge forward and contribute your opinions or ideas of your own to discussions.

See Wikivoyage:Requests for comment for links to discussion of some related issues. m:Wikivoyage/Wishlist for cross-Wikivoyage bugs and requests.

Short-term goals edit

Fix listings templates/tags edit

Improve articles on key destinations edit

These major destinations are often the first thing many readers see. They need to be complete, readable, and well-linked to our other articles.

  • Continent articles really need to have all the sections filled out with meaningful content ASAP. Currently, some are fairly weak.
  • Articles on large and diverse countries such as China, India, the USA or Brazil also need work. These are difficult to do well; it is hard to find the right balance, to be reasonably complete without creating something long and unreadable, and hard to decide which cities and attractions go in the main article rather than in regional articles.
  • We have a list at Wikivoyage:World cities/Large of the world's largest cities and busiest tourist destinations. Many of those could stand improvement.

Improve article quality edit

Quality control edit

Enhance patrolling edit

Improve main page edit

See Talk:Main Page New. We need to focus on improving our mobile gateway, our main-page display for non-wide screens, and our interlingual portal (which is really bland).

What should the key functions of the main page be?


What are the basic design principles for achieving those key functions?


Comparison with other sites: critical notes


Develop Tourist Office edit

See Wikivoyage talk:Tourist Office

Fix breadcrumbs edit

  • Enable (i.e., customize) support for multiple parents in breadcrumb navigation. E.g., it should be possible to assign Russia two parents: Asia and Europe, then allowing destinations further down in the hierarchy to pick one of those parents for its breadcrumb trail. So Vladivostok would use Asia/Russia, while Saint Petersburg would use Europe/Russia.

Enhance interproject links edit

Add all sister projects to our list of RelatedSites edit

Do people agree this should be a priority?


What would be entailed technically?

This may be affected by Wikidata too. --Rschen7754 07:44, 28 July 2013 (UTC)[reply]

This will probably be easiest to do before Wikidata takes over management of our related sites, just to have everything in order before they run the bots. The ones we really need are Wikiversity and Wikibooks for our phrasebook links, and Wikinews to link their categories from a fairly wide variety of our destination guides. Other project links will usually make more sense in-line (like Wikisource links in "Read" sections), so those aren't a concern. But I figured it simplest to just enable them all? --Peter Talk 21:12, 29 July 2013 (UTC)[reply]

Enable multiple links to one sister project in sidebar edit

Long-term goals edit

Enable listings reviews edit

  • Add up-vote/down-vote button to listings, possibly limited to a user group?
  • Add a "reviewed" button to listings, for trusted users to confirm that details are up-to-date on individual listings, perhaps with a hover text showing the date?
  • Basically resurrect "Extra," which would be the more interactive "back-end" of our travel guide content. Listings would have a review button, which would allow readers to jump to a review page for the listing, and add their own reviews.

Generated user maps edit

We should come up with an organic way for users to generate their own travel maps (very rough example—not what the proposed would look like).

  • Add an "I've been here!" button to the top of articles.
  • Create a map generator that adds POIs to an OSM map to show all the locations for which a user has clicked that button.
  • Side benefit: link in the sidebar to a list of users who have clicked the button for any given page, so editors can find people who have been there, and can ask them questions.
  • Discussion here.

Tours of Wikivoyage edit

Allowing new users who are unfamiliar with Wikivoyage to take a tour of the site and understand what it's all about:

  • Introduce new users and help them understand the project's goals and mission
  • Attract new users from other WMF sites
  • Help users discover many features which go unnoticed or underused
  • Make the site more user-friendly and fun for readers

Strengthen crossover links with other-language WV sites edit

What can be shared for mutual benefit?
Which language-WV sites are the low-hanging fruit?

Visual Editor edit

Do we want to encourage sooner rather than later adoption?

Don't decide until you have used it yourself for enough edits to be sure of your opinion. Not just for trivial edits either, and take a look at the feedback page. It is a long way from bug-free (early beta at best). Some like it, others loathe it. • • • Peter (Southwood) (talk): 06:52, 28 July 2013 (UTC)[reply]
For me it has bugs which are currently unacceptable. I can't do most of what I want to do on it, due to poor support of wikitext, the mouse-over "edit source" links are terribly annoying and cause me to select the wrong editor far too often, it is terribly slow, and opting out/temporary disable should be an easily visible option. At the very least we should require that the [edit|edit source] links must be permanently visible. It has great potential, but I don't think it is ready yet, and the developers will not tweak it to suit the local community. If you get it, you get it as it is, without the option of turning it off. • • • Peter (Southwood) (talk): 06:52, 28 July 2013 (UTC)[reply]
For the record, Wikipedia gets the first priority, since other sites need customization for this to work - but structurally Wikivoyage is quite similar to Wikipedia, so it may be considered first like it was for Wikidata. --Rschen7754 07:43, 28 July 2013 (UTC)[reply]
Are regular WV editors likely to be irritated by the dual edit buttons (which a surprising number of en.WPians seem to be—strange to me)? It appears to me that casual editing travellers would like VE for the basic edits they make. Does VE work well on mobile devices, and do you know what proportion of WV edits are made from mobile devices? Tony (talk) 08:02, 28 July 2013 (UTC)[reply]
The VE can be disabled, so as long as the disable link is prominent enough, I don't see an issue with a sooner rollout. The things that were described I wouldn't call bugs; more like "annoyances". But I think new users will be happy to put up with annoyances if they get a much more intuitive and simple UX. Also, how would the VE deal with our numerous templated listings? I know the add template interface is fairly straight forward (but tedious), so it could even act similar to a listings editor in some respects. James A ▪ talk 10:56, 28 July 2013 (UTC)[reply]
James (and others): do we have a "most techie" editor as a regular on WV? It would be nice to know whether there's someone who could advise and liaise with WMF etc. Tony (talk) 11:12, 28 July 2013 (UTC)[reply]
I think the main advantage of enabling VE would actually just be to draw the eyes of WMF technical wizards to our site, hopefully getting them interested in developing other features for our site. But our listings form editor really does most of the work for us on this front. Editing plain prose in, say, Understand sections is quite easy, and we use far, far less complicated markup in our articles than in template heavy Wikipedia articles. --Peter Talk 21:00, 29 July 2013 (UTC)[reply]

Related grants edit

See also edit

Grants and coding programs

Retrieved from "https://en.wikivoyage.org/w/index.php?title=Wikivoyage:Roadmap&oldid=2511808"