Wikivoyage

Wikivoyage talk:External links/Links in listings/Archive

< Wikivoyage talk:External links | Links in listings
Learn more about this page

How should links be shown:

  • to someone reading the printout I made when I clicked on "printable version" ? (should we even show links at all ?)
  • to someone browsing the web ?

Currently they look very different for "embedded external links".

Some people propose changing the software to make them look even more different. Others would prefer both to look as similar as possible.

edit

The current style guidelines indicate that external links to bullet-listed attractions (hotels, restaurants) should be placed as bare URLs (automatically turned to links by Wiki) at the very end of the list item. While this standard is not explicitly stated, it is used in all the examples : Project:Attraction_listings

I propose that external links instead be embedded in the attraction name.

That is,

instead of



An embedded link is the very essence of an HTML web page. It says "Click ME to see more about me. You don't have to go to a footnote at the bottom of the page, or type in a URL in a separate window. Just click ME and I will take you there."

A Wiki bare URL link, besides creating redundant HTML, breaks this fundamental property of hypertext. It needlessly displays an ugly string. Furthermore, placing it at the end, separate from the actual name of the attraction, is bad user interface design (if you can call a hypertext link an interface). It's almost as bad as (if not worse than?) the dreaded 

"click <a href="http://www.wikivoyage.org">here</a> for a cool on-line travel guide."

So, why are bare URLs used in attraction listings? I suspect the main reason is for printed articles. (I am a big advocate of supporting Wikivoyage in print form.) By including the bare URL, it's available to users who only have the printed article. But in fact, the Printable Version of a Wikivoyage article automatically expands embedded external URLs. So there's really no need to include bare links for print compatibility.

I think another reason for bare links is influence from printed travel guides. It's common for them to include them, and when I see an attraction listing with a URL, I instinctively think, "Hey, that's great, it includes the web site." But there is no need for it. Printed documents include bare URLs only because they are print documents.

Embedded links make for better-looking and more functional web pages, as well as fully usable printed documents. I think we should use them. --(WT-en) Paul Richter 11:51, 24 Jun 2004 (EDT)

So, here are my main reasons for wanting to keep URLs bare and separate.
First, I agree that keeping the print version clear is important. However, I also think that with a printed guide, having the URL right after the name is not that useful. In fact, the URL is of very low importance for a printed guide -- it's much less important than the address, phone number, or review. That's why it's at the end of the listing, not the beginning.
Second, I like emphasizing the print aspect of Wikivoyage guides. Getting people out of the idea of making a Web site and into the idea of making a travel guide is a good thing, IMHO. Concessions to the "webbiness" of Wikivoyage aren't, for me, a high priority. I'd rather our guides looked like print guides displayed on the Web than vice versa.
Thirdly, I think the listings just look better with a bold heading rather than a link. It's aesthetic, I know, but they seem more pleasing to the eye that way. (That may have something to do with my exasperation seeing a whole page of front-linked attraction listings: "Great! There's a half-hour off my life, reformatting those listings!" B-))
Lastly, and kind of selfishly, I think that separating URLs from labels discourages Wiki spam. Google Page Rank is closely linked (ha ha) with the text of the anchor tag. If we keep URLs separated from labels, we're not really a good leg-up for Wiki spammers. It's a gentle way of saying, "we want your information, but we're not here to boost your Google ranking."
Now, to controvert myself: it's a pain changing listings from front-linked to end-linked. I hate it. Maybe since people instinctually want to put links on the names, we should just do it. It might be time to just quit fighting this. --(WT-en) Evan 13:48, 24 Jun 2004 (EDT)
I have mixed feelings on this issue. When I started contributing, I at first preferred and used the 'bare and separate' approach, because it seemed to me that it clearly differentiated between internal links (which are invariably embedded) and external links. However as I continued, I somewhat changed my mind, for the following reasons:
  • The use of 'bare links' was in any case inconsistent. In more general text (as opposed to bulleted attraction/restaurant/hotel/etc entries) embedded links were already the norm.
  • Putting the 'bare link' at the end of the attraction/etc entry divorced it from the rest of the address information (street address, telephone, etc) which is where it naturally seems to belong, and which the mos says should come immediately after the name. In the printable view, the URL for an embedded link on the names is directly next to the other addressing info.
  • In some case I found I was putting secondary links as embedded links in the text of the attraction, with the primary link as a bare link at the end. These seemed perverse, and gave more prominence to the secondary info over the primary.
  • Some of the URLs I was putting in as bare links were very long and ugly, and embedding them hid that, at least in the non-printable view. For example:
http://www.english-heritage.org.uk/default.asp?wci=mainframe&URL1=default.asp%3FWCI%3DNode%26WCE%3D107
I now almost invariably use embedded external links. I don't think this is perfect answer, but on balance I feel more comfortable with it than the bare link approach. -- (WT-en) Chris j wood 14:46, 5 Jul 2004 (EDT)
I think having to put out the full URL for links is a good thing. If it looks bad on the Web, it's going to look bad on the printed page.
Having now spent some time looking at the output of the printable version, I agree. I think that if an organisation cannot be bothered to provide decent URLs for deep links, we should honour their (deliberate or unthought) desire not to have such links. To put the example above into context, I think that if I was now writing that attraction entry, instead of saying:
  • Wolvesey Castle, tel 854766. This palace was the chief residence of the Bishops of Winchester and its extensive ruins still reflect their importance and wealth. Open Apr-Sep 10am-5pm. Free.
I would instead say something like:
  • Wolvesey Castle, tel 854766. Now owned by English Heritage, this palace was the chief residence of the Bishops of Winchester and its extensive ruins still reflect their importance and wealth. Open Apr-Sep 10am-5pm. Free.
