Are external link icons useful

List overview All Threads
Download

newer

older

Agora button semantics and CSS...

Design Team Promotion

Jon Robson

28 Oct 2013 28 Oct '13

11:22 p.m.

Changed subject to reflect this change in topic. Also cc'ing design mailing list. In terms of external links to me I don't care about whether I'm leaving the site or not. If I clicked on something and it wasn't what I expected that's a badly labeled link. A link saying there is more information on the [white house official website] and a link to the word [house] should be enough information to tell which I'd external and which isn't. I actually think the only place an icon next to a link really makes sense is for downloads. Clicking something that downloads a PDF when I thought it was a web page is a little confusing (on mobile at least). That said if all the external links are in the external links / references section wouldn't encouraging that organisation of links be better....? Also I agree with Juliusz that we shouldn't force behaviour of where links open. It should be up to the user if they want the same tab or new one and it should be configurable within the browser preferences. On 24 Oct 2013 16:07, "Juliusz Gonera" <jgonera(a)wikimedia.org> wrote:

...

No, we should definitely not warn people, that's just weird ;) It's not like something bad is about to happen. I'm also not saying that users have the expectation that links point to local URLs, I'm only saying that it might be a useful piece of information to some. On 10/24/2013 02:48 PM, Jared Zimmerman wrote: Its definitely a less heavy handed way of doing the thing many (annoying) sites do when they warn you that you're leaving their site. I just wonder is the signal to noise it worth it. I don't know that modern web users have any expectations that link within a site always point to local site urls. * * * * *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>

Attachments:

attachment.htm (text/html — 4.2 KB)

Show replies by thread

Quim Gil

29 Oct 29 Oct

4:39 p.m.

On 10/28/2013 03:22 PM, Jon Robson wrote:

...

That said if all the external links are in the external links / references section wouldn't encouraging that organisation of links be better....?

While this is mostly true in Wikimedia projects, it doesn't necessarily apply to the rest of MediaWiki-based sites. What is the problem that you want to solve? -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

Siebrand Mazeland (WMF)

4:54 p.m.

Also see https://gerrit.wikimedia.org/r/#/c/23424/ In my opinion, external link icons add a lot of visual noise and not that much relevant information. On Mon, Oct 28, 2013 at 11:22 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:

...

_______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

-- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

Jon Robson

6:51 p.m.

+ wikitech On Tue, Oct 29, 2013 at 8:54 AM, Siebrand Mazeland (WMF) < smazeland(a)wikimedia.org> wrote:

...

_______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

-- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate _______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

-- Jon Robson http://jonrobson.me.uk @rakugojon

quiddity

7:41 p.m.

+1 for more discussion, and onwiki discussion to find out why we/they've each kept them in the individual CSS payloads for so many years...

...

>>> On 10/24/2013 02:48 PM, Jared Zimmerman wrote: >>> >>> Its definitely a less heavy handed way of doing the thing many >>> (annoying) sites do when they warn you that you're leaving their site. I >>> just wonder is the signal to noise it worth it. I don't know that modern >>> web users have any expectations that link within a site always point to >>> local site urls. >>> >>>

Wikis are special, in relation to most sites, because of the density of internal links (many per paragraph), and the expectation that most links are internal and will lead to a similar quality/style of information. That applies from Wikisource, to Wookiepedia. In wikis that don't mix external links in the main content (eg most Wikipedias), the icons are also useful *for editors* as they can easily notice that something needs to be moved/fixed. See https://en.wikipedia.org/wiki/Help:External_link_icons for a good list of what the English Wikipedia has. See also recent discussion at https://bugzilla.wikimedia.org/show_bug.cgi?id=54604 ("Ridiculous amount of CSS rules for external links") The only icon that seems (afaik) completely unnecessary, and bright/distracting, is the https padlock, which possibly could/should be replaced with the standard external link icon. (Unless there's a rationale for it that I'm forgetting/unaware of.) See this 2009 discussion where Davidgothberg created a blue (less distracting) replacement, if we need to keep a padlock for some reason. https://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_11#Secure_l… https://www.mediawiki.org/wiki/Special:Code/MediaWiki/60320 HTH. Quiddity

