From Wikitravel Shared

I just started this page and it would be nice to have some sort of structure up and running rather soon. I think it is vital that we keep the tech requests to the page where it is supposed to be, and use this page as some sort of guidance for IB to what we think they should prioritize. Riggwelter 10:13, 29 August 2007 (EDT)

I added a priority table and an idea of how it should be handled. The discussions regarding what should go where would be held on this talk page. Riggwelter 10:59, 29 August 2007 (EDT)

[edit] Discussions

[edit] Bug reports

I suggest that the first priority should be given to bug reports, such as the case with the MWI. Issue to be solved: how to prioritize the different bug reports? I suggest that the second priority should be given to technical requests. Again: how to prioritize? Riggwelter 10:59, 29 August 2007 (EDT)

I still consider that the handling of bug reports should be the #1 priority at all times. New features are always cool, and probably more fun to develop compared to the tedious business of faulting, but if what we have does not work, we will end up with fewer and fewer contributors. Riggwelter 04:36, 1 October 2007 (EDT)

[edit] Setting Priorities

I'm interested in getting feedback from the community on your sense of relative priority for some of the items I previously mentioned, including:

• completion of form-based listing editor
• mapping of items geo-coded in listings
• script to geo-code items in listings that don't have long/lat provided
• new page generation wizard
• WYSIWYG editing
• variety of widgets people can post on their sites and blogs, with links back to Wikitravel (favorite destination, my most recently edited article, most recently edited article on my watch list, etc.)

Do any of these stand out has having particular value in the near-term? Redondo 17:51, 31 August 2007 (EDT)

The geo-coding features sound interesting, but I don't know enough about what they are to make any judgments about their relative priority. But these features would only really have an impact on guides to the rich (i.e., wired) world, correct?

For me, the form-based listing editor should see real priority. Right now, the listings tags do not work in translation (at least in non-Roman alphabets anyway) and listings can regardless be intimidating for uninitiated contributors. If done right, a form-based listing editor could have tremendous benefits for Wikitravel. The majority of listings across Wikitravel are improperly formatted and very incomplete; my hope is that a more straightforward editing process would help put an end to these problems.

Widgets sound cool, but IMO should take a back seat in terms of priority to functionality issues (including bug reports).

I'm skeptical of the usefulness of both WYSIWYG editing and a new page generation wizard, because we already have features that offer these types of functionality. The preview button allows editors to see what the code they are typing will produce. We have straightforward pre-loadable article templates within the "new article text" page that facilitate page creation. Not that WYSIWYG editing and a new page generation wizard wouldn't be better, but given that we have existing features that accomplish the same goals with some degree of efficiency, I think these two features should also get less priority.

I'd like to also bring up one feature request that I think should be included among the highest priorities—automatic transfer of files from each language version to shared. There is no good reason for files to continue to be uploaded to individual language versions. At the same time, it is best that contributors be able to upload files using their own language versions, so that they don't have to create accounts on shared and so that they may read the "upload file" page in their native language. --Peter ^Talk 19:53, 31 August 2007 (EDT)

I pretty much agree with Peter on all those points. Regarding the images to shared thing, this is a conversation about it. Evan's comments about merging all the databases is particularly interesting as well. If all "upload file" links on the various versions pointed straight to shared, and you didn't have to have a separate login at shared, then I would truly be impressed. I made a feature request a while back as well. – cacahuate ^talk 04:25, 1 September 2007 (EDT)

I agree re. the importance of forms-based editing. Unclear if Evan might stay involved enough with Wikitravel development to take this over. If not, IB will take this on. To facilitate further discussion and community feedback, we'll provide some loose mock-ups of thoughts on both geo tools and some widget ideas in the next week or so. Yes, the idea of a single file repository on Shared seems worth further consideration, including the idea of people using their own language version for upload. Redondo 23:14, 4 September 2007 (EDT)

I think that form-based editing is the most important feature, followed by new page generation wizard and WYSIWYG editing (if that is possible). My sense is that the crucial difference between Wikitraval and Wikipedia is that Wikitravel will have a larger proportion of casual users and correspondingly a lower proportion of experienced users who will correct their mistakes, so anything that enables us to get value out of casual edits should be high priority. — Ravikiran r 01:06, 12 September 2007 (EDT)

The forms-based tool for entering listings is something that Evan was close to completing, so that seems like a good item to start with. Another item that I think should be high-priority (and apologies if this is discussed elsewhere) is beginning the discussion about how and where ads will go. That's probably going to be an ugly debate, and even though IB has said it's not a priority, it will have to happen eventually and it will be much better if the discussions about where & how have already occurred. -- Ryan 02:52, 12 September 2007 (EDT)