and let the reader wade through their website until they found Wolvesey Castle. But if anything, that amplifies the basic issue. If I'm only to use bare links appended to the attraction entry, how do I concisely express the fact that this is a bare link for the whole of English Heritage, and not a direct link for their Wolvesey Castle property. -- (WT-en) Chris j wood 20:01, 5 Jul 2004 (EDT)
Another thing I was thinking about was the issue of parallelism. Not every attraction has an accompanying URL (startling, I know). So if we decide to do this, we'd have listings that looked like this:
  • Attraction 2, Description text.
  • Attraction 3, Description text.
I don't think that looks good.
Lastly: would someone like to summarize the pros and cons of front-linked listings on this page? --(WT-en) Evan 19:06, 5 Jul 2004 (EDT)
Bit too tired to try that right now. I'll give it a go in the morning. -- (WT-en) Chris j wood 20:01, 5 Jul 2004 (EDT)


Ok, here goes (as the following section) -- (WT-en) Chris j wood 08:47, 6 Jul 2004 (EDT)

Front-linked Listings Or Bare-linked Listings

edit

Definitions

edit

A front-linked list entry is a bulleted list entry for an attraction, restaurant, bar, hotel or similar where the name of the attraction/etc (which the mos already says is the first element of the entry) is an embedded external link. An example would be:

  • Somewhere Interesting, Some Street, tel 999999. This is a really exciting place to visit. Open Su 1am-2am. $100.

A bare-linked list entry is a similar entry, where the url is instead appended to the entry, thus:

An un-linked entry is a similar entry, without an external link to the attraction/etc, thus:

  • Somewhere Interesting, Some Street, tel 999999. This is a really exciting place to visit. Open Su 1am-2am. $100.

In any given list there are always likely to be un-linked entries, because the attraction/etc doesn't have a web site or we don't know its url. The question is whether, where we do know a url, we should use the front-linked format or the bare-linked format. The mos mandates the bare-linked format, but front-linked entries happen quite a bit.

Complicating this question is the fact that any of the above three formats may contain secondary links within the description to urls that are related to, but not directly about, the attraction/etc. By more or less universal practice these are always written as embedded links. For the purposes of this discussion, I call these secondary-linked. Examples would be:


  • Somewhere Interesting, Some Street, tel 999999. This place, run by the Somewhere Company, is a really exciting place to visit. Open Su 1am-2am. $100.

Pros Of Front-linked Listings