Jared Zimmerman

7:57 p.m.

...

+1 for more discussion, and onwiki discussion to find out why we/they've each kept them in the individual CSS payloads for so many years...

Bartosz Dziewoński

8:38 p.m.

As discussed on https://bugzilla.wikimedia.org/show_bug.cgi?id=54604 , several of the icons – such as the PDF or IRC ones – are clearly useful. Several of them are also clearly useless, such as the HTTPS one. (I would suggest everybody to look at that discussion first to avoid repeating ourselves :) ) Personally I think the default external link one should be kept as well, the indication that this is an external resource is useful. -- Matma Rex

Quiddity

9:11 p.m.

As Bartosz says, and I think most of the communities would agree if asked on their respective village pumps - we value the external link icon in particular, and most of the other icons in general (with the possible exception of the https padlock). We think they are useful for both editors and readers. Re: Gadget - This isn't a particular workflow - this is: "I'm reading a random article, and I notice an external link icon, so, as a wikignome, I either: (if spam) remove it, (if citation) fix it, (if [subjective decision about its relevance/worth and adherence to [[WP:EL]] guideline) move it into the External links section." A gadget would not be a good replacement. By all means clean up the CSS, but do not consider removing the icons without seeking much much wider input. On 13-10-29 11:57 AM, Jared Zimmerman wrote:

...

Nick, good points, for the particular use case sounds like a gadget for showing external links called out for workflows around fixing them would be a good idea. After hearing everyone's thought i'm leaning toward no icons for the average user. * * * * *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman <https://twitter.com/JaredZimmerman> On Tue, Oct 29, 2013 at 11:41 AM, quiddity <pandiculation(a)gmail.com <mailto:pandiculation@gmail.com>> wrote: +1 for more discussion, and onwiki discussion to find out why we/they've each kept them in the individual CSS payloads for so many years... On 10/24/2013 02:48 PM, Jared Zimmerman wrote:

Its definitely a less heavy handed way of doing the thing many (annoying) sites do when they warn you that you're leaving their site. I just wonder is the signal to noise it worth it. I don't know that modern web users have any expectations that link within a site always point to local site urls.

Wikis are special, in relation to most sites, because of the density of internal links (many per paragraph), and the expectation that most links are internal and will lead to a similar quality/style of information. That applies from Wikisource, to Wookiepedia. In wikis that don't mix external links in the main content (eg most Wikipedias), the icons are also useful /for editors/ as they can easily notice that something needs to be moved/fixed. See https://en.wikipedia.org/wiki/Help:External_link_icons for a good list of what the English Wikipedia has. See also recent discussion at https://bugzilla.wikimedia.org/show_bug.cgi?id=54604 ("Ridiculous amount of CSS rules for external links") The only icon that seems (afaik) completely unnecessary, and bright/distracting, is the https padlock, which possibly could/should be replaced with the standard external link icon. (Unless there's a rationale for it that I'm forgetting/unaware of.) See this 2009 discussion where Davidgothberg created a blue (less distracting) replacement, if we need to keep a padlock for some reason. https://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_11#Secure_l… https://www.mediawiki.org/wiki/Special:Code/MediaWiki/60320 HTH. Quiddity _______________________________________________ Design mailing list Design(a)lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design _______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

Brion Vibber

9:33 p.m.

A few background notes: * The generic external link icon is applied by virtual of existence of the 'external' class, which is a nice simple implementation. I kinda like it. :) * In contrast, the CSS rules used to mark certain external links with the PDF, IRC, SSL, etc "specific" icon types are relatively ugly and hard to maintain. These use inefficient client-side attribute value matching. There is a desire to clean these up in the style sheets, which would of course be easiest if they're simply removed. * If it's useful to keep those subtypes, it may be more desirable to implement them differently (for instance by having the parser apply the matching rules and output a class). This would simplify the CSS rules for maintenance, since they would be able to just use the classes. * Note that some of the rules such as PDF detection can misidentify resource types (for instance the rules would mark a File:Blah.pdf file *page* on Commons as "PDF" even though it's not actually a PDF download, but an HTML web page). This would not necessarily change under the above proposal to change implementation, as the basic problem is that you can't really reliably determine a file type from a "file extension" on a URL (the only real way to check is to try fetching the resource, or at least its HTTP headers, and report back what type was received). -- brion On Tue, Oct 29, 2013 at 1:11 PM, Quiddity <pandiculation(a)gmail.com> wrote:

...

Nick, good points, for the particular use case sounds like a gadget for showing external links called out for workflows around fixing them would be a good idea. After hearing everyone's thought i'm leaning toward no icons for the average user. * * * * *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman <https://twitter.com/** JaredZimmerman <https://twitter.com/JaredZimmerman>> On Tue, Oct 29, 2013 at 11:41 AM, quiddity <pandiculation(a)gmail.com <mailto:pandiculation@gmail.**com <pandiculation(a)gmail.com>>> wrote: +1 for more discussion, and onwiki discussion to find out why we/they've each kept them in the individual CSS payloads for so many years... On 10/24/2013 02:48 PM, Jared Zimmerman wrote:

Wikis are special, in relation to most sites, because of the density of internal links (many per paragraph), and the expectation that most links are internal and will lead to a similar quality/style of information. That applies from Wikisource, to Wookiepedia. In wikis that don't mix external links in the main content (eg most Wikipedias), the icons are also useful /for editors/ as they can easily notice that something needs to be moved/fixed. See https://en.wikipedia.org/wiki/**Help:External_link_icons<https://en.wiki… a good list of what the English Wikipedia has. See also recent discussion at https://bugzilla.wikimedia.**org/show_bug.cgi?id=54604<https://bugzilla.… amount of CSS rules for external links") The only icon that seems (afaik) completely unnecessary, and bright/distracting, is the https padlock, which possibly could/should be replaced with the standard external link icon. (Unless there's a rationale for it that I'm forgetting/unaware of.) See this 2009 discussion where Davidgothberg created a blue (less distracting) replacement, if we need to keep a padlock for some reason. https://en.wikipedia.org/wiki/**MediaWiki_talk:Common.css/** Archive_11#Secure_links_**padlock<https://en.wikipedia.org/wiki/MediaWik… https://www.mediawiki.org/**wiki/Special:Code/MediaWiki/**60320<https://… HTH. Quiddity ______________________________**_________________ Design mailing list Design(a)lists.wikimedia.org <mailto:Design@lists.**wikimedia.org<Design@lists.wikimedia.org>

https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wiki… ______________________________**_________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wiki…

______________________________**_________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wiki…

Bartosz Dziewoński

9:36 p.m.

On Tue, 29 Oct 2013 21:33:03 +0100, Brion Vibber <bvibber(a)wikimedia.org> wrote:

...

* In contrast, the CSS rules used to mark certain external links with the PDF, IRC, SSL, etc "specific" icon types are relatively ugly and hard to maintain. These use inefficient client-side attribute value matching. There is a desire to clean these up in the style sheets, which would of course be easiest if they're simply removed.

I think we should apply this logic to bug 1. ;)

