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@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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
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?
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@wikimedia.org wrote:
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@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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
+ wikitech
On Tue, Oct 29, 2013 at 8:54 AM, Siebrand Mazeland (WMF) < smazeland@wikimedia.org> wrote:
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@wikimedia.orgwrote:
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@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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
Design mailing list Design@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
+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_li... https://www.mediawiki.org/wiki/Special:Code/MediaWiki/60320
HTH. Quiddity
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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Tue, Oct 29, 2013 at 11:41 AM, quiddity 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_li... https://www.mediawiki.org/wiki/Special:Code/MediaWiki/60320
HTH. Quiddity
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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@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_links_padlock https://www.mediawiki.org/wiki/Special:Code/MediaWiki/60320 HTH. Quiddity _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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@gmail.com wrote:
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 https://twitter.com/JaredZimmerman>
On Tue, Oct 29, 2013 at 11:41 AM, quiddity <pandiculation@gmail.com <mailto:pandiculation@gmail.**com 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<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<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 somereason. https://en.wikipedia.org/wiki/**MediaWiki_talk:Common.css/** Archive_11#Secure_links_**padlockhttps://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_11#Secure_links_padlock https://www.mediawiki.org/**wiki/Special:Code/MediaWiki/**60320https://www.mediawiki.org/wiki/Special:Code/MediaWiki/60320
HTH. Quiddity ______________________________**_________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.**wikimedia.org<Design@lists.wikimedia.org>https://lists.wikimedia.org/**mailman/listinfo/design<https://lists.wikimedia.org/mailman/listinfo/design>______________________________**_________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/designhttps://lists.wikimedia.org/mailman/listinfo/design
______________________________**_________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/designhttps://lists.wikimedia.org/mailman/listinfo/design
On Tue, 29 Oct 2013 21:33:03 +0100, Brion Vibber bvibber@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.
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
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
Nemo
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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Oct 31, 2013 at 2:19 AM, Federico Leva (Nemo) nemowiki@gmail.comwrote:
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.htmlhttp://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_Pageshttps://www.mediawiki.org/wiki/Archived_Pages
Nemo
______________________________**_________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/designhttps://lists.wikimedia.org/mailman/listinfo/design
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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Oct 31, 2013 at 2:08 PM, Quiddity pandiculation@gmail.com wrote:
PDFs:
- 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-4https://en.wikipedia.org/wiki/Scrabble#cite_note-4
- Not all PDF links work even in Firefox, eg:
https://en.wikipedia.org/wiki/**Scrabble#cite_note-12https://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 https://twitter.com/JaredZimmerman>
On Thu, Oct 31, 2013 at 2:19 AM, Federico Leva (Nemo) <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@lists.wikimedia.org <mailto:Design@lists.**wikimedia.org<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@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/designhttps://lists.wikimedia.org/mailman/listinfo/design
______________________________**_________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/designhttps://lists.wikimedia.org/mailman/listinfo/design
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@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@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@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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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.