Classification of articles

[tmos]

Ah we already discussed, it would be great to be able to classify articles from their type.

So we can display differently

• audio
• video
• galleries
• something else ?

Should we use system tags to handle this feature ?

[Phyks]

Yes, this is already implemented in the backend. I took this wikipedia page and used the categories to create system tags:

• application
• audio
• example
• image
• message
• model
• multipart
• text
• video

[Phyks]

My bad, I did not fully implement it yet. I created the system tags, but did not do the backend code to automatically tag articles based on their enclosures type (or anything else you want).

[eliemichel]

We could have some _displaystyle_foo tags to specify how to display the entries. @Phyks I think we should always prefix system tags that represent a category in order to avoid conflicts.

We could add some styles such as status (tweet-like) for short entries, link for shaarlis, and also quote, snippet, etc. I think we should (one day) have some easy way to add display styles. Of course the last examples can't be auto-detected, but we can tag a feed with such a system tag.

[Phyks]

:+1:

[tmos]

The style could be set by the user (this feed is a picture feed, this one audio), and overrided by the enclosure, if present ?

[eliemichel]

Yep

[tmos]

depending the type, a backend operation could be necessary (adding the player for example, or creating the download link).

For the frontend part, A variable to display the type will be enough to add classes to the article (value[type] or something like that).

We have to agree on what each type have to return :

• application : ?
• audio : an html player
• example : ?
• image : an image url
• message : ?
• model : ?
• multipart : ?
• text : text that we display in a lightbox ? Or with quote format ?
• video

[Phyks]

So, here's my implementation proposal: We create extra system tags called _displaystyle_$type for $type in audio, image, text, video. audio, image, text and video are the relevant MIME-Type categories (AFAIK, I may have missed some).

If we detect an enclosure with a MIME-type entering one of the above categories, we tag the corresponding entry with the matching system tag _default_style_*. The user is free to choose the way to display such entries either via a special menu or by tagging some feed.

Then, when displaying such an entry, all the informations are in the $entries variable and everything can be in the template. Some ideas for the way to display these entries (based on @tmos suggestions):

• audio : an html5 audio player
• image : a lightbox ?
• text : text that we display in a lightbox ? Or with quote format ?
• video : an html5 player, I know that this one is a good one, although I did not experimented it yet

Then, we are free to implement new display styles such as quote, links, snippets, webzine or whatever, in the future.

What do you think ? If it's okay, I think it may be the next thing I will handle after the end of the current refactor and closing issues work.

[tmos]

I'm okay with this, just two details :)

• The user is free to choose the way to display such entries The user is free to add the type to a feed, so all articles of this feed are classified as audio, or as video, etc. But not really how to display it, isn't it ?
• displaystyle is okay, but as we may use this information, maybe a less display-specific name could be better, like type of something like that.

[Phyks]

Yes of course for the type. Then, it's the template job to apply the correct style.

:+1: for type instead of display style.

[Phyks]

Should be ok by now, although I did not test it yet as I don't have feeds with enclosures to use to test…

[tmos]

If I remember correctly, this one have some : http://feeds.wired.com/RawFile (and ads too btw…)

[Phyks]

Beurk ce flux… Je vois pas d'enclosures dedans (balises <enclosure> dans le flux). Par contre, il y a des images et des liens dans le contenu du flux.