MaxTravelz talk:Listings

From MaxTravelz

Contents

Templates for listings

Moved from MaxTravelz talk:Using Mediawiki templates by Evan


So, I think one of the great lessons of ja: is that it's easy for users to contribute listings using templates, and that the output can look quite fantastic. I'd like to see if we can start moving to using templates for listings on en: and other languages.

I realize that moving entirely to templates for listing would be a huge amount of effort, but I think we can make it work, and I think the payoff could be humongous. I think it will make it easier to have structured listings, and I think it will make it possible to store tags and other metadata about listings and use that data to enhance search ("Where are there Chinese restaurants in or near Marseille which cost around €15 per meal?"). We could start putting GPS coordinates in for individual listings rather than cities as a whole, and use that data for making maps or for coordinating with geo-aware Web sites like http://www.semapedia.org/ .

And, also, I think we can help new users input listings information. I think the following is as easy or easier to figure out and use than our current formatting. 

 {{resto|name=Ouzeri|address=4690 Rue St. Denis|directions=one block north of Avenue Mont Royal
        |phone=845-1336|web=http://example.org/|hours=Tu-Th 5PM-1AM, F-Sa 12PM-2AM
        |price=$25-$35|extra=prix fixe on Fr and Sa
        |desc=Fine Greek dining, great selection of ouzos and Greek wines. Stylish and modern.
              Try the flambé cheese hors d'oeuvre -- it's dramatic.
        |geo=45.5253,-73.5857
        |tags=greek,modern,wine,ouzo,popular,mid-range,plateau}}

(The last two entries would be invisibly rendered as RDF.) We could also look into enhancing our interface with e.g. the Inputbox extension to make adding a new listing (or editing one...?) easier. We'd also need to have parameter defaults working so that incomplete listings like: 

 {{resto|name=Ouzeri|address=4690 Rue St. Denis|phone=845-1336}}

...do the right thing. Another benefit of using structured data is that we can start using bots more often for things like geocoding addresses or fixing common formatting mistakes.

The big problem here is not technical but social and organizational. Can and should we do this? Is it worth the effort to get structured listings? Bots and other automation may be able to handle some percentage of the existing listings (...30%? 60%?), but there will be a lot of gruntwork -- I think our experience with removing External links sections, or adding isIn data, is probablly representative.

Of course, if we want to do this, it's not going to get easier later.

I'd like to start talking about this and maybe work up some sample templates that render, more or less, to our current formatting. Comments? Questions? Ideas? --Evan 10:58, 4 March 2006 (EST)

Hell yeah, I've been agitating for this for a long time (you can blame me for doing it in ja: in the first place!) and would be behind this all the way. However, I still think that it's too much to ask for users to be able to edit the raw templates, so enabling/extending Inputbox or equivalent is essential. And sure, there's gruntwork, but there's already a lot of continual gruntwork just in whipping entries into MoS shape and templating would do away with this once and for all. Jpatokal 11:08, 4 March 2006 (EST)e
I think this is a super-great idea! I think we've proven with the +isin -ext links our ability to do site-wide cheanges (heck, I think it's a great way to get people working on pages they otherwise never would have seen). Anyway, I think structured data is going to open up a lot of neat stuff and is 100% the way to go. Majnoona 11:48, 4 March 2006 (EST)
What jpatokal said. We should make it structured without making articles ugly to look at or forbidding to edit. Someone visiting for the first time should be able to add or edit listings without the experience turning negative for him. I just had a look at ja: and I think they've got it right. --Ravikiran 11:31, 4 March 2006 (EST)
And while we are at it, I'd like to revive the idea of using a wizard while creating a new page - a simple one which asks if it is a smallcity, bigcity, region, itinerary, traveltopic etc. and simply inserts a template to edit. --Ravikiran 11:56, 4 March 2006 (EST)
I'd like to volunteer to convert Singapore (and for time being only Singapore) to use templates, and work out any bugs in the process. Any objections? Jpatokal 10:32, 2 April 2006 (EDT)
I wouldn't be opposed, but can any templates that are created be given names that are obvious English words? Someone seeing "resto" wouldn't necessarily know what that's for. Also, are separate templates going to be created for hotels, bars, restaurants and attractions, or is one template sufficient? -- Ryan 15:07, 2 April 2006 (EDT)
I think a lot of it is common, but what about doing Template:Eat for restaurant listings, Template:Drink for bars and clubs, Template:Sleep for hotels and Template:See and Template:Do for attractions? I think they're going to be a lot the same, if not identical.
On top of this -- I'd like to develop extended wiki markup for MaxTravelz listings so that a) listings can be rendered as hcard HTML and b) we can save out the listings on the back end into a database, which could then be searched/reviewed/updated/shared/etc. I think getting these templates started is key... at some point we'd just swap the custom tags into the template. I'll put up some examples at User:Evan/hcard examples. --Evan 15:39, 3 April 2006 (EDT)
Agreed with using the verbs for the template names, that's how it's done in ja: and it seems to work fine. I even experimented a little with doing a meta-template which is included into other templates to make the formatting consistent, but I don't think this level of complexity is necessary in the English version.
But Evan, are you saying I should plunge forward with just plain vanilla templates, and the hcard conversion can then be done at some point in the future? I don't really see the big difference between Wikimedia templates and hcard, both are structured forms of information that can be post-processed easily with nothing more than a string parser.
I do think the DB idea is key though: it would be really spiffy-keen to have a shared database accessible across all MaxTravelz versions, so (eg.) changing the telephone number in French version would automagically change the number in Japanese one too. Jpatokal 09:52, 4 April 2006 (EDT)
Yes, I think that's one big use; we might even make that database available separately.
So, I had hoped that we could do this: make templates that contained (vanilla) wiki markup, and then later replace the vanilla wiki markup with listings tags, so that Template:Eat would start off as * '''{{{name}}}''', {{{address}}}, ... but eventually change to * <hcard name="{{{name}}}" address="{{{address}}}" ... >. But custom tags don't work very well with template parameters, so I guess I'd ask either a) plunge forward and be prepared to pull back or b) don't plunge forward for a day or so. -- Evan
A day, as in a single 24-hour period? Egads! I think I can restrain myself that long... Jpatokal 12:54, 4 April 2006 (EDT)
Yep. I've already started work on the custom tags, and I'll get them rolled out on MaxTravelz.org by 1PM EDT tomorrow. We can experiment a bit to make sure they look right (I could probably use some CSS2 help on them...) and then start doing a run-ahead on Singapore and its districts. --Evan 13:51, 4 April 2006 (EDT)