...

* If it's useful to keep those subtypes, it may be more desirable to implement them differently (for instance by having the parser apply the matching rules and output a class). This would simplify the CSS rules for maintenance, since they would be able to just use the classes.

There's a bug for that (linked earlier). Patches welcome. -- Matma Rex

Federico Leva (Nemo)

31 Oct 31 Oct

10:19 a.m.

New subject: [Wikitech-l] Are external link icons useful

Jared Zimmerman

9:55 p.m.

New subject: [Wikitech-l] Are external link icons useful

...

Brion's email reminds me that we sometimes use an icon resembling Adobe's A to identify PDF, which is very ugly for an open standard. FSFE's initiative welcomes design help to make their icons better, their maintainer told me: http://pdfreaders.org/**graphics.en.html<http://pdfreaders.org/graphics.… Also, the Internet Archive brought up a proposal to "Create a visual format/style to include an archived link next to an external link". https://www.mediawiki.org/**wiki/Archived_Pages<https://www.mediawiki.or… Nemo ______________________________**_________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wiki…

Quiddity

10:08 p.m.

New subject: [Wikitech-l] Are external link icons useful

PDFs: 1) That's a browser plugin. It works in Firefox, and possibly other browsers, but not all. Eg. this PDF link opens in-browser in Firefox, but not in Chromium: https://en.wikipedia.org/wiki/Scrabble#cite_note-4 2) Not all PDF links work even in Firefox, eg: https://en.wikipedia.org/wiki/Scrabble#cite_note-12 Deadlinks: Very interesting. Thanks Nemo, for letting us know. I've added links to that page at Enwiki, and viceversa. On 13-10-31 01:55 PM, Jared Zimmerman wrote:

