rel value for more general widgets

[panzi]

We at crowdranking.com provide iframe based ranking widgets. These don't really fall in any of the categories (favicon, thumnail, image, player, reader, logo). So I think there should be a general widget or embed rel value. widget is already in use for autodiscovery for W3C widgets, but embed seems to be unused, see the existing rel values.

Here are two example usages of ranking widgets:
http://bloodyalbatross.tumblr.com/post/30356388187/here-i-ranked-the-imho-best-video-game
http://panzi.github.io/Browser-Ponies/ (scroll down)

PS: Currently we don't provide much metadata, but when I've time I will implement an oembed endpoint and reference it in the head of ranking pages.

[nleush]

At this moment we think widgets (like in twitter, slideshare, github.gist etc) are "readers", because user can read them.

We are careful in "rels" invention to prevent useless unspecific cases and specification overload. We have some experience writing embed plugins and embed consumer apps. That experience was a source for current "rels" list. So we try to be practical.

For example: 'thumbnail' and 'image' are very similar but we can see clear semantic difference between them. 'thumbnail' - is something to preview in lists, usually smaller then original. 'image' - individual full image ready to be shown in details. Both cases are very frequent and easy to distinguish.

Besides, we still not used such obvious rels as "video" and "audio" replacing them with common "player".

We will be ready to invent "widget" when clearly understand semantic properties of that embed type to describe in specification.

For now, as I see - "widget" - is something user can read and interact with. Not only read as with "reader".

@iparamonau what would you say about that?

[panzi]

Our crowdranking widget is something the user can interact with. A user can make his/her own ranking of the given items. So I guess it wouldn't be a reader?

[iparamonau]

widgets and embed are too vague of a term to be useful in crafting the user experience. We return reader, for example, as people can "read later", so there is an obvious action associated with the rel.

I envisioned poll or survey to be included into the list of supported rels, as I expect many publishers would be interested in it. We can whitelist it in the iframely when we roll out the reverse consumption of oembed/2 links.

@panzi Would it cover your app and use case? Would you prefer poll or survey?

[panzi]

poll or survey are both fine by me. I don't have any preference.

[iparamonau]

Let's use 'survey' then. I believe it will be more appealing for the publishers.
Thank you.

[nleush]

@panzi, now you can check out how "survey" rel works in new version: http://iframely.com/debug?uri=http%3A%2F%2Fcrowdranking.com%2Fcrowdrankings%2Ft537g0--die-besten-premium-kompaktkameras-2013

[panzi]

Great! :)

[nleush]

@panzi I would recommend you to use max-width for link in crowdranking.com. max-width about 600 would be better then infinite. Or you can use post's image width.