edit
  • Front-linked listings are more concise in the normal view, and not significantly less concise in the printable view.
  • Use of front-linked listings means that we consistently render external links in the same way, as use of embedded links is almost universal in other parts of the wikivoyage content (ie. both secondary links in list entries as defined above, and links outside lists such as in 'understand' sections.
  • In the printable view, use of front-linked listings means that all 'address' type information for an attraction/etc is adjacent. (With bare-linked listing the street address and phone comes at the beginning of the entry; the url at the end).
  • Use of front-linked listings correctly expresses the order of precedence between the primary link (first) and any secondary links (following); bare-linked listings reverse this order.
  • Use of front-linked listings is good web practice. As Paul Richter says above An embedded link is the very essence of an HTML web page. It says "Click ME to see more about me. You don't have to go to a footnote at the bottom of the page, or type in a URL in a separate window. Just click ME and I will take you there.".
  • Contributors seem to intuitively want to do front-linked listings. So, having this be our style guideline for listings means a lot less work switching around the links.

Pros of Bare-linked Listings

edit
  • Bare-linked listings result in closer similarity between the normal and printable views, which makes editing for both formats easier and more reliable. (BUT it only does this for list entries; we probably need to address all the other places embedded external links are used).
  • An mixture of bare-linked and un-linked entries in a single list is more aesthetically pleasing than a mixture of front-linked and un-linked entries, because the names of all entries are identically decorated.
  • Bare-linked listings help to strongly differentiate between external links and internal links, which are always embedded. (BUT this only works for list entries; we probably need to address all the other places embedded external links are used).
  • Bare-linked listings do less for the targets google ranking, and hence using them will discourage people spamming wikivoyage in order to benefit their ranking. (BUT this only works for list entries; we probably need to address all the other places embedded external links are used).

Opinion

edit

I have tried to be as impartial as I can in the above. So here are my opinions having had to think about this.

I firstly don't rate the anti-google-ranking-spam argument for bare-linked listings at all. If a link is genuinely useful to our readers, then I rejoice in the fact that we are helping that site's google ranking. If it isn't, then the link shouldn't be there in the first place and we don't appear to be short of editors prepared to police this.

I think all the other arguments are good ones, but at the end of the day I personally feel that the pro-front-linking ones outweigh the pro-bare-linking ones. -- (WT-en) Chris j wood 08:47, 6 Jul 2004 (EDT)

That sounds great. Thanks a lot for doing this. I'd like to get some more attention on this page. One thing I changed: bare-linked URLs are mandated by the MoS at this point: see Project:restaurant listings, Project:attraction listings, Project:accommodation listings, Project:bar listings. --(WT-en) Evan 10:46, 6 Jul 2004 (EDT)
OK! -- (WT-en) Paul Richter 04:49, 7 Jul 2004 (EDT)

I don't like the new "front linked URLs". I'm afraid that for me the arguments in favor of keeping it the way it is now outweigh the arguments in favor of making the change. Besides I don't think it's worth the hassle. -- (WT-en) Mark 17:16, 8 Jul 2004 (EDT)

I prefer the current Bare Linked form. Google rank-spamming is a serious issue that we already face. Front linking will make it worse. Also, I think it looks terrible to have a mix of both linked and unlinked stuff in the list (for those items which have no extlink) -- though perhaps this could be mitigated with a change to the style. -- (WT-en) Colin 18:12, 8 Jul 2004 (EDT)

Surely anyone inserting a link into Wikivoyage purely for the purpose of google-rank-spamming is going to go ahead and insert an embedded link anyway. I don't think spammers take much notice of manuals of style, so I don't see how changing the mos is going to make any difference to the amount of spam we see. -- (WT-en) Chris j wood 16:06, 9 Jul 2004 (EDT)
If the MoS requires barelinks and someone inserts an embedded link, it's a clue you're dealing with either an inexperienced user or a link spammer. In either case, that's a clue that the link should be investigated to make sure it is appropriate. I, for one, don't want to follow every link added by a user I don't recognized to check appropriateness. It's a small point perhaps, but for me it's worth mentioning. For others, no doubt it's not so influential. -- (WT-en) Colin 18:21, 9 Jul 2004 (EDT)

My preference is for the Front-linked and hidden URLs - the arguments summarised above for them are fairly compelling on the whole. Yes, it may involve some work.... but who's frightened of a bit of gradual change divided between all active contributors? Another reason for including front-linked hidden URLs is that many URLs are extraordinarily long and complex, detracting from the sense of the written word..... (WT-en) Pjamescowie 12:37, 9 Jul 2004 (EDT)

Another thought, contra a supposed advantage of bare-linked URLs: "Bare-linked listings help to strongly differentiate between external links and internal links, which are always embedded". Couldn't the Wikivoyage stylesheet be easily amended to distinguish between internal and external links, should the option to use hidden front-linked URL's be adopted? A colour distinction (blue = external, green = internal, for example) would, I think, prove too "busy" visually. Internal links, however, could be given an additional "hover" background attribute, so that when a user's pointer is over the link, the link "glows" a light blue colour behind it. The links on my website provide a good example of this in action: http://www.ancientneareast.net/ External links would simply display as blue lettering and underlining. (This is just one suggestion, of course - others may have other ways of signifying the distinction....) (WT-en) Pjamescowie 12:47, 9 Jul 2004 (EDT)

My thoughts on this are that the current bare linked is best approach. I think having hidden URL linking is a good idea for deep linking onto a specific relevant page, but that it shouldn't be done in the title. I think that having the title look different depending on whether it has a website or not is not a good idea. I think some of the other problems can be addressed other ways. For example to deal with long url's to the attraction page I would suggest something like the following:

In my opinion this looks a lot better than hidden url's in the title.

I disagree completely -- this is verbose, redundant, and butt-ugly to boot. The point of a link is to link somewhere relevant, not tell you the name of the server, and isn't it already obvious that you'll get "more information" if you click on it? (WT-en) Jpatokal 00:51, 23 Jul 2004 (EDT)

I also think that with the way that the printed form of wiki works having expanded (and sometimes very ugly) URL's right after the attraction name is a very undesirable appearance. I actually would like to be able to turn off the printing goes expanded version. In my example above I would turn off expansion for the more information link as nobody would type in the long version, but would navigate from the companies front page. -- (WT-en) Webgeer 00:19, Jul 23, 2004 (EDT)

In this case the printed version should be changed to append the link to the end of the paragraph, which is just a matter of some Perl magic. (WT-en) Jpatokal 00:51, 23 Jul 2004 (EDT)
Or maybe even in the HTML-generating code with a user preference: external links in lists embedded or at the end of the paragraph.
Of course this is a slippery slope to the kind of software which is too flexible/wishy-washy to set any user interface policies and ends up letting the user configure everything. But the more I think about it, the better it sounds... -- (WT-en) Paul Richter 21:54, 5 Aug 2004 (EDT)

Change management

edit

So, one last point about front-linked URLs: it's a change from the existing style. We'd have to go through all 2000 articles (!) and make sure they have the new front-linked style. Admittedly, a lot of them do already, but it is going to be a not-insignificant amount of work. Tedious, mind-numbing work. Then again, it's easier to do now than when we have 10,000 or 100,000.

One possibility is writing a script to do it, but that'd be kinda tricky.

This should probably factor into a decision. Is having front-linked listings worth the effort? --(WT-en) Evan 15:35, 8 Jul 2004 (EDT)

It could also be a gradual process of converting to the new style. Yeah, it'd be a bit sucky at first though. -- (WT-en) Colin 15:50, 8 Jul 2004 (EDT)
Yeah, I'd guess it'd take a couple of months. --(WT-en) Evan 16:00, 8 Jul 2004 (EDT)

Where Are We With This?

edit

Just noticed that (WT-en) Hypatia has gone through the Sydney/Darling Harbour article and changed See/Sleep/Eat/Drink list entries from embedded links to raw links. Which is fine if that is the way the consensus has gone; something I would be hard put to call either way from this discussion.

But, the same article still has embedded links in 'Get In' and 'External Links' sections. If we are going to go for raw links for all external links; fine. But allowing them in some sections but not in others seems positively perverse.

Opinions -- (WT-en) Chris j wood 20:51, 5 Aug 2004 (EDT)

First, the end links is still the manual of style guideline (per the listings format pages). So it makes sense to change articles to fit the guidelines right now.
Second, the way that links work in regular paragraph text is different from how it works in listings. I think it's consistent. Listings are more structured than regular text. --(WT-en) Evan 00:29, 6 Aug 2004 (EDT)
I actually did that before I was aware of this discussion, and if I had been I might have left it. However, when I started Sydney/Darling Harbour I used end links, and one of the later authors changed all the listings to front links. A conclusion to this discussion would be nice, since this "formatting war" where links are changed to front links and are changed back to end links is unproductive. (WT-en) Hypatia 05:48, 6 Aug 2004 (EDT)

My thoughts on this... perhaps the code can be changed so that external links display a small icon to the right of the text so that it is clearly external. Like this:

  • Somewhere Interesting[[Image:External link 1.png]] 123 Fake St. (Springfield), 456-7890. This is a really exciting place to visit. Open Su 1am-2am. $100.

Then on mouseover the link can be highlighted or whatever. This is similar to what Wikipedia does. This could be a good compromise... thoughts? -(WT-en) Nickpest 16:25, 7 Aug 2004 (EDT)

This has been an interesting discussion to read through. As someone who recently started contributing, and have only read parts of the MoS, I have been instinctively using front-end links. I had a few thoughts on the discussion up to now.
  1. I don't much care to see entire links, long or short, as a I think they're ugly.
  2. Having used the London guide to some extent on my recent trip, I also don't see much use for URLs in the printed version, as if I'm in a position to visit a website, I'll have access to the hyperlinked article, and if I'm visiting more than one, it's easier to load it up on wikivoyage and then follow the links instead of typing each one in off a printed page.
  3. As a new contributor, I'd have to say reading the entire MoS before starting (especially since it's easy to get distracted by side pages), is unlikely. I mostly started by grabbing page templates and working off what I saw on other pages. Thus, as long as there's a fairly common inconsistency, I'm more likely to use what comes naturally. (Which would be front-end links).