Listings tags

So, there are now 5 custom tags to start experimenting with for listings. They are <eat>, <drink>, <sleep>, <see>, and <do>, and all of them have the following attributes:

  • name
  • address
  • directions
  • phone
  • email
  • fax
  • url
  • hours
  • price

None of these are mandatory technically (although things get screwy if you don't use a name). The contents of the tag become the description of the listed attraction. An example: 

* <sleep name="Auberge de la Fontaine" address="1301 rue Rachel est" phone="+1-800-597-0597" fax="+514-597-0496" url="http://www.aubergedelafontaine.com/" price="$100-$280">Fun B&B with 25 rooms. Located on the Plateau and across the street from Parc Lafontaine. </sleep>

This becomes:

  • Auberge de la Fontaine, 1301 rue Rachel est, ☎ +1-800-597-0597 (fax: +514-597-0496), http://www.aubergedelafontaine.com/. Fun B&B with 25 rooms. Located on the Plateau and across the street from Parc Lafontaine. $100-$280.


Note that I haven't yet integrated listings into the list format. I'm going to try to re-style these listings to look more like ja:'s listings, although I'm not sure we want to do that yet. Should we try to convert listings to use this structured format first, then change the look and feel? Or do it first as an incentive to change over? --Evan 13:24, 5 April 2006 (EDT)

P.S. Those of you who use tails will note that these listings are valid (if imperfect) hcard listings. --Evan 13:26, 5 April 2006 (EDT)
Incentive. I'd like to change the stuff and see that I really changed it. Although the editor would certainly have to change the entire set of listings in one swoop or it'll look awfully funny. Anyway, if we waited, we may wait forever. It would be like looking at a Christmas present wrapped under the tree. -- Ilkirk 15:05, 5 April 2006 (EDT)
Another question: I'm making the names of the tags (<eat>, <sleep> ..) and the names of the attributes (address, phone, ...) configurable in each language version. Any reason not to? --Evan 11:14, 6 April 2006 (EDT)

Yes, languge-configurability is good (ja: already has localized names). Trying these out in Singapore/Sentosa now, and some comments: Jpatokal 11:18, 6 April 2006 (EDT)

  • URLs should be automatically enclosed in [], so they show up correctly. Now you get the full path visible.
  • A single blank line after a listing turns into an excessive amount of blank space.
  • A <buy> tag would also be useful.
  • If the address is missing, the phone number is also swallowed:

<sleep name="Sijori Resort" tel="+65-6271-2002" url="http://www.sijoriresort.com.sg" price="S$120-">Blah blah</sleep>
→ Sijori Resort, http://www.sijoriresort.com.sg. Blah blah S$120-.


A couple of responses. First, it's actually kind of a pain in the keester to tap into that link-numbering mechanism, so I skipped it for now and I'll try to get back to it later. It's not merely a matter of wrapping things in [] since the processing goes tag → HTML, not tag → Wikitext → HTML. I'll see if I can figure out a way to do it.
I don't think the numbers are necessary or even desirable, they're pointless and rather weird. IMHO just "web" and the arrow would be much better! Jpatokal 13:00, 6 April 2006 (EDT)
Not sure I understand about the blank line but I'll look into it. MediaWiki doesn't handle custom tags very well if the contents are split over more than one line (gar), so Don't Do That. I'll figure out if there's another way to do it soon.


Test!

First


Second

What I mean is that if you leave a blank line after any entry, then instead of ignoring the line (as currently) it turns it into about 2 blank lines' worth of space. See infobox to the right. (Or is it just Mozilla?) Jpatokal 13:00, 6 April 2006 (EDT)
The buy tag is a good idea.
The attribute is actually phone, not tel. viz.


This brings up a design question: should we have lots of synonyms for these attributes (phone: tel, voice, ph, telephone), which makes it easy for someone guessing to get it right, or should we have just one name for each, which makes it easier for third-party processors to keep up? I favor the latter. --Evan 12:11, 6 April 2006 (EDT)
Oops! One name each is enough -- as said, for a long-term solution there has to be a way to enter the templates with a friendly wizard, so people never have to guess at the names. Jpatokal 13:00, 6 April 2006 (EDT)

Any progress on fixing these issues? Singapore/Sentosa is now 100% listingfied, but the two bugs that still bug me are 1) the display of links as URLs instead of just "web" [arrow-icon], and 2) the extra white space if I leave empty lines after the listing. Jpatokal 13:26, 8 April 2006 (EDT)

