genmon / aboutfeeds Goto Github PK

My RSS feeds include a short plain text description of each post in the <description> element within each <item>.

These aren't rendered by the current pretty-feed-v3.xsl file.

I've added something like this, between the item title and Published date:

<p class="mb-0">
  <xsl:choose>
    <xsl:when test="string-length(description) &gt; 200">
      <xsl:value-of select="substring(description, 0, 200)" />…
    </xsl:when>
    <xsl:otherwise>
      <xsl:value-of select="description" />
    </xsl:otherwise>
  </xsl:choose>
</p>

This displays the entire <description> if it's 200 characters or fewer, otherwise displays the first 200 characters followed by an ellipsis. (200 is just arbitrary.) e.g.:

But I think some people have the entire HTML blog post within <description>, between <![CDATA[ and ]]>. This might be problematic if it's truncated mid-tag, or between opening and closing tags? Or maybe the HTML itself would be visible?

AFAIK there isn't a way to detect if the description starts with ![CDATA[ or not, so I'm not sure if this idea can be reliably generalised.

But, given I know my feeds only have a brief plaintext description, I've gone with the above.

Currently, the listed apps include apps for Android, iOS and macOS, as well as web-based apps. But there is no desktop app for Windows or Linux listed. This looks like a shortcoming.

https://github.com/RSS-Bridge/rss-bridge

https://rss-bridge.org/bridge01/

There's a certain amount of the "Who made this site?" section that needs to be on the homepage, but not all of it -- it just adds to the length of the page.

In particular, the top CTA for site owners needs to be there, and a shorter version of the "who made this/why" text.

The longer form can be elsewhere.

I would like to propose the idea of customizing automatically the landing page to include the original website's feed URL.

As a site owner, instead of linking to https://aboutfeeds.com/, I would link to https://aboutfeeds.com/to/http://myurl.example.com/feed.rss or something similar so that my visitors will see my URL on the aboutfeeds landing page.

As a visitor, when I land on the customized landing page, I see a big text box that says:
"Copy this into your feed reader: http://myurl.example.com/feed.rss".

The idea comes from the Matrix chat app and their matrix.to URL that provides link to various matrix clients and makes it easy to 1 click launch each client directly into the linked chatroom. This makes it very easy for visitors.
See this example: https://matrix.to/#/#bibliogram:matrix.org

Another example is the feedburner customized XML page. They add some CSS to the XML to make it visible in browsers.Look at the box "Subscribe now!" on the right side. They have buttons to automatically subscribe using popular services. Unfortunately, their links are very outdated and most services don't exist anymore.

Problem: Web feeds are hard to discover for users (whether the site has a feed and, if it does, where that feed is).

This page should include a list of ideas would help when attracting users who don't yet have a newsreader installed.

Candidate ideas...

• Link (should it use feed: or not?)
• Link text copy
• Standard icons: see http://www.feedicons.com
• Help copy (linking to AboutFeeds.com)
• Implementing RSS/Atom/JSON Feed -- which to choose and validators
• Feed auto discovery
• Using XSLT to make an attractive, semi-formatted RSS feed which includes a "What is this? How to subscribe" link at the top

Hey man i just landed the aboutfeeds from a feed (who would gess that 😂). Im building my own blog, im seeing different blogs feeds trying to decode how those feeds should be crafted, i think it would be nice to add to aboutfeeds a little bit of:

Hey if you are new to the feed crafting stuff you should check out this resource.

What you think ?

Any suggestions about how to do a good feed will be more them welcome.

If a feed item has no title then it doesn't render with a link.

Problem: Newsreaders are mysterious.

For new users, seeing what a newsreader looks like will make it less daunting to jump in.

Useful illustrations:

• Hero image (what a newsreader looks like, in action)
• Images of the different recommended newsreaders
• GIFs of subscribing to a feed with the different recommended newsreaders (on a separate page?)
• How to identify a feed: examples of what a Feed URL looks like on different sites

As your own blog posts suggests, how the money thing works, to help communicate the value of feeds, is something that's important, but not traditionally well explored with RSS/Atom/webfeeds.

2. Newsletters and the money thing

The “competition” for RSS is email newsletters. If RSS is going to get taken challenge email as a channel, it could use a few extra features:

• the ability to go paid – Substack offers newsletter authors a platform with built-in free and premium tiers. It offers RSS, but it’s kinda janky: the premium RSS is a private feed address that the user needs to discover and add separately. Maybe the “Upgrade to premium” button could be inside the feed reader itself, and tapping it would seamlessly upgrade the feed?
• virality and community – you can forward an email, and anybody you forward it to can subscribe from the footer. Likewise, you can reply to a newsletter and start a conversation with the author… which might even get rolled into future editions. These social features are great, and they should be built into RSS readers.
• analytics like open rates and click counting. Yeah, RSS doesn’t need this, and email is moving away from it too.

There are likely good some examples of payment flows in other services that make subscriptions work, and it might outline why they work, and which parts might work for RSS.

I've created this issue here, I can't really find much elsewhere, and this seems as good a place to discuss as any right now.

In addition to RSS (in its many flavors) there is also the Atom feed format

https://validator.w3.org/feed/docs/atom.html

Most of the time a site that offers Atom also offers some form of RSS, but there are cases of atom-only feeds and folks should be aware of them.

Hi @genmon

I'd be willing to translate index.md to French, if you're OK with it.
Would index.fr.md be a good file name at the project root, or do you have plans to add /fr/ etc. to the URL tree for each translation?