Nickpest's last suggestion seems the best to me, as it preserves the front-end simplicity, but doesn't provide the inconsistent formatting (which I don't much mind anyway). -(WT-en) Neil C 18:36, 7 Aug 2004 (EDT)
So, these are great comments. Here are my main responses: first, although I don't like the way front-linked listings look, I find the idea that people "instinctually" make front-linked listings is a convincing argument. I'm really sick of having to change them -- it's really tedious.
I also don't expect people to read the MoS entirely. MoS style is a goal to aim for rather than a set of rules you have to learn before making a single contribution. If you add something that's not MoS, that's great -- we want all the info we can get -- but it's likely that someone else will bring it more in compliance.
We use the MoS to resolve conflicts on more or less arbitrary problems (formatting, layout, naming, etc.) and provide consistency. We don't have to argue on each and every guide what the layout, formatting, and content is supposed to look like -- we just defer to the MoS. Most of the stuff in there is pretty arbitrary and more about form than content.
Anyways, that's my main feedback. My final feeling: I'd like to change to front-linked listings, even though I dislike it aesthetically, if we can overcome objections. --(WT-en) Evan 14:31, 8 Aug 2004 (EDT)
I, too, dislike the front-linked listings for aesthetic reasons, but I think my suggestion somewhat overcomes that if it can be implemented. I, for one, never had a problem with having a bare link at the end of a listing; in fact I like it because it gives a "printed travel guide" feel.. but I totally understand people's objections to it. -(WT-en) Nickpest 15:00, 8 Aug 2004 (EDT)
I like Nickpest's suggestion for external links using the Wikipedia type graphic. I think this would be a nice solution that maintains the distinctiveness of Wikivoyage articles vs. external links and keeps nice consistent formatting. (These are my two objections to the inline formatting). -- (WT-en) Webgeer 13:01, Aug 9, 2004 (EDT)

So is this settled now? -- (WT-en) Beland 02:38, 16 Aug 2004 (EDT)

I'll cast another vote in favor. Now the only thing missing is the implementation...! (WT-en) Jpatokal 04:48, 16 Aug 2004 (EDT)
I think there are a few hold-outs. Personally, I hate making these kind of tedious changes on really minor, arbitrary formatting issues, and I just don't think it's worth the effort. But, yes, the Mediawiki 1.3 external link format makes for a much nicer presentation -- good job, Nickpest! --(WT-en) Evan 16:08, 16 Aug 2004 (EDT)

I'll change my opinion to neutral on this issue... (thus removing me from the dissenting opinions) -- (WT-en) Colin 15:54, 16 Aug 2004 (EDT)

Vote Opinion Summary So Far

edit

I decided to do a vote summary so I could make heads or tails of the discussion. The opinions expressed were rather complicated, though, and I'm not sure I did it right. Please check below to see if you are accurately classified, or if you want to change your vote. -- (WT-en) Beland 18:27, 18 Aug 2004 (EDT)

  • Hidden
    • Paul Richter, Chris j wood, Pjamescowie, Beland, Elgaard
  • Hidden, with icons for external links
    • Nickpest, Neil C, Webgeer, Jpatokal
  • Hidden if objections can be overcome
    • Evan
  • Bare, before proposal to have icons for external links
    • Mark
  • Explicitly neutral
    • Colin
  • Unknown
    • Hypatia
I thought we weren't going to vote on things on Wikivoyage.
That said, although I still like the listings with the link at the end the old way I would be perfectly happy with the Mediawiki 1.3 icon format. -- (WT-en) Mark 01:58, 19 Aug 2004 (EDT)
Yes, we don't normally vote on things on Wikivoyage. Perhaps "Opinion summary" would be a better term here, so I've subbed it in for the title. Otherwise, it looks like we're moving towards consensus here.
I'll put some information about the 1.3 upgrade somewhere soon. It's going to be something of a pain, but I'd like to do it before we start any new language versions. --(WT-en) Evan 17:06, 19 Aug 2004 (EDT)
So it seems we now have consensus for hidden links, pending the 1.3 upgrade. Should this be written into the official policy now? Should we start writing things in the new style in the meantime? -- (WT-en) Beland 21:44, 23 Aug 2004 (EDT)
Yes, I'll go ahead and change all the listing formats. There's tons of work to do in changing old articles. I really hope the people who've made a big deal about this are prepared to help out with the execution of the plan. --(WT-en) Evan 15:37, 24 Aug 2004 (EDT)
So, I changed all the listing formats, and y'know what? I think the printable version with front-linked listings looks really awful. (See here for an example). I feel pretty foolish not to have actually checked that before. Am I alone on this? I'm still reluctantly in support of this, but I'm really holding my nose on this one. --(WT-en) Evan 16:01, 24 Aug 2004 (EDT)
I agree, but there's not much that can be done besides reverting back to the bare listing format or hacking the Wiki code to automagically detect a linked listing and move its URL to the end of the paragraph .. doable, but not necessarily a trivial task. -(WT-en) nick 18:44, 24 Aug 2004 (EDT)


A real page like Østerbro is even worse. But I think the front-link way should be easyer to hack. Can we get get rid of the magnifying glass in printable versions. And get the pictures bigger than thumbnails since they can not be enlarged. The links still get underlined when I print with firefox. Konqueror does it right. -- (WT-en) elgaard 21:13, 2004 Aug 24 (EDT)
I guess I wasn't clear about my opinion. I really hate linking out the header of these listings without the little icon thing. With the icon thing I find it sort of tolerable. Can we ditch the front-linked stuff and just go back to the old way? -- (WT-en) Mark 03:55, 26 Aug 2004 (EDT)
If you're going to hack code to de-uglify the print version so that front-links look nicer (such as moving the URLs to the end), then remember that in-line embedded links will be affected as well. So a non-bulleted paragraph with three embedded links will have three URLs scrunched at the end, and no visual connection between them and the links in the paragraph... yuck.
Frankly, the print version is ugly in its entirety, and that can't be helped. But front-links make the on-line version cleaner and more usable, IMO. -- (WT-en) Paul Richter 04:52, 26 Aug 2004 (EDT)
It should be possible to match bulletet links so only those are moved to the end. But the more I look at both ways the more I would like an option to just not have URL's in the printed version. I would never type an URL into a browser anyway, I would just go to wikivoyage.org, search for the right page and have all the clickable links on one page. -- (WT-en) elgaard 06:31, 2004 Aug 26 (EDT)
I can't handle it looking this way. Writing off the printed version is not an option for Wikivoyage (see our goals for why). Nobody seems to like the printed version with an URL in the middle, and the only ideas for how to make it better is to hack the Mediawiki code to put the link... at the end! Where we have it on most listings already!
I have read the Goals and non-goals and I do not see why there have to be URL's on paper.
Wouldn't it be possible to run printed version trough something like:

perl -pe 's#^\*\s*\[(http://\S*)\s(.+)$#\*\[\2 \(\1\)#g;' -- (WT-en) elgaard 19:48, 2004 Aug 26 (EDT)

I'm reverting the changes to the listings formats. I just don't think this is tenable. --(WT-en) Evan 13:34, 26 Aug 2004 (EDT)
Right on! -- (WT-en) Mark 13:50, 26 Aug 2004 (EDT)
Loud objection! I see no consensus at all for this, just you & Mark. End links look horrible online, and the problems with the printed version are fixable with Perl hacking. As Elgaard says, why don't we just drop URLs entirely from printed listings? (WT-en) Jpatokal 21:53, 26 Aug 2004 (EDT)
Sorry Jpatokal, but I don't think we really had a consensus for changing it in the first place. That said I think that we can get there, like I said I won't resist the links with the icon.
I will on the other hand resist the idea of not having URLs at all in the print verion. Basically that's us putting a limit on what we can publish which our competition, like say Lonely Planet do not have. They can publish URLs in their print version, so why shouldn't we ? Imagine this scenerio: You're in a new city and you you have a print version of the guide. You have found an internet cafe, and you want to look up the site of one of our listings. Why should our policy make you have to come to the Wikivoyage site first? Heck, the Wikivoyage site might be down. -- (WT-en) Mark 07:42, 27 Aug 2004 (EDT)
After all this debate and a decision, the guideline is going to be reverted simply based on how it looks in the printed version? I think that's kind of weak. Yes, you should have checked that before. Please see my comments (Content vs. Presentation, More on Printing) below. -- (WT-en) Paul Richter 05:17, 27 Aug 2004 (EDT)
Yep, I shoulda checked it. After bringing it up, there was pretty much unanimous agreement that it was really, really ugly in the printable version. The work really hadn't started to get things changed over to the front-linked format, so I figured it was safe to change back to the end-linked version. --(WT-en) Evan 14:18, 27 Aug 2004 (EDT)
edit

These places may need to be updated once this question is resolved: Project:restaurant listings, [[Project:attraction listings]], Project:accommodation listings, [[Project:bar listings]].

There has been a proposal to improve handing of URLs in printed versions (by moving them to the end of the paragraph or page).

Seeking Consensus

edit

So, Mark, does the proposal for denoting external links with icons change your mind? What about the claim that people usually intuitively make hidden front-links? It need not be a hassle to change styles for anyone who doesn't want to help. If we prefer a quick rather than gradual transition, someone (maybe me) could write a script to find all bare links on wikivoyage, and for listings, suggest a fix. (I'd prefer a human look over the suggestions before implementing them, but that's still orders of magnitude faster than fixing everything manually.) -- (WT-en) Beland 18:27, 18 Aug 2004 (EDT)

Content vs. presentation, and the end-linking hack

edit

Placement of the URL with or apart from the text is a presentation issue. If it's so important that URLs in print don't look ugly, maybe there ought to be code to pull out an embedded URL and stick it on the end (on-line and print), and a user preference to do that. As a structure issue, though, it is eminently better to keep them together. Having them separate just doesn't make sense. Yet in separating them end-linking sacrifices structure for presentation, and as far as I can see, that's all it does.

As elgard writes in a previous thread, the front-link format should be easier to hack, i.e., the user option would be to a) pull apart embedded links or b) do nothing. So if a front-link/end-link user option were implemented, it will be up to front-linkers to do the work changing the pages. Viewers with the end-link option on should notice no difference.