One more vote for the listings editor, it's absolutely critical. We'll see a big leap in the number of edits once it's ready, because it just lowers the barrier to entry so much.

We agree. We're working out whether Evan or IB will complete this, but we plan to make it a priority regardless. Redondo 19:49, 12 September 2007 (EDT)

As for ads, this discussion has in already started under the innocuous title of en:Wikitravel talk:Wikitravel Press#Links from Wikitravel. Chip in -- this is going to be reality real soon now. Jpatokal 07:25, 12 September 2007 (EDT)

I think it is worthwhile to have an ads policy on shared. I've created one at Advertising policy. --Peter ^Talk 14:18, 12 September 2007 (EDT)

Thanks for creating that, Peter. Redondo 19:48, 12 September 2007 (EDT)

I would like to take a stab at adding more detail to some of John's (Redondo's) product ideas listed above, and nominate these as possible next development projects. These projects seem to me like good candidates as the form-based listing editor nears completion. -- Ibkevin 13:26, 18 September 2007 (EDT)

I've taken the liberty of moving these into their own feature requests:

* Tech:ListingGeoData Script

* Tech:Listing map extension

* Tech:Wikitravel Research Widget

And finally created this one as well:

* Tech:Form-based editing of listings

Please continue discussion there. Jpatokal 23:58, 18 September 2007 (EDT)

I have questions to members from IB.

1. Are the new features above going to be deployed on English version Wikitravel only?
2. How are you going to handle Open bug reports and Open feature requests? How prioritize them including the new features above?
3. Do you think we've finished discussions about which issue has #1 priority before you respond to Riggwelter's suggestion above?

-- Tatata 01:10, 19 September 2007 (EDT)

1. I sincerely hope that you will not prioritise en: to any other Wikitravel version. Either you deploy new features across all versions, or not at all. A big brother - little brother approach to things is not very constructive.
2. I still consider that the handling of bug reports should be the #1 priority at all times. New features are always cool, and probably more fun to develop compared to the tedious business of faulting, but if what we have does not work, we will end up with fewer and fewer contributors. Riggwelter 04:36, 1 October 2007 (EDT)

My votes go for

• mapping of items geo-coded in listings
• script to geo-code items in listings that don't have long/lat provided

As I am visualist in reading listings, I believe that adding geo-coding and visualizing it would really make even non-star guides much more useful for travellers. Especially that having most up-to-date listings seem to be our key competitive edge, compared to the traditional guidebooks. --DenisYurkin 18:28, 18 January 2008 (EST)

Geocoding - It can be extravagantly data-intensive. However there is a range from static 2-D approaches up to dynamic 3-D approaches like Google Earth. There must be several orders of magnitude difference in data intensity. Probably there are workable ways to implement without assuming broadband connections.

Wikipedia's implementation of geocoding gives you a long menu of choices how you are going to view the geographic data, so it's very possible to let people choose what works best for their particular situation.

Personally, I believe geocoding is a huge paradigm shift in travel information and I would make it a top priority. We are only just beginning to understand its possibilities. Let's climb onto this learning curve instead of dragging our feet.

--LADave 21:16, 21 March 2009 (EDT)

[edit] Wikitravel Extra

I'm interesting in community feedback on the direction you'd like to see Wikitravel go with regard to Wikitravel Extra. It feels a bit "chicken-and-egg" in that Extra will be a good user experience once there is a lot of content and usage of it. But it is hard to get that usage going. It seems we can continue with the relatively unobtrusive links to Extra, or alternatively we could more actively encourage it's use on the site. How do people feel about this? Redondo 23:19, 4 September 2007 (EDT)

Though I don't know about the relatively unobtrusive links to Extra in detail, I think it will be nice that a link appear in the related pages box or the other sites box[1], or somewhere on left sidebar and the link point to a destination tag on Extra[2]. BTW, I heard that multilingual support would be added to Extra's UI later this summer[3]. Is it still ongoing? -- Tatata 01:49, 5 September 2007 (EDT)

