search

Podcastindex-org / web-ui

The public home page of podcastindex.org
MIT License
52 stars 115 forks source link

Is the Supported Element "Value" or "Sat Streaming"? #152

Open dwvisser opened 2 years ago

dwvisser commented 2 years ago

Do "Value" and "Sat Streaming" indicate the same feature? If so, it would be good to standardize on one. (My preference would be "Value", but I am fine as long as there is one term in the UI.)

I see that both are allowed values in apps-schema.json. So, I guess a PR implementing this change would remove one of them, and edit apps.json into compliance.

Thoughts?

P.S. related, but probably deserves its own issue tracker: It would be nice to have hovertext over the element links with a brief description of what they are. Alternatively, a collapsed section of the page could provide a glossary.

dellagustin commented 2 years ago

I'm glad you asked, as I also have been thinking about this. I don't know the original intent behind having both filters (Value and Sat Streaming), but as far as I could find out, Sat Streaming was introduced by @thebells1111 with https://github.com/Podcastindex-org/web-ui/pull/118.

I can offer you my own interpretation: Value means apps (be it hosting, players or anything else) that somehow supports the podcast:value tag (e.g. a hosting service that allows podcasters to define recipients through the value tag, or podcast players that parse this tag, likely to stream sats). Sat Streaming applies specifically to streaming sats, which generally applies only to players. It is unlikely, but it would be possible for instance for a player to first implement Boost/Boostagrams, and later (or never?) to implement Sat Streaming.

In that sense, it makes sense to have both as separate Supported Elements, although that supports my suggestion to replace the term Supported Elements with Supported Features (#147).

Does that make sense to you?

dwvisser commented 2 years ago

That clears things up for me. I assume that if it confused me, then it probably confuses many others. What do you think of adding a glossary or hyperlinks to pages clarifying each of the elements?

dellagustin commented 2 years ago

Some way to clarify what each of the filters mean would be a nice addition.

dellagustin commented 2 years ago

Here is something for inspiration: https://podcasting.github.io/podcasting20/features-showcase/funding/

dwvisser commented 2 years ago

If I can find the time, I'll try to put together a pull request. It ought to be educational.

dwvisser commented 2 years ago

Well, I was able to get a local copy of the site running. Then, I started to research, and I am now realizing more fully how some of the items in the UI under "Supported Elements" are actual XML tags in the specification, while others are UI-level features potentially supported by apps. I.e., "Value" is the element. "Boostagrams" and "Sat Streaming" are not elements per se, but rather are two app features enabled by support of that element. (I know, @dellagustin already explained this to me. Bear with my pedantic repetition. I just want to make sure I'm getting this right.)

Therefore, both Boostagrams and Sat Streaming imply Value. So, I suggest, that when #147 is dealt with, Value should be eliminated from the schema, and in its place, maybe name the others "Value (Boostagrams)" and "Value (SAT Streaming)".

dwvisser commented 2 years ago

Alternatively, I could try to make my suggested schema changes as the PR for this issue. It would bring my desired clarification.

dwvisser commented 2 years ago

I don't understand every single usage of Value in the data file, so I should probable leave a Value (Other) in the schema for those to avoid destroying information.

dellagustin commented 2 years ago

I'm actually fine with how it is now. Value means the app does something with the podcast:value tag (e.g. a hosting service supports that you enter payment recipients, which generates the podcast:value RSS Feed tags). Boostagram and Sat Streaming do indeed imply Value, but I am ok with having them as separate features from Value. I fear that trying to solve this problem too well will mean a complexity for which the cost will outweight the benefit.