I took a look at Wikipedia to see what their guidelines are. It turns out end-linking isn't addressed because it's never done anyway. Bare URLs are used only for single-line External links, and even then it's preferred to make them embedded instead of bare. And the idea of having a keyword with a link separate from it is, rightly, not even considered. -- (WT-en) Paul Richter 04:56, 27 Aug 2004 (EDT)

Hi Paul, I don't think I agree that non-embedded URLs in listings are so bad from a structural point-of-view. After all the phone numbers aren't embedded, nor the descriptions, so why should the URLs be? Just 'cause you can do that in HTML (and hence Wiki markup)?
This would be structural markup:

    <listing type="attraction" url="www.attraction.com" 
        description="this is a great place to go
        phone_number="+5 55 555 5555"
    >Cool attraction</listing>

    or maybe:

    [http://www.attraction.com|Cool Attraction|+5 55 555 5555|this is a great place to go|attraction]

    or better yet (the least markup, thus the most Wiki):

    *Cool Attraction, +5 55 555 5555. This is a great place to go!  http://www.attraction.com
Our consistent listing format is a stuctural markup if it is applied consitently, but one which can handle a lot more information that just a URL. I think we're just used to thinking of the URL as part of a tag, but that is HTML thinking, not Wiki thinking.
The templates are perfectly capable of recognizing a URL, or a phone number for that matter, so why not let them do the work? -- (WT-en) Mark 07:42, 27 Aug 2004 (EDT)
Meanwhile I do use embedded URLs all the time, just not in the listings. -- (WT-en) Mark 07:50, 27 Aug 2004 (EDT)
Phone numbers are not embedded because usually you cannot dial a number by clicking it (although I could make my softphone do just that). And URL's are often long and ugly, whereas phone numbers are short strings of mainly digits.
Email-adresses can often be clicked in browsers, but now always and not on SMS->gateways, some terminals in cafes and airports etc, so it makes sense to have email adresses bare. Actually i would like them as mailto: links as well. -- (WT-en) elgaard 2004 Aug 27 (EDT)
It's important to realize that Wikipedia has different norms, in that they downplay the importance of printed versions ("Wiki is not paper"). So comparing Wikivoyage guidelines to Wikipedia ones isn't always a fair comparison. --(WT-en) Evan 14:54, 27 Aug 2004 (EDT)

More on Printable Versions

edit

There's no need to configure Wikivoyage to move the URLs to any particular location; embedded links should appear as normal (no need for any "external link" icon, though; that just clutters things up). When someone actually goes to print the Printable Version, their web browser will handle links in an appropriate fashion. I believe that most web browsers will show URLs as numbered footnotes. At least in text-only browsers like lynx, you can disable the printing of these footnotes.

Not outputting the usual "a href=" style of URL risks disassociating the URL from the text to which it refers, especially for links embedded inside paragraphs (as opposed to links in listings, where it's a little more clear...unless there are multiple links in the same listing, which is quite possible if special directions or feature are noted). -- (WT-en) Beland 18:27, 18 Aug 2004 (EDT)


Regarding the role of a printed Wikivoyage, I think it's important to differentiate between a) making a printout of the on-line Wikivoyage, and b) publishing a printed travel guide based on Wikivoyage content. (In the Project:Goals and non-goals article, a) is "individual article printouts" and b) is "ad-hoc travel guides" and "inclusion in other travel books".)

The first, I think, is not very important, certainly its appearance. Web pages are designed to be viewed with a browser, not printed, and as long as the Print Version is still HTML rather than PDF, it will always be ugly, clumsy, and inadequate.

The second role is the one that we need to keep from being too web-centric -- e.g., being a link directory, reliance on multimedia. The important thing is to have the same content available in print and on-line, not that it be presented or formatted for print. Anyone who decides to publish a printed travel guide based on Wikivoyage has the freedom to move/replace/include links (and anything else) in any manner they want, so let's just supply the content in the most usefully structured form and let the print publisher present it in the best way for print media. -- (WT-en) Paul Richter 05:10, 27 Aug 2004 (EDT)

I agree. There are all kinds of ways www and especially now-web versions will be produced from the Wiki markup that is typed in. For example I would probably not use the printable version. I would use User:(WT-en) Mark/Wix to download a country and generate latex with parsewiki (once wix becomes recursive).
Therefore it is important that we have wiki-text that makes it easy to generate different versions, even versions we are not considering now. Separating URL's from text makes it harder.
I am not too worried that the printable version looks ugly as long as it can be made pretty without editing the content of WikiTravel. I would make it pretty by just removing URL's, but I do not argue that others should have to do that.

-- (WT-en) elgaard 10:16, 2004 Aug 27 (EDT)

One-off printouts from the browser are always going to be important for Wikivoyage. I realize they're not important to everyone, but they are part of our essential goals. I think that our printable versions actually look pretty good. --(WT-en) Evan 14:28, 27 Aug 2004 (EDT)
It's important for me too. I would use it for shorter trips, for a longer holidays I think wix would be easier.

The printout does look very good, depends a bit on the browser but html2ps is perfect for this. I still think magnifying glasses is pointless on paper. I just think it should be possible to make every version look good, we do not have to make one version look less good to make another verison look better -- (WT-en) elgaard 21:16, 2004 Aug 27 (EDT)

edit

Crazy, crazy idea: What if all wikivoyage articles were "no external links allowed" ? After all, you can't click on them after they're printed out.

Then "the style of external links" becomes irrelevant.

(I'm not talking about *deleting* links. Some of them are very helpful. I'm talking about *moving* them to a more appropriate place: the "Talk:" page, or the Wikipedia sister page.)

We might apply this ban only to articles discussing actual physical locations; the Travel_topics section would be exempt. http://en.wikivoyage.org/wiki/article/Wikivoyage_talk:External_links/What_to_link_to#Proposal:_No_external_links_allowed

Yeah, let's ban phone numbers and physical addresses while we're at it. For that matter let's not allow anybody to talk about any place of business. It's not like we have very many hotel listings now anyhow, so we won't have to delete much.
This should make it much easier to finish any given destination page. We could just have a script do it. -- (WT-en) Mark 17:06, 28 Aug 2004 (EDT)

Front vs back-linked listings, part XVII

edit

I remain entirely unsatisfied with the current state of affairs. Here's how I see it. In the Web listing, which is the way most people see Wikivoyage...

In the printed listing...

  • you have verbose computery gobbledegook spewed onto the page no matter which way you choose.

So the front-linked listings are obviously better. Mark and Evan, can you convince me otherwise? And please note that the Project:External links page currently doesn't say which is better, so I shall religiously revert any changes to the status quo until this is sorted out once and for all. (WT-en) Jpatokal 09:59, 1 Sep 2004 (EDT)

It's in the Project:Manual of style, which at the moment says to use bare urls. As far as I can tell a link is no more gobbledegook than a telephone number is. They go at the end because they can get kindof long, but a really long URL probably indicates that the page it points to doesn't really belong to the entity being listed, meaning that it probably shouldn't be there at all. Project:External links is about what to link to, not how to do the links from listings.
So it sort of bothers me that we have a DOM which does not follow the MOS. Maybe we should pick a different one until we get this worked out? Or maybe we should just make it match the MOS until we get this worked out? Either way. -- (WT-en) Mark 23:26, 1 Sep 2004 (EDT)
In my opinion there are 3 problems with front linked listings type of listing.
  1. Offsite vs. Onsite. Wikivoyage generally uses the front-link listing apearance for more wikivoyage pages. (Cities, Areas, are always done like this, attractions which have a whole page about them have also been done like this) Therefore, when one navigates around wikivoyage, one would expect the link to go to a wikivoyage page about the attraction. Instead we are sending people off-site.
  2. Inconsistent appearance. Making attractions with websites linked appear in a different colour/formatting from attractions without website links to me looks very hodge-podge.
  3. Printing. To me this is the least of the concerns. But having the gobbldegook appear at the end of the listing is better than right after the title where it looks out of place.
As mentioned before, my preferred solution is to use an icon. With the below option either replacing the [1] with an icon or even just leaving it. If #3 above can be sorted out with programming I like the look of the first option shown below. Otherwise I think the second option is the best way to go
  • Attraction 123 any road, 555-555-5555, [[Image:External link 1.png]]. Best to keep the link right with the other contact information, but have it display very different from on-site links. Does not change the overall appearance of the list, puts it with the contact information where one would expect information directing you to the site. The use of an icon in the online version (with the url in the print version) is the best solution. However, if it is too much to hack wiki I think the simple numbering system [1] is ok too.
  • Attraction 2 Alternatively, if we can't address the printing issue and we don't want to have the webpage in the middle of the listing. Put the link and the end, but have it either be a numbered link or use an icon. [2]
We will have to wait until Evan gets back to discuss how doable this is, but personally I think this is the best option. -- (WT-en) Webgeer 12:22, Sep 1, 2004 (EDT)
Yes, I think you've pretty much nailed the reasons why front linked listings are bad. I like the icon solution too, and the numbers look reasonably good too, but maybe there's another possibility:
  • Attraction 2, 55 Avenue A. +5 555 5555. [Website] Alternatively, if we can't address the printing issue and we don't want to have the webpage in the middle of the listing. Put the link and the end, but have it either be a numbered link or use an icon.
-- (WT-en) Mark 23:39, 1 Sep 2004 (EDT)


The way WikiPedia does it is: An externel link in wikicode looks like: 

 * [http://www.example.com/ Attraction] foo bar

The HTML looks like: 

 <li><a href='http://www.example.com/' class='external' title="http://www.example.com/">Attraction</a> <span class='
 urlexpansion'>(<i>http://www.example.com/</i>)</span>foo bar</li>

If we don't like the underlining we can use a different stylesheet. If we also do it this way, we can use frontlinking and discuss style-sheets and transformations for print versions. -- (WT-en) elgaard 17:48, 2004 Sep 1 (EDT)

If we're going to go this route, let's make external links open up in a separate window so you're still on the Wikivoyage site. Or maybe have that as a user preference. -(WT-en) nick 03:24, 6 Sep 2004 (EDT)

This discussion page is getting quite confusing, so I'm not sure whether I'm putting this in the right plave, but here goes nothing....
Where are we in terms of achieving consensus re the style of external listings? Yesterday I made some link additions to the Paris/1st_arrondissement and these were speedily converted into number links by Mark. Mark also informed me on my talk page that this basically reflected the new consensus for external links..... Now, I can find no real evidence of any such consensus emerging in discussion on this page.... I can find some minor discussion re the suggestion of a number or icon display of ex links, but no evidence of anyone other than Mark and maybe one or two others jumping on this particular bandwagon. (Just for the record, if we do go down this road, let me state that I prefer an arrow icon à la Wikipedia for external links - the numbers just look confusing and get lost in the text.....).
I had thought that hidden, front-linked listings were achieving more of a consensus, both in discussion (see above) and in practical application..... Any thoughts on this? Where do we stand? (WT-en) Pjamescowie 06:46, 13 Sep 2004 (EDT)
My comments above are not designed, by the way, to take away from the sterling work that Mark has been doing on the Paris pages..... (WT-en) Pjamescowie 06:49, 13 Sep 2004 (EDT)
Thanks, Pjames. The reason that I think we'll wind up with the numbers links (which will turn into arrows when we upgrade the software) is that some people here object very strongly to bare URLs at the end of listings, while others of us (Evan and myself for instance) object very strongly to front-linked listings on astetic and typesetting grounds. As well as others.
The idea of putting the link in at with the rest of the contact information seems to have illicited no objections, and has the additional advantage of being very logical, since it neither relegates the link to the back, nor gives it preference over the other contact details up front.
Since we're talking about a consensus, in which we all more or less agree then the idea with no objections would seem to me to carry the day. The ideas with strong objections (like front-linked listings) are not likely at all to achieve a consensus. -- (WT-en) Mark 07:29, 13 Sep 2004 (EDT)
Thanks for that Mark - I hadn't worked out from the discussion that the numbers will convert to arrows once the software is upgraded.... So it will look like Wikipedia? Great! I'm with you on this one then.... It appears to be an effective, visually-appealing compromise, avoiding objections from both sides.... I'll use this approach from now on and endeavour to revise previous contributions. Any idea yet as to when the software will be upgraded? (WT-en) Pjamescowie 07:37, 13 Sep 2004 (EDT)
I have to admit that I'm assuming that that's what will happen. If not I'll write a script which will make it happen.
As for when the upgrade will happen, that'll be Evan's move. -- (WT-en) Mark 07:41, 13 Sep 2004 (EDT)
  • Could we at least put the number/arrow right after what is itemized, not after phone numbers, emails etc. Otherwise it will be harder later figuring out where the link belongs. Also it takes longer to eg go through a list of hotels and find the ones with web-pages.
  • Why is the number on the printed version (in addition to the bare URL)?

I don't have a big problem with the visual expression of the web or printed version. But I still think it is ugly and unnecessary to write it directly in the wikitext. -- (WT-en) elgaard 09:38, 2004 Sep 14 (EDT)

I'm not really sure I understand what you are saying in the last sentence there. Can you clarify? -- (WT-en) Mark 11:05, 14 Sep 2004 (EDT)
Look at a front linked page: Østerbro, then look at http://www.agol.dk/elgaard/Osterbro.html. Apart from pictures missing and a font-problem, I only changed two lines of CSS. Now if you add an arrow whereever you want I am happy.
I want the the wiki-code (the text you see in edit mode) to be tidy and keep as much information as possible because this is the source of web-pages, printouts, and all other formats. Making the transformations from wiki to web, print, etc should not be too difficult. And even if we do not get it right the first time, we can always improve the transformations without editing every single wikivoyage page. -- (WT-en) elgaard 18:05, 2004 Sep 14 (EDT)

Order of contact info

edit

You might notice that the contact info is in order of importance to the traveler on the ground.

  • Name, address, other location info. phone, fax, email. [URL]. description

One of the problems I have with the front-linked listings is that they put the URL before any other information in the wikitext. To my eye that looks absolutely hideous. It makes more sense to me to put it in with the contact info, especially if we are going to be hiding it in brackets (under a number or later a nice little graphic). -- (WT-en) Mark 11:11, 14 Sep 2004 (EDT)

It only make some sense if you insist that the printed versions and www versions should look the same.
When reading wikivoyage online an URL is a lot more important than say the fax number.
This is also true for the traveler on the ground. When I travel I could use my cheap GSM-phone to browse wikivoyage and external
links, although it would be expensive. I usually also have access to the net from the hotel, public terminals or internet cafes.
But I have never used a fax machine while traveling. -- (WT-en) elgaard 18:18, 2004 Sep 14 (EDT)
I respectfully dissagree. I think that for most travellers a URL is not terribly useful at all. Perhaps Denmark is more advanced (I think it probably is) but in most of Europe hotel reservations which are supposedly handled over the web must still be confirmed with a phone call, and often by faxing a copy of one's credit card. I've had to do this a couple of times.
That's why I think that for all of the beauty and simplicity of URLs and browsers on palmtops that the URL is still in our day last on the list of importance in contact information for travellers.
Anyhow, I guess I've realized that another objection that I have to front-linked listings is that in the raw wikitext the URL is the very first thing. I think the name should go first. Actually I think that's really important.
If you insist, I am very willing to compromise by agreeing to put the link right after the name of the place and before the other contact information but I really do not want the name of the listing itself linked because that has the effect of putting the link first before the name in the wikitext, and in bold to boot.
I guess for me it's important that the wikitext source itself also look good and be easy to use. I guess I'm also looking at the listings as being a sort of a unit, including the URL, so I don't really see why the URL should need any specific markup since its really easy to recognize a URL with regex, and that the Mediawiki software already does that. I'm also thinking in terms of offline editing because I very often edit pages in Vim], rather than in the browser window. At any rate I really think it's important to preserve a visual hierarchy of some sort within a given listing.
At any rate, I'd really like to come to a consensus on this, and I'd like as well to underscore that I have a great deal of respect for the work you've done for Wikivoyage, as well as for your skill as a graphic-designer as demonstrated by your excellent map of Copenhagen. -- (WT-en) Mark 11:54, 15 Sep 2004 (EDT)
I guess the importance of URL's is subjective. I have never used a fax to book hotels (except for documentation to get a visa to Russia). I have used the www to book hotels in Greece, Belgium, USA, Finland, Russia, and France. And I have used the www to choose hotels in many more countries. I just like to see a web-page before I choose a hotel unless I can just walk by.
You can recognize a URL with a regexp. But what is it a URL for? I guess that if we have a policy that there can be at most one bare URL (= [ http: //example.com] URL that become number/arrow) in each entry and that it is an URL for the first bold text, there is no loss of information.
OK, I won't object to this. Of course someday there might come a wikimedia version that let us write external links with the URL's last and can generate all kinds of HTML formatting and I will suggest that that we run a perl-script to "clean up" the raw wiki-text :-)
I am happy that you like my work, but I cannot take credit for the train-maps in Copenhagen
They are the maps used by danish public transportation I got them from Jørn Damsgaard, who was very helpful. I just exported them from GIMP. But I can recommend everybody to just ask your local traffic organizations for permission to use this kind of material on WikiTravel.
I think it is best that kind of request comes from locals in the native language. But maybe we could make a template. I.e. making sure the CC-sa license is mentioned.
The Copenhagen/Østerbro map required more work than skill. It is based on autotrace on a PD map from one of the sites mentioned in the map expedition page. It seems there are advantages of living close to the US embassy.
-- (WT-en) elgaard 17:41, 2004 Sep 15 (EDT)
Add topic
Retrieved from "https://en.wikivoyage.org/w/index.php?title=Wikivoyage_talk:External_links/Links_in_listings/Archive&oldid=2421710"
Return to the project page "External links/Links in listings/Archive".