Aaron responded to my ramble:
One of the main reasons to use h-feed and h-entry is that RSS/Atom really only can represent blog posts and podcasts. For those purposes, they’re fine formats, but the reality is there are many more kinds of content on the social web today, such as replies like this one which can’t really be represented in RSS.
That’s absolutely fair! I’ve found RSS/Atom to be Good Enough for everything I’ve wanted to support in it, but in a lot of the use cases it’s definitely on the end of “Hey I have new content, come to my site to consume it properly.” I haven’t really seen any example of h-feed handling those better, though. Do you have some examples that I could look at?
What features are you finding that Microsub doesn’t support? Like most of the IndieWeb protocols, Microsub is supposed to be an evolving protocol based on the needs and implementations of people using it. I don’t expect that we will ever say “Microsub is done!” the way that some specs put a stick in the ground, since the reality is that things change and need to adapt to new use cases to remain relevant.
The main features that feel like they’re missing are organizational facets, like what we were discussing earlier today. Having some mechanism to more easily recategorize feeds, or entries within feeds, or whatever. I know that most of that probably falls on the endpoint itself and shouldn’t be part of the Microsub protocol though. It’s hard to know where to draw the line.
Another thing that feels like it’s missing is a user story. It’s just confusing to get started with. I set up various endpoints (adding a token endpoint and a microsub endpoint to my main page, which doesn’t feel like it should be necessary to use an external piece of software that has nothing to do with my site), and then when I did get things going, I found that the UX of the readers was… underwhelming, I guess. And it isn’t clear to me how much of that is on the readers and how much is on Microsub itself. It sort of feels like there’s two parts to the experience which each keep on saying that no, it’s the other part’s responsibility to do things.
Most of the UX I see emerging is based on doing something Twitter/Tweetdeck-esque and I want something more like an email inbox with folders/filters. (Thus the issues I opened earlier today, and thanks for your comments on #40 in particular!)
It’s definitely an evolving spec and I appreciate that about it, but it just feels really difficult for me to even get started with it right now because I don’t feel like the goals that the various folks implementing the tools are aligned with the goals I have in using a feed reader right now.
I do appreciate the idea of it being built in the form of building blocks with interoperability, but the way that the blocks are currently connected just feels confusing and overwhelming and doesn’t feel like it’s particularly advantageous to having a single reader-with-subscriptions.
I guess, mostly, as a user I feel lost, and as a developer I feel like it’s overly-abstracted.
I’d love to see the ability to do some sort of scriptable hook into a feed where I run my own filter that does things the way I want them. One of the things I tangentially got at in issue #40 is I’d love to have a way of registering a webhook that gets a notification when an item comes in, and then says where to put the item. Like, give me a JSON blob that gives all of the parsed semantics and let me return a disposition of which channel (or group or whatever) it should go in. And make sure it provides all the data in some easily-processed form.
That probably belongs in the configuration UI of the Microsub endpoint, though, rather than needing to be a core feature of Microsub itself. But I’m not seeing any endpoints that are trying to implement stuff like that. Not that I’ve looked very hard, though, because there’s just a huge collection of things to look at and none of them really tell me why I should look at them vs. any other endpoint implementation. And meanwhile I feel like there’s a missing link for actually being able to transport data between them. I couldn’t find any working (or documented-enough for me to use) examples of an OPML importer or exporter, for example, which made me skittish about even trying any endpoint out enough to see if it would really work for me.
I’d love to see a concept of nested channels, too. So I can have a channel for all art stuff, and subcategories for drawings vs. photography or whatever. Or being able to have subchannels for each of the separate comics I follow, all grouped together under “comics,” which would handle the use case of wanting to do an archive binge on a single series vs. wanting to catch up on what’s new in the last day. Even with a flat channel structure it’d be nice to be able to just, like, focus on one feed sometimes, without having to always focus on only that feed. And then having something where I can see all my subscription content, but not the “follow” content, per the distinction I raised the other day, so just having a “show all” view isn’t quite what I’m looking for.
Also it took me a while to understand what’s meant by the channel order; I was looking for a means of giving the sort order of the items within a channel (oldest-first, newest-first, latest-arriving first) rather than just how to organize one’s sidebar in their reader. Which also feels like it’s tied to a specific UX concept, rather than something intended as a building-block for a more general reader experience.
At this point I feel like I’m talking in circles or something. I’m looking forward to trying to get on the same page this coming weekend. :)
