Wikivoyage talk:External links/Links in listings

From Wikivoyage
Jump to navigation Jump to search

Moved from Project:External links by (WT-en) Evan

Old discussion: Project:External links/Links in listings/Archive

Another alternative[edit]

How about writing external links as

  • Climb up to Arthur's Seat (web), an extinct volcano. Wonderful view of Edinburgh.

It would be nice to be able to write this in markup as

and have the external URL automatically displayed as a footnote in the printed version. Presumably that would mean adding it to the external links section with a reference to it in the text where the markup appears such as [1]. Is that too complicated? It would presumably require a code change to Wiki. The reason I'd prefer not to have the text Arthur's Seat as the link text is that that should be reserved for links to Wikivoyage topics such as Edinburgh in the example. Wikivoyage links could use a different font in the printed version.

With this scheme the URLs would be accessible in both the Web and printed versions but we would avoid ugly URLs embedded in the text. We would also distinguish between Wikivoyage and offsite links, which seems worthwhile.

There is one problem I can see. Sentences of the form:

don't fit this format. They would have to be rephrased slightly as (eg)

  • Online visual traffic information is available (web)

A small image could be used instead of the word "web", if desired. (WT-en) Bobkemp 21:13, 1 Oct 2004 (EDT)

Hi Bob. In a couple of days (WT-en) Evan is planning to upgrade the Mediawiki software on which Wikivoyage runs. When he does that all of the numbered links like this one [1] will become neat little images.
Meanwhile the listing format is meant to have a lot more information than a description and a link. Specifically it's:
  • Title, Location information. Contact information. Hours and days. Description. Price range.