If the audiences want to dig deeper, my repo might be able to demonstrate the diversity of the realm of RSS.

This isn't something that should be on the front page, but it might be useful to collect examples of how to subscribe to the feeds of sites that don't obviously have them. For example:

• There are lots of things, besides individual subreddits, you can subscribe to on Reddit
• Subscribe to YouTube channels or your export YouTube subscriptions OPML
• Getting RSS for YouTube playlists or users is possible but more fiddly

Great site!

One thing you might want to mention is the ability to read feeds by email, so you don't need a new app, you can just use your current email client. I used to use blogtrottr before switching to rss2email (which is too technical to recommend to people just starting out).

https://blogtrottr.com/

I made a small tool which helps discover feeds based off of urls:

https://discovery.thirdplace.no/?q=https://www.kode24.no

It works by having lots of hardcoded rules but also some dynamic discovery.

This is a great site which I link to from my blog.

I think section 3 could be greatly enhanced by adding a link to https://www.rsslookup.com/ as a way to find url feeds.

Finding the URL is the biggest blocker to non-technical users adopting RSS at scale. This site seems pretty good at finding the link if it exists.

Some colour and illustrations would go a long way to making it readable!

Constraint: this should be a page that all kinds of site owners would be happy to link to.

The problem: it's hard to imagine a newsreader developer linking to the site when their app is only one of three listed... or not listed before. BUT we want links from newsreader websites.

Related problem: I understand that some of the GPL community won't link to aboutfeeds.com because it lists non-GPL newsreaders. This is the problem in a nutshell: many communities will see something about the list of newsreaders as a barrier to linking.

Thinking out loud...

It would be possible to have different landing pages which promote different newsreaders.

I'm reluctant to put these on completely different URLs because this means that those URLs have to be supported forever. And that would make it hard to reorganise the site.

However, there could be something in the query string which slightly altered the homepage to promote a particular newsreader or collection of newsreaders, with the rest of the list accessible from a link.

This idea is dependent on #12 which is the process to list a large number of newsreaders.

Problem: tapping on a Feed URL leads to a baffling XML feed. Tapping on the "Help" link (to AboutFeeds.com) leads to a site that has no call to action to subscribe.

Could this site have a subscribe CTA at the top which is customised depending on a Feed URL passed in the query string?

Could this site auto-discover installed newsreaders, and present a relevant subscribe link by the Feed URL?

Ultimately, what would it mean to have a "Subscribe" button that walks a new user through all the steps required to get set up with the origin Feed URL in their newly-downloaded newsreader?

Problem: There are lots of newsreaders (which is a hurdle to getting started because choosing takes energy) and some of them are challenging for users new to feeds on first run (which means there's a risk that news users bounce off. Also, the more newsreaders that are listed, the greater the overhead in checking that the download/add-subscription instructions are accurate and up to date.

One solution is to narrow down on a small number of recommended readers (which is what I've done to start with).

But another solution might be a comparison matrix, narrowed down to just the most popular readers that are aimed at a general audience.

Two questions to start:

• What's a good authority for a list of the top newsreaders, covering all the platforms?
• What are the criteria to decide which of those gets included (as being friendly for new, general users)?

To help make feeds visible on page, you could encourage people to look for or use the standard feed icon http://www.feedicons.com as well as the the Help text.

Hi
If I see this right, the base license of all of this as specified in the README is Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. Is that really intended? It would make it impossible to ship this as a default in for example a BSD licensed blog software, as I was considering to do.

My suggestion would be to re-license the .xsl as either BSD or GPL - if GPL I'm not sure I can use it for this specific project, but at least it's a valid code license. Most problematic of the current situation is the NC aspect, that makes shipping it anywhere basically impossible, and also causes a very high risk when using it in a website of your own in legislations like germany.

I tried to use pretty-feed-v3.xsl for my Atom feeds, but it didn't work at all because Atom and RSS have different XML structures.

I tried to build an alternative version for Atom feeds, but I don't know if my specific Atom feeds match the common use case.

I also don't know if it would be possible to share a single XSL stylesheet for both RSS and Atom.

Here's my version:
https://github.com/nhoizey/nicolas-hoizey.com/blob/main/src/assets/pretty-atom-feed-v3.xsl

Here's how it looks:
https://nicolas-hoizey.com/feeds/all.xml

A few notes:

• I removed the target="_blank" attributes for accessibility
• I moved the code for each item in a specific <xsl:template> to ease maintenance

I can make a PR if you want to iterate over it.

When feed auto-discovery works, it's a great user experience, and lots of newsreaders promote entering the website URL in the "Add a feed" box as a convenience function -- so it needs to be mentioned. (As otherwise users will be thinking "where do I enter the Feed URL?")

But I'm reluctant to recommend it as the primary route as it feels like an expert feature, so it doesn't belong in a Getting Started guide.

In my (informal!) testing, the experience of auto-discovery was:

1. Go to a site that looks like it should support RSS (i.e. it has updates, it's reverse chronological, it's structured like a blog)
2. Give the site URL to a newsreader (in this case, using the iOS Share sheet to hand it to NetNewsWire)
3. It didn't work for the first 2 sites we checked -- and when using the Share sheet, you don't even get a "Couldn't find a feed" alert

After inspecting the source, it turned out that these 2 sites didn't support RSS. So the learnings are

1. RSS is less well-supported than it was
2. For a new user, the experience of trying to use auto-discovery and it failing is just baffling

So in the first instance, that's why the site promotes a longer but guaranteed successful path.

But auto-discovery does need to come up... but how? Maybe as part of an "Advanced usage" guide?