...

Conceptually I agrees, somewhat… but partly not. on wiki pdfs aren't downloaded they're viewed on an in-page viewer, its basically not a PDF at that point, so i don't get the value of classifying the links for them. Broken links should be fixed, but in the case where they can't the internet archive things sounds pretty interesting. * * * * *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman <https://twitter.com/JaredZimmerman> On Thu, Oct 31, 2013 at 2:19 AM, Federico Leva (Nemo) <nemowiki(a)gmail.com <mailto:nemowiki@gmail.com>> wrote: Brion's email reminds me that we sometimes use an icon resembling Adobe's A to identify PDF, which is very ugly for an open standard. FSFE's initiative welcomes design help to make their icons better, their maintainer told me: http://pdfreaders.org/__graphics.en.html <http://pdfreaders.org/graphics.en.html> Also, the Internet Archive brought up a proposal to "Create a visual format/style to include an archived link next to an external link". https://www.mediawiki.org/__wiki/Archived_Pages <https://www.mediawiki.org/wiki/Archived_Pages> Nemo _________________________________________________ Design mailing list Design(a)lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/__mailman/listinfo/design <https://lists.wikimedia.org/mailman/listinfo/design> _______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

Jared Zimmerman

10:13 p.m.

New subject: [Wikitech-l] Are external link icons useful

Nick, I'm talking about something different, I'm talking about this https://commons.wikimedia.org/wiki/File:Contributions_redesign.pdf the url points to what appears to be a PDF but mediawiki(?) is displaying it in a viewer/ * * * * *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman> On Thu, Oct 31, 2013 at 2:08 PM, Quiddity <pandiculation(a)gmail.com> wrote:

...

PDFs: 1) That's a browser plugin. It works in Firefox, and possibly other browsers, but not all. Eg. this PDF link opens in-browser in Firefox, but not in Chromium: https://en.wikipedia.org/wiki/**Scrabble#cite_note-4<https://en.wikipedi… 2) Not all PDF links work even in Firefox, eg: https://en.wikipedia.org/wiki/**Scrabble#cite_note-12<https://en.wikiped… Deadlinks: Very interesting. Thanks Nemo, for letting us know. I've added links to that page at Enwiki, and viceversa. On 13-10-31 01:55 PM, Jared Zimmerman wrote:

Also, the Internet Archive brought up a proposal to "Create a visual format/style to include an archived link next to an external link". https://www.mediawiki.org/__**wiki/Archived_Pages<https://www.mediawiki.… <https://www.mediawiki.org/**wiki/Archived_Pages<https://www.mediawiki.org/wiki/Archived_Pages>

Nemo ______________________________**___________________ Design mailing list Design(a)lists.wikimedia.org <mailto:Design@lists.**wikimedia.org<Design@lists.wikimedia.org>

https://lists.wikimedia.org/__**mailman/listinfo/design<https://lists.wi… <https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design>

______________________________**_________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wiki…

Quiddity

10:21 p.m.

New subject: [Wikitech-l] Are external link icons useful