The URL used to go at the end, but some people have prefered to link it out from the title. Me, I think that looks terrible especially in the wikitext and prefer to put the URL in the contact information. I think we are going to compromise on putting it in the location information instead though, because some of us (not me) think that URLs are more important than the other contact information. -- (WT-en) Mark 08:31, 2 Oct 2004 (EDT)
Hi Mark. Yes, I understand that the listing information is more complex than in my example. The idea was to keep it simple. I didn't know about Evan's change (there's so much here to read) but it sounds good! Presumably one can choose the image and hence use some standard one for external web links. (WT-en) Bobkemp 18:18, 2 Oct 2004 (EDT)

Wikimedia 1.3.5[edit]

We're now finally running Wikimedia 1.3.5 and, at least in the Monobook skin, you finally get nifty little external icons (Whee!). I think this would be a good time to decide on a format Once and For All.

I suggest this:

  • Title, Location information. Contact information, [2]. Hours and days. Description. Price range.

When printed, this looks like this:

  • Title, Location information. Contact information, (2) ( Hours and days. Description. Price range.

Two questions:

  1. Do we agree on the overall style — a numbered, clickable footnote with an extlink image?
  2. How about the exact location: after title, after location or after contact?

Comments welcome. (WT-en) Jpatokal 23:44, 10 Oct 2004 (EDT)

I personally don't like the "numbered" aspect of this format. I think a lone icon like Bob suggested above would parse better. As for the location of the icon, I think it works well there (or it could also be immediately after the title). -(WT-en) nick 01:01, 11 Oct 2004 (EDT)
Now that I see the wiki code, my initial practical problem with numbers is gone, but I still don't like the looks of it. I don't have any specific suggestion for improvement though, as I think the little link symbol would be too small by itself. Maybe something like link or website, printing simply as ( might work. The location is a good compromise though. Keeps the website with the practical information, but still has the neat, consistent start to each line. I expect there'll still be a lot of editing required to change work by new users to conform to MoS.
-- (WT-en) Neil 01:14, 11 Oct 2004 (EDT)
Can the number be automagically be replaced with a string like "web"? (The shorter the better.) 01:34, 11 Oct 2004 (EDT)
It shouldn't be too hard. I'll see if I can come up with a patch. Of course whether or not to apply it should be a community decision. -- (WT-en) Mark 04:26, 11 Oct 2004 (EDT)
How does this work with screen-readers that sight impaired people use? They generally prefer, as far as I know, to have meaningful text associated with links ("2" conveys little meaning, and nor does "small icon"), but I am no expert. -- (WT-en) Hypatia 04:57, 11 Oct 2004 (EDT)
I haven't used one either so I'm just guessing, but it seems to me that a screen reader would use its own CSS, and since the data's all there it would do something sensible with that data. -- (WT-en) Mark 05:04, 11 Oct 2004 (EDT)
Quite possibly, it's just that "Name of attraction... [intervening text]... link that happens to be to attraction" doesn't seem to me to give the CSS a lot of data to work with. I don't think you can indicate in CSS the association between that name and the link, which I imagine the screen-reader would want.
For example, I believe it's possible to get screen-readers to read out just the links on a page -- having it read "1, 2, 3, 4, 5" or "pic, pic, pic, pic, pic" isn't helpful. The association between Name of attraction and "link a little while later" is obvious to sighted readers, it's obvious to a program that explicitly recognises Wikivoyage conventions, but I don't see how it's obvious to CSS or anything that only has the DOM tree to work with.
If possible I'll get hold of a screen reader and try it out if someone can give me a good sample page, but I'd be a novice user. -- (WT-en) Hypatia 06:21, 11 Oct 2004 (EDT)
. Hi. I've just looked at the spec for HTML 4.01 and it seems that the 'title' attribute of the HTML 'a' tag is what we need to set, ie <a href="" title="Website for BigCo Plc">...</a>. That is what 'audio user agents', as they call them, are supposed to speak. (HTML title attribute defn). Currently we put the URL in there but presumably [ BigCo web site] could be made to set the title attribute to 'BigCo web site'. (WT-en) Bobkemp 21:14, 11 Oct 2004 (EDT)
It's not so much links of the form [ BigCo web site] that worry me, it's the links proposed for attraction listings and so on, which are of the form [] (ie, no name, just the link). So, for example this wiki text:
'''BigCo's Bar''', 100 Something St. ph 000 000 000. []. Big Co's bar is the most happening place in town. $5 cocktails.
The HTML output of the [] wikitext will be something like: <a href="">[3]</a>; there's no title tag for the screen readers, and the nearest appropriate meaningful text is right back at '''BigCo's Bar'''. As best I can tell, the only option the screen readers have to describe <a href="">[3]</a> is to read out "link to double u double u..." or "link to square bracket three square bracket", or perhaps "unlabelled link" when they encounter links in the proposed listing style.
Of course I realise that the existing listing style has exactly the same problem. However, I thought I'd raise it because the trend seems to be very much towards "external URLs in listings should have as little text associated with them as possible, and we will in particular not associate titles with them". And for sighted web users and print users it is easy to look back to the beginning of the listing for the title, but screen readers tend to rely on links having meaningful text either <a href="link">HERE</a> or <a href="link" title="HERE"></a>. Neither the existing or proposed new listing format support that. -- (WT-en) Hypatia 14:43, 19 Oct 2004 (EDT)
. Mea culpa. The example I gave wasn't so appropriate for listings. I was more concerned with what had to go into the low-level HTML. What we need, it seems, is a way of specifying text for the link and for the title separately -- assuming we go with a terse link text like 'Web'. See below for my next suggestion (See also) which may avoid this problem.
. How about a more concrete (and slightly hacked) example in your suggested format
  • Auberge du Pont de Collonges, 40 Quai de la Plage. [3], Tel 04 72 42 90 90, Fax 04 72 27 85 87. Open 11am-3pm,7pm-1am every day. Paul Bocuse's restaurant, one of the most famous restaurants in France. From €100.
Using text instead of the number would leave it as
  • Auberge du Pont de Collonges, 40 Quai de la Plage. Web, Tel 04 72 42 90 90, Fax 04 72 27 85 87. Open 11am-3pm,7pm-1am every day. Paul Bocuse's restaurant, one of the most famous restaurants in France. From €100.
That looks nice but would it be better if we used images instead of 'Tel', 'Fax', 'open', etc. There is an 'alt' attribute to HTML image tags for use by browser (alt attr defn), so the system can generate HTML that screen readers can interpret.
With text (or image) instead of the number and possibly images for Tel, Fax, etc personally I think the web version would look good.
Not so sure about the print version. If the URL is short it would look okay inlined but if it's long and complex it will look hideous. Even putting all URLs as footnotes in the printed version might produce half a dozen footnotes which would look awkward especially if they're short enough to look okay inline. Could there be some option in the wiki markup to force it to a footnote? I noticed that the markup for images has some options, eg [[Image:Paris_arrondissements_overview.png|thumb|350px|The Layout of Paris by district]]. How difficult would it be? An option to flag the URL as cumbersome would allow the writer some flexibility. (WT-en) Bobkemp 22:37, 11 Oct 2004 (EDT)
Actually, Unicode has a large set of Miscellaneous Symbols and Dingbats that could also be used with much less overhead. ☎ Tel , ✉ E-Mail, etc. The major problem with these is that there's no fallback if the user's browser doesn't support them, they'll just get a "?". (WT-en) Jpatokal 04:27, 12 Oct 2004 (EDT)
. Well, unless we wanted to get into browser-specific code perhaps the images aren't so practical then. I was just throwing up ideas to see what people thought. (WT-en) Bobkemp 22:38, 15 Oct 2004 (EDT)

. Part of the 'problem' is that a link on a web site is usually displayed differently to a phone number, ie you don't usually see the URL, just some explanatory text. In contrast, you can't usually click on a link to ring someone. That's one reason why links on a website should probably be treated differently to a phone number. However, what happens if there's also a Wikipedia entry? That's another URL, in addition to the company's own one and there may be others. Using 'Web' won't solve it either because there may be several non-wiki sites. How about using text like ''See also [ BigCo web site], [[Wikipedia:BigCo]]'' at the end of the entry for external links. If the example looks unlikely, think of entries in the Michelin restaurant guide, etc. The previous concrete example then becomes something like
Is that a runner? Or too repetitious? To address Hypatia's concerns (above) about screen readers, we need to say somewhere (link text or title) whose web site it is. Repeating that for a Michelin Guide entry would look bad but would it be needed? (I have no experience of screen readers, so cannot comment). Being able to distinguish between link text ('Michelin Guide entry') and the title for a screen reader ('Michelin guide entry for XYZ') might still be useful.
If the descriptive text (Paul Bocuse's restaurant, one of the most famous restaurants in France) was quite long this might not look so good because it would then separate the website links from the other contact info but if the description is that long perhaps it could go in a new paragraph and the 'See Also' part could tag on after the main contact details.
By the way, note how unreadable the Michelin Guide URL is. Would you want to see that in a printed listing? Even in a footnote it would be useless. To produce a readable printed version, perhaps we need a way of reproducing the URL inline, as a footnote or omitting it depending on a wiki markup option. Omitting would be awkward. What do people think about creating Wikivoyage page for the printed version describing key external sources -- like an appendix? This appendix could list home pages of Michelin Guide, National Trust, National Tourism Offices,etc and, in the printed version, an unreadable URL would just display as the link text which would mention (as in the example) the Michelin Guide and leave it to them to remember the appendix. It might be awkward however to keep everything in sync. (WT-en) Bobkemp 10:25, 21 Oct 2004 (EDT)
Terribly verbose and in the wrong place. I also see no reason to link to Wikipedia entries for attractions, since they're unlikely to contain much practical information (opening times, admission fees, maps etc).
I still think the simple automated "Web" in the contact info section is by far the best proposal anybody has come up with. (WT-en) Jpatokal 11:28, 21 Oct 2004 (EDT)
I like that best too, but I do wish there was a way to make the HTML come out as <a href="" title="Meaningful title here">Web</a> rather than <a href="">Web</a>. That's all that is needed to solve the screen-reader issue: it's standard meta-data for anything that wants to grab the links on the page without scanning the content and getting meaning like a (sighted) human reader does. -- (WT-en) Hypatia 11:45, 21 Oct 2004 (EDT)
. Yes, it is verbose but that's partly because I was trying to make the link readable for a screen reader. If we had some other way of handling that, we could write See also their web site or Michelin entry which would be less excruciating.
It's also true that Wikipedia references for restaurants would not be much use but what about the 'See' section. The Eiffel Tower has history as well as opening times. Am I being overly general here? For restaurants, hotels, etc no contest but for historical features Wikipedia can provide more detailed historical data that we probably don't care to duplicate.
Despite that, if the vote is for the simpler version, that's fine by me. (bobkemp with new sig) (WT-en) Bob 16:04, 21 Oct 2004 (EDT)