Xtof : Page créée avec « {{stub}} Une '''prévisualisation de lien''' est ce que les articles présentent à propos d'un ou plusieurs liens embarqués, par ex. une en-tête, une image,... »

2018-04-05T03:59:17Z

Page créée avec « {{stub}} Une '''<dfn>prévisualisation de lien</dfn>''' est ce que les articles présentent à propos d'un ou plusieurs liens embarqués, par ex. une en-tête, une image,... »

Nouvelle page

{{stub}}

Une '''<dfn>prévisualisation de lien</dfn>''' est ce que les articles présentent à propos d'un ou plusieurs liens embarqués, par ex. une en-tête, une image, un résumé provenant du lien de destination.

== Pourquoi ==
Envisagez d'afficher une prévisualisation de lien afin que votre lecteur ait quelque attente de ce qu'il recevra quand il cliquera sur un lien.

== Comment ==
=== Comment publier ===
By using an [[auto-embed]] function (like the [[CASSIS]] "auto_link" (not a typo) function), you can provide inline embedded images and videos in your plain text notes that have links.

If you do the usual mark-up your posts with [[h-entry]], specifically:
* <code>p-name</code>
* <code>"p-author [[h-card]]"</code> (with at least <code>p-name</code>, <code>u-url</code>, <code>u-photo</code>)
* <code>u-featured</code> (if any)
And for [[photo]] posts, the usual:
* <code>u-photo</code>
Then link-preview parsers will be able to use those to generate link previews of your posts.

See also: http://microformats.org/wiki/link-preview-brainstorming#publishing

=== How to parse ===
To parse a link for information to show in its link-preview, do the usual
* parse for an [[h-entry]]
Then get the following information from the following microformats parsed properties:
* <code>name</code>
* <code>summary</code> (if any), otherwise, text-only value of <code>content</code>, elided as necessary
* <code>author</code> (<code>name</code>, <code>photo</code>, <code>url</code>)
* image
** from <code>featured</code> if any
** else <code>photo</code> if any

See also: http://microformats.org/wiki/link-preview-brainstorming#parsing