Ah, well that's not an external link, and thus unrelated to this thread! ;-) On 13-10-31 02:13 PM, Jared Zimmerman wrote:

...

Quiddity, I'm talking about something different, I'm talking about this https://commons.wikimedia.org/wiki/File:Contributions_redesign.pdf the url points to what appears to be a PDF but mediawiki(?) is displaying it in a viewer/ * * * * *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman <https://twitter.com/JaredZimmerman> On Thu, Oct 31, 2013 at 2:08 PM, Quiddity <pandiculation(a)gmail.com <mailto:pandiculation@gmail.com>> wrote: PDFs: 1) That's a browser plugin. It works in Firefox, and possibly other browsers, but not all. Eg. this PDF link opens in-browser in Firefox, but not in Chromium: https://en.wikipedia.org/wiki/__Scrabble#cite_note-4 <https://en.wikipedia.org/wiki/Scrabble#cite_note-4> 2) Not all PDF links work even in Firefox, eg: https://en.wikipedia.org/wiki/__Scrabble#cite_note-12 <https://en.wikipedia.org/wiki/Scrabble#cite_note-12> Deadlinks: Very interesting. Thanks Nemo, for letting us know. I've added links to that page at Enwiki, and viceversa. On 13-10-31 01 <tel:13-10-31%2001>:55 PM, Jared Zimmerman wrote: Conceptually I agrees, somewhat… but partly not. on wiki pdfs aren't downloaded they're viewed on an in-page viewer, its basically not a PDF at that point, so i don't get the value of classifying the links for them. Broken links should be fixed, but in the case where they can't the internet archive things sounds pretty interesting. * * * * *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation M : +1 415 609 4043 <tel:%2B1%20415%20609%204043> | : @JaredZimmerman <https://twitter.com/__JaredZimmerman <https://twitter.com/JaredZimmerman>> On Thu, Oct 31, 2013 at 2:19 AM, Federico Leva (Nemo) <nemowiki(a)gmail.com <mailto:nemowiki@gmail.com> <mailto:nemowiki@gmail.com <mailto:nemowiki@gmail.com>>> wrote: Brion's email reminds me that we sometimes use an icon resembling Adobe's A to identify PDF, which is very ugly for an open standard. FSFE's initiative welcomes design help to make their icons better, their maintainer told me: http://pdfreaders.org/____graphics.en.html <http://pdfreaders.org/__graphics.en.html> <http://pdfreaders.org/__graphics.en.html <http://pdfreaders.org/graphics.en.html>> Also, the Internet Archive brought up a proposal to "Create a visual format/style to include an archived link next to an external link". https://www.mediawiki.org/____wiki/Archived_Pages <https://www.mediawiki.org/__wiki/Archived_Pages> <https://www.mediawiki.org/__wiki/Archived_Pages <https://www.mediawiki.org/wiki/Archived_Pages>> Nemo ___________________________________________________ Design mailing list Design(a)lists.wikimedia.org <mailto:Design@lists.wikimedia.org> <mailto:Design@lists.__wikimedia.org <mailto:Design@lists.wikimedia.org>> https://lists.wikimedia.org/____mailman/listinfo/design <https://lists.wikimedia.org/__mailman/listinfo/design> <https://lists.wikimedia.org/__mailman/listinfo/design <https://lists.wikimedia.org/mailman/listinfo/design>> _________________________________________________ Design mailing list Design(a)lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/__mailman/listinfo/design <https://lists.wikimedia.org/mailman/listinfo/design> _________________________________________________ Design mailing list Design(a)lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/__mailman/listinfo/design <https://lists.wikimedia.org/mailman/listinfo/design> _______________________________________________ Design mailing list Design(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

3830

days inactive

3833

days old

design@lists.wikimedia.org

Manage subscription

14 comments

9 participants

tags (0)

participants (9)

Bartosz Dziewoński
Brion Vibber
Federico Leva (Nemo)
Jared Zimmerman
Jon Robson
Jon Robson
quiddity
Quim Gil
Siebrand Mazeland (WMF)