I disagree with you that this is a chicken and egg situation. It is clear to me that in this case, traditional software development and strategic thinking should come first. Here on Wikitravel, we already had a great software that served some 70% of our needs, there was already a wiki model where much of the thinking had already been done by Jimbo Wales and others, and Evan was there to act as a catherd. Most importantly, the Wiki software is so self-organizing that an incredible number of things can be done without recourse to developers or a higher authority. None of these is true of Extra. Of course, it makes sense to involve users in the development effort. It makes sense that the development effort will involve increasingly closer links with Wikitravel content. But if you are thinking that the most important thing Extra lacks is content, I must beg to differ. — Ravikiran r 01:20, 12 September 2007 (EDT)

I agree with Ravikiran -- Extra really needs closer integration to Wikitravel and visa versa. Ideally, every listing on Wikitravel should individually link to a list of reviews/blog entries/whatever concerning that place on Extra, and (the hard part) also show whether there is any content there. Without this, nobody browsing the hotels in the en:Maldives will ever find my detailed review on Extra. Jpatokal 07:22, 12 September 2007 (EDT)

Based on the above, would people like to see more prominent linking from Wikitravel articles to corresponding Extra pages? Even when they aren't started, people could be taken to new pages similar to what happens with new Wikitravel articles. Other thoughts on this? Thanks! Redondo 19:36, 12 September 2007 (EDT)

I think the simplest way to implement this would just to use Extra's built-in "search" function, like this:

http://extra.wikitravel.org/search/node/{{PAGENAME}}+{{LISTINGNAME}}

So eg. clicking on the link for the sleep item "Casa del Caribe" in the node "en:San Juan" would link to [4], which pulls up all blog entries (and forum posts if there were any) that mention it. Jpatokal 02:45, 16 September 2007 (EDT)

[edit] Voting

I was going to go ahead and add my column to the table, but I think we should clear up the averaging scheme first. (Or start over, since only two people have voted.) Right now, if I add a new nomination and give it priority 1, the average is 1, since nobody else votes on it. I'd suggest giving 10 points to the top priority and so on down the line. Or perhaps using something like Bugzilla; a wiki isn't really built for bug tracking. -Jonboy 09:54, 26 March 2008 (EDT)

The bugzilla idea is interesting, although not something I'm familiar with. But I think your worry about the averages is misplaced. Provided that people do vote, if you add a new #1, others including me will come along and vote on that new row too. Given the, um, pace at which features do get implemented, I think we'll always have time to vote on features newly added to the nominations table. It sure would be nice, though, to have the averages calculate automatically... --Peter ^Talk 13:19, 26 March 2008 (EDT)

OK, that was an extreme example. As things stand, though, Jani refrained from voting Tech:ALL uploads go direct to shared; presumably it's no more than #4 for him. But it's listed as an "average" of #2, the same as if he had voted #4. The averaging is flawed -- items people fail to vote for will end up higher than those they vote for. I'd suggest getting rid of it and just letting anyone eyeball the list. --Jonboy 14:49, 26 March 2008 (EDT)

Fair enough. --Peter ^Talk 15:10, 26 March 2008 (EDT)

Why don't we start with a more simple format like Top bugs? It's definitely easier to fill in, not to mention to watch changes. --DenisYurkin 18:04, 26 March 2008 (EDT)

I was worried that the Top bugs format is too crude a measure of priorities—it does demonstrate when there's a big problem (and everyone rushes to add an X), but it doesn't really let IB know our order of preferences in setting priorities. If I just added an X for each of these feature requests, it would make it seem that I think Tech:IWBNI Links at the bottom of image showed all language links and Tech:Form-based editing of listings are equally important. But they're not—they both are quite important, but the form-based editor is a much bigger deal. --Peter ^Talk 18:17, 26 March 2008 (EDT)

I like GMail voting for features mechanism: [5]. All they do is collect the info: what features will make most users happier? And if you have one feature much more wanted than another, it's unlikely that you'll vote for all the features presented at once--instead, you'll likely select top3 or top5 that you really want--and once they're implemented, you'll vote for something else from there. It's really simple, and it works just fine, as far as I can judge from Google's competitor point of view. --DenisYurkin 18:30, 26 March 2008 (EDT)

[edit] Update

Hey guys, can IB update us on what's being done with bugs and feature requests at the moment? – cacahuate ^talk 13:27, 9 August 2008 (EDT)

Is that a no? Is our site, as a whole, pretty much on the back burner now? Got the ads in place, as desired, now just coastin? – cacahuate ^talk 20:21, 25 June 2009 (EDT)

[edit] Format

I'm going to overhaul the format of this page to make it more user friendly and easier to digest, more in the vein of Top bugs. Stop me if you don't like the new format. This will require that we get input afresh. --Peter ^Talk 17:29, 23 September 2009 (EDT)