== approches indieweb ==
A few indieweb sites are figuring out how to better support embedding:
* [[User:Tantek.com|Tantek]]: I'm thinking of improving the posting UI on my site, so that when I'm previewing a post before PuSHing and syndicating it out, the post preview UI retrieves the link preview(s) on the server, and then shows them to me as part of the overall post preview before I hit the "Publish" button. When I hit the "Publish" button, the same logic which makes a syndicated copy to Twitter (by calling the Twitter API), and then saves the Twitter copy permalink in my data store, can also save the link preview(s) in the same data store accordingly. just piggybacking the same data store write to file call.
* This is similar to another thing I’ve had on my implementation list for a while, which is a better quoting UI. Specifically, my posting UI detects URIs in my content, loads up previews, allows me to D&D in for link previews, perhaps load the content and allow me to select, D&D for quotations --[[User:Waterpigs.co.uk|Waterpigs.co.uk]] 13:23, 7 March 2013 (PST)
* {{kevinmarks}} built a [http://pageaspreview.herokuapp.com utopian idea] that iframes the site itself as a preview, relying on it using responsive design
* {{martymcguire}} experimented with replacing bare URLs in the content of posts with an [[h-cite]] containing their link preview.
** [https://martymcgui.re/2017/06/13/152026/ Example post]([https://web.archive.org/web/20170618001657/https://martymcgui.re/2017/06/13/152026/ archive.org version])
** However, content within the h-cite would show up in subsequent link-previews of this post. [https://chat.indieweb.org/dev/2017-06-17/1497742260646000 IRC Example]
** For now, moved link-previews outside of <code>p-name</code> and <code>e-content</code>. In markup terms, this means that a link-preview appears after the content that refers to it, and the original URL remains in place (converted to a clickable URL). This is similar to Twitter's link-previews.

== Exemples dans les silos ==
Various social network silos (e.g. Facebook, Twitter, Google+) show link previews underneath notes and comments that have one or more URLs, by extracting information from those URLs content and showing a title/summary/photo for those URLs underneath the posted note/comment.
=== Facebook ===
[[Facebook]] utilise [[OGP]] à partir du premier lien dans un post, c'est-à-dire : [https://www.facebook.com/tantek.celik/posts/10101317488329623]
* Supporte l'affichage d'une prévisualisation de lien d'un lien tweet y compris le texte du tweet et l'image dans le tweet s'il y en a, par ex. avec une image : [https://www.facebook.com/tantek.celik/posts/10101317397351943]

Facebook a un certain nombre de guidelines concernant les images dans sa documentation :
* https://developers.facebook.com/docs/sharing/best-practices#images

They show different link-preview layouts for images of different resolutions!
* Large ( > 600x315px - both dimensions? > 1200 x 630 preferred "for the best display on high resolution devices")
** image is shown above text from link preview
* Small ( < 600x315px - either dimension? but > 200x200px both dimensions?)
** image is shown next to text from link preview
* None ( < 200x200px - either dimension? )
** no image preview possibly?

There are third-party guidelines that does not follow Facebook's own though:

* AddThis: http://support.addthis.com/customer/portal/articles/1399895-adding-open-graph-tags-using-blogger Suggest including Blogger-thumbnail as image, which by default is 72x72px.

=== Google+ ===
[[Google+]] uses an assortment of [[microformats]]/meta/schema/[[OGP]]+

=== Pinterest ===
[[File:pinterest_link_preview.png|200px|thumb|right]]

[[Pinterest]] uses [[OGP]], [[Microformats]], and Schema.org for their "[https://developers.pinterest.com/rich_pins_overview/ Rich Pins]"

=== Twitter ===
[[Twitter]] uses their own white-list-domain limited meta + [[OGP]] AKA "[[Twitter Cards]]" on the last link in a tweet, e.g.: [https://twitter.com/t/status/520773727370633217]

As of (2015?) Twitter *does* support showing a link-preview of a tweet link, e.g. https://twitter.com/t/status/520758106838818816 (they previously didn't)

However, Twitter fails to show a link-preview for many links, resulting in odd link-only cross-posts from Facebook, where presumably the author did see a link-preview (because Facebook looks at far more information for the link-preview than Twitter does)

[https://www.rmendes.net/2016/protip-dont-connect-your-twitter-account-to-facebook-or-your <img src="https://www.rmendes.net/file/7c3da11a1c4e0494ec0cc30c8315aecc" alt="" style="max-width:100%"/>]

=== Slack ===
They call creating link previews “[https://api.slack.com/docs/unfurling unfurling]” a URL. They support [[oEmbed]] and [[OGP]] (including twitter extensions), as documented in [https://medium.com/slack-developer-blog/everything-you-ever-wanted-to-know-about-unfurling-but-were-afraid-to-ask-or-how-to-make-your-e64b4bb9254 this blog post].

=== ... ===
* ... who's next to make up their own site-specific link preview markup convention?

== other link preview standards ==
There have been a couple of open standards created explicitly for information for link previews.
* [[oEmbed]] - since 2009. However it requires an extra endpoint (URL, different language(s) etc.)
* [[OGP]] - far more well established since it works in HTML, and [[Facebook]] immediately shows results using it.

See http://microformats.org/wiki/link-preview-formats for more prior art research.

== simple link preview standard ==
[[h-entry]] is a useful building block for this. E.g.

<code><body class="h-entry"></code> is a good simple baseline way to markup data for link previews.

For more details towards the development of a simple link preview standard, see:
* http://microformats.org/wiki/link-preview-brainstorming

== brainstorming ==
=== featured image ===
Beyond h-entry's existing properties, there may be a need for additional properties to satisfy the same use-cases as documented by the "existing silo support" above.

E.g. most commonly, a thumbnail image to put next to a post, or rather as a publisher to provide a thumbnail / representative / featured image for others to display as part of a link-preview.

[[WordPress]] has good prior art here:

http://codex.wordpress.org/Post_Thumbnails: <blockquote>Post Thumbnail, '''now Featured Image''', is an image that is chosen as the ''representative image'' for Posts, Pages or Custom Post Types. The display of this image is up to the theme. This is especially ''useful for "magazine-style"'' themes where each post has an image. </blockquote> '''Emphasis''' and ''emphasis'' added.

=== u-featured ===
Thus we can learn from the WordPress's experience and go with their naming of "Featured Image" - although we can simplify that - why limit to an image when some may (and do!) want to feature a video, or an audio playback stream, etc. as demonstrated by the variety of [[Twitter Cards]]?

Thus we can introduce a "featured" property for this use-case, expected to be used as a "u-featured" property inside an h-entry that is a URL to the asset to feature for that post. Handling of different types is up to the link-preview displaying client. E.g. it could do different things based on <code>Content-Type</code> of the URL when requested, or check its file extension (e.g. .gif .jpg .png .mov .mpeg .mp4 .mp3) and provide markup accordingly, just as existing [[autoembed]] solutions do.

== implementation wishlist ==
It seems like an indieweb implementation of a "link preview" feature would need:

# Open way to '''markup''' the info on pages that we want to go into a preview (obv min: name, summary, photo). See "simple link preview standard" above.
# OSS '''library''' that retrieves a page and '''generates simple embeddable preview markup'''. Such a library would return you the markup snippet with preview name/summary/photo - you just need to store that however you store information in your posts, so you can retrieve it from your store rather than the external URL. Ideally the markup snippet returned would support the same format as in #1 so it is completely re-usable without loss of fidelity.
# Exercise for each indieweb implementer: '''code to store/cache that embeddable markup''' in your personal post data store so that you can redisplay it without having to rerequest the external URL (has the advantage of snapshotting the preview as of the time you posted the note in case the external URL content changes or dies).

Utilities:
* Link preview validator/previewer - a validator which would parse a URL and show you what preview might result. Note that Twitter has a [https://dev.twitter.com/docs/cards/validation/validator Twitter Card validator] (login required) - we just need to build an indieweb version of it (and not require login).

== See Also ==
* [[cards]]
* [[h-entry]]
* [[POSSE]]
* [[silos]]
* [[microformats]]

[[Category:building-blocks]]
* every silo has their own way of looking for these, so one page can have a different preview per silo: http://www.kevinmarks.com/partialsilos.html

Link-preview - Historique des versions

Xtof : Page créée avec « {{stub}} Une '''prévisualisation de lien''' est ce que les articles présentent à propos d'un ou plusieurs liens embarqués, par ex. une en-tête, une image,... »