I like just the word "web" (or "website"? or a localized version of same?) for the link. About the whitespace: ugh. I'm going to see what I can do about it; but MediaWiki seems to insist on sticking a "<br />" into pages for no good reason. The last thing I want to do is figure out a good way to render "geo" and "tags". Eventually I'd like to have a Special:Tag that has links to every page and listing that matches the tag (tagcloud, eh?), but I'm going to have to build that out. And I'm not sure how to make it look good (although I think hiding it in the print stylesheet will be good).
Even the word "web" seems superfluous to me; it carries no information. Online, all you need is the box-and-out-arrow graphic in click-me blue (no localization required). Offline, just "http://" is a dead give-away that you're looking at a Web URL. - Todd VerBeek 21:01, 23 April 2006 (EDT)
Here's what I'd like to do next: let's convert 2-3 other big pages and see if we run into anything that we can't handle with the listing format. Then, if we're OK with it, let's change the MoS (MaxTravelz:restaurant listings, ...) pages to use this format. --Evan 00:02, 9 April 2006 (EDT)
So, I'd be happy to convert all of Singapore, but I'd like to see the extlink formatting changes — I'm fine with either web-arrow or just plain arrow as suggested by Todd. The extra space after the entries is also a bit bothersome. Jpatokal 00:48, 24 April 2006 (EDT)
One more thing: can we add an optional "map" value that just prints out "Map X."? This could be used to point either to a map grid ("A5") or a listing number ("7"). Jpatokal 22:33, 24 April 2006 (EDT)

One additional request: it would be good if it was made policy that when using a tag to create a listing that ALL fields for that tag should be included, even if some are empty. This policy would be similar to the article template policies - we always include the "Sleep" heading, even if there is no content, to encourage people to fill out the section. Similarly, we should also make it policy to always include (for example) the "phone" field in a listing to encourage people to add that information if it is missing. Thus a listing might look like:

<sleep name="Test Listing" address="" phone="" fax="" url="" price="">Description.</sleep>

This is probably a minor point, but I think making it explicit policy that fields MUST always be included, even if blank, is important. Also note that if we make this policy it makes the question of whether or not to allow synonyms (phone/tel/etc) a non-issue since people won't need to guess at values. -- Ryan 22:18, 9 April 2006 (EDT)

Pictures in listings implemented on Japanese MaxTravelz

Just a little heads up: there's now some template magic on ja: to include pictures into the listings, and display a gray default image if undefined. Take a look at eg. Manila. Jpatokal 05:13, 14 April 2006 (EDT)

That's pretty cool. So, I'd like to do that with the tags, but just have nothing if there's no photo. --Evan 08:23, 14 April 2006 (EDT)
Now implemented! Jpatokal 07:09, 30 April 2006 (EDT)

List or not list?

One more thing I'd like to get sorted out: is it really necessary to place the '*' in front of every listing? I think it would be more flexible to enter just and then do the processing under the hood. ~~~~