Sadly the general concept presented here, while it sounds potentially useful, is far too little and misdirected. Hopefully better potential solutions are still not too late.
First, let’s step back a moment. The bigger problem with feeds was that website designers and developers spent far too long in the format wars between RSS and Atom while the social media giants focused on cleaner and easier UI. This allowed the social silos to dramatically close the gap in functionality and usability. While website owners were spending time on formats and writing long articles about what RSS was, how it worked, and how to use it, the public lost interest. We need something really dramatic to regain this ground and
/feeds just is not going to cut it.
The first problem I see with this is that on it’s face
/feeds both looks and sounds like code. No user really wants to interact with code if they don’t have to. Why not simply have a page or button called something much more user friendly like “subscribe” or “follow”? Almost every major social silo has a common pattern like this and has a simple “follow” button on every user’s page. A quick click and one is done with the transaction!
Instead the solution offered here is to have not only yet-another-page but one that needs to be maintained. (As good as the /now idea may seem, the fact that it needs to be regularly and manually updated makes it a failure out of the gate. I’ll bet that less than half the /now pages out there have been updated in the last 6 months. I know mine hasn’t.) Worse, suppose I click over to a
/feeds page, as an average person I’m still stuck with the additional burden of knowing or learning about what a feed reader is, why I’d need or want one, and then knowing what RSS is and how I might use that. I might see a one click option for Twitter or Mastodon, but then I’m a mile away from your website and unlikely to see you again in the noise of my Twitter feed which has many other lurking problems.
One of the best solutions I’ve seen in the past few years is that posited by SubToMe.com which provides a single, customizable, and universal follow button. One click and it automatically finds the feeds hidden in the page’s code and presents me with one or more options for following it in a feed reader. Once I’ve chosen a reader, it remembers my choice and makes the following pattern easier in future transactions. This is a far superior option over
/feeds because it takes away a huge amount of cognitive burden for the user. As a developer, I’ve got a browser bookmarklet that provides this functionality for sites that don’t provide it for me. How nice would it be if browsers went back and offered such a one button collection mechanism?
Want to give this a try? I’ve got a “Follow Me” button in the side bar of my website. And if that doesn’t float your boat, I’ve tinkered with other methods of subscribing to my content that you can find at my subscribe page. Some developers might not be too scared of what’s on my subscribe page (a
/feed page by a slightly friendlier name), but less technically minded people are sure to have a dramatically different perspective.
The other piece here that I might take umbrage with is the offering to provide feeds to subscriptions to alternate services like Twitter and Mastodon. (This doesn’t take into any account that RSS feeds of social services are positively atrocious, not to mention that attempting to access Marcus’ Twitter feed in RSS Box returns the interminable error message: “There was a problem talking to Twitter. Please try again in a moment.”)
Ideally I see a future in which every person has the ability to own both their own domain name and their content in a simple manner. If this happens and it’s easier to subscribe to the sites of my friends, then I don’t need corporate social media to intermediate the transactions on my behalf. I also don’t need them to intermediate what I’m actually seeing with their blackbox algorithmic feeds either. Friends, family, and colleagues could simply come to my website and subscribe to all or portions of my content in which they’re interested. While I still presently syndicate some of my content to silos like Twitter and Mastodon for the ease of friends or family who don’t know about the technical side of potential solutions, I post everything on my website first where one can subscribe in a feed reader or by email. Subscriptions in Twitter or Mastodon, while nice to have, are just a poor simulacrum of the real things being served by my site in better ways with more context and a design that better reflects what I’d like to portray online. A
/feed page is going to be a failure from the start if you’re going to cede all the subsequent power directly to Twitter, Mastodon, and others anyway.
While I like the volume of the reactions to the post (indicating that there’s not only a readership, but a desire for this sort of functionality), I’m disheartened that so many designers and developers think that the idea of
/feeds is “enough” to stem the tide.
For those who might be truly interested in designing our way out of this problem, I’d recommend looking at some of the design and development work of the IndieWeb community which is trying (slowly, but surely) to improve these sorts of technical hurdles. Their wiki has large number of examples of things that do and don’t work, discussion of where problems lie, and a community conversing about how to potentially make them better through actual examples of things that are currently working on peoples’ websites.
A good example of this is the increasing improvement of social readers that allow one to subscribe to a variety of sources in a reader which also allows one to respond to posts in-line and then own that content on one’s website. If I can subscribe to almost anything out there in one interface and sort and filter it in any way I’d like, that’s far better than having twenty different feed readers named Facebook, Twitter, LinkedIn, Instagram, Soundcloud, etc. which I have to separately and independent manage and check. Now I’ve yet to see an IndieWeb reader with a one click SubToMe-type of solution for adding feeds to it, but I don’t think it will be very long before that’s a reality. The slowly improving Microsub spec that splits some of the heavy lifting needed to build and design a stand alone feed reader is certainly helping to make some massive headway on these issues.
Maybe we’ll soon have an easy way for people to post who they’re following on their own websites, and their readers will be able to read or parse those pages and aggregate those followed posts directly into a nice reading interface? Maybe someone will figure out a way to redesign or re-imagine the old blogroll? Maybe we’ll leverage the idea of OPML subscriptions so that a personal blogroll (maybe we rename this something friendlier like a following page or personal recommendations, subscriptions, etc.) can feed a person’s subscriptions into their social reader? There are certainly a lot of solid ideas being experimented on and in actual use out there.
We obviously still have a long way to go to make things better and more usable, not only for ourselves as designers and developers, but for the coding averse. I feel like there’s already a flourishing space out there doing this that’s miles ahead of solutions like
/feeds. Why don’t we start at that point and then move forward?
I imagine that header-menu belongs in the
While some of these ideas sound romantic at present with minimal penetration and implementation, we’ll definitely need to be cognizant of how they grow and building tools to mitigate abuses in the future as they become more common. No one wants Webmention to become a vector for spam and harassment the way it’s poorly designed and implemented predecessors like Pingback or Trackbacks were.
While the IndieWeb seems to be the largest hub of this conversation so far, especially for the technical portions, it’s also been distributed across multiple platforms and personal websites and wikis. If you haven’t come across the IndieWeb you may appreciate their wiki and bridged chat channels.
Lately I’ve noticed a big spillover into the wiki space primarily by way of Tom Critchlow, Kicks Condor, some from TiddlyWiki and the Roam Research spaces, and many of your colleagues at egghead.io. I’m personally looking forward to the convergence of the website, blog, personal wiki, commonplace book, etc. in a single platform.
As I notice that you’re in Brighton, if you haven’t been before, you might consider joining in one of the local Homebrew Website clubs either there, in other parts of the UK, or across the world. I see events for Nottingham and London coming up on the schedule, but I’m sure Jeremy Keith or other organizers will do another in Brighton soon.
In any case, you’re on the web, and we can “see” and “hear” you. Thanks for drawing up a campfire to create a discussion.
As a bit of prior art, consider the (originally) open API that Twitter provided that created an efflorescence of Twitter clients one could use to post to Twitter. Obviously those were a bit simpler since they only involved 140 characters of text, URLs, and maybe photos or geo-coordinates. While Twitter eventually cut off the API, the concept was a strong one and the competition provided by the wealth of options, including paid options, made creating posting interfaces or editors an easy option for a variety of developers. Remember the thousands of WordPress plugins in the WordPress repository alone? (Sadly, Twitter turned off this API and all the lovely posting clients for Twitter either died or were bought up by Twitter and look where we are now.)
Several years ago the IndieWeb community took the openness of this model to heart and created the W3C recommended Micropub spec. It’s essentially an open API that dis-intermediates the CMS/publishing platform from the editor interface using a client/server model. It also has the benefit of allowing developers to create incredibly highly customized publishing interfaces. You can now use a full article editor like Quill which provides a Medium.com-like interface, but you can also use something supremely simple like Teacup (even from your watch!) to quickly post what your drinking/eating (along with a timestamp and optional location) to your website.
As a result of this development and the fact that there’s already a Micropub endpoint implemented for WordPress as a plugin, you can try several dozen editors and posting clients out today! And why not try them on other platforms like Drupal, Known, Craft, Jekyll, Kirby, Hugo, and Blot to name a few.
The added benefit is that designers and developers can create either very simple interfaces for posting custom things (maybe you want to post the book you’re reading with indiebookclub.biz to your website in a GoodReads or LibraryThing sort of way) or they can create interfaces for posting almost anything (our Quill example). Interface modalities can also be dramatically different. They could be stand-alone applications on PC/MacOS/Linux, web applications, mobile applications, or as simple as a browser extension (Omnibear for Chrome or Firefox is a great example of this).
For several months now, I’ve been using several social media sites to publish their data to my website using their RSS feeds via IFTTT/Zapier to Webhooks that post to my Micropub endpoint. There’s nothing better than owning all your data, right?
Maybe you want to go all in on the social media side of life? What’s to keep feed readers from building in these Micropub posting interfaces? Then you could read posts in something like the WordPress.com reader, type your reply or response directly into the reader and use Micropub to post it to your website and also cross-post it to social media? (Incidentally there are a handful of social readers that do this already!)
I hear UI complaints by people all the time at camps… If you’re a dev shop interested in paring down the editor interface for a non-tech-savvy client, then customize a Micropub client to post only the minimum requirements and let the WordPress CMS and theme take care of the rest for them! In fact, perhaps there’s a market for white-listed or even branded posting interfaces?
Now that we’ve fixed the root problem without tons of engineering time, all WordPress really needs to do is to create a Micropub client out of Gutenberg, and all those hours of work and engineering on that one posting interface could allow it to be a client to not only post to WordPress, but to Drupal sites, WithKnown sites, and any of the other dozens of platforms that already support the spec.
I mentioned it the other day, on my own website and on Twitter, if Iceberg were to implement their editor as a Micropub client, then their users could use it not only for WordPress, but other CMS platforms could use it as well.
Looking at @useiceberg and thinking how cool it would be if there were an app version that I could log into that had Micropub support so I could use it to publish to any of a handful of CMSes and not just WordPress. https://t.co/fAwIiBp31s — Chris Aldrich (@ChrisAldrich) May 22, 2020
What if a user got tired of using and maintaining their current CMS and wanted to move to another easier or faster one? They don’t have to dump the beautiful editor interface and workflow they’ve become accustomed to, they can just move to anything else that has a Micropub endpoint and take their editor with them. (Think about how you can take most text editors with you if you moved from PC, MacOS, or Linux. Why shouldn’t the same be true if you changed CMS? It’s all just data, right?!)
A great example of just this potential came out in the last week. The 9 year old iA Writer just added Micropub support. It’s a markdown writing app that supports publishing to WordPress, Medium, and Ghost. With Micropub support it can now be used to publish to dozens of additional CMSs and services like Micro.blog. While it’s available on Mac/iOS devices at the moment, I can’t wait for them to add the support for Windows and Android devices shortly as well.
Or what if Medium.com pivoted (maybe for the last time?) and made itself a Micropub client? Then it could be the billionaire’s typewriter that we’ve all been hoping for? And it would have the benefit of being able to post to multiple CMSs.
There are so many possibilities for such an open ecosystem. But, please, let’s not just build something that only works with WordPress API. Do we need another API that will make it harder for editor designers and developers to support each and every quirky, ever-changing snowflake API out there?
Want some more overview and some demos? I did a WordCamp session on the topic last year.
I often pull my own annotations to my personal website similar to your own Memex and publish them there (example: https://boffosocko.com/kind/annotation/)
Incidentally you can also annotate documents stored locally on your computer, but viewed through a browser as well as collaboratively annotating with others.
Some of what I’ve been looking at relates back to the renaissance ideas of the commonplace book as well as memory techniques dating back to ancient Greece and even further back. There are ideas like wikis (personal as well as public–Audrey references a great post by Mike Caulfield in her article) and online notebooks tools like Evernote, OneNote, TiddlyWiki, Roam Research, etc. If a student could quickly add all their highlights/annotations into their website, online notebook, Zettelkasten, or other related learning tools, then they could use them for reading, reviewing, or even spaced repetition as provided by platforms like Anki, Mnemosyne, or NeuraCache.
Going back to Jeremy’s original question though:
Ok, so is hypothes.is doing this? How can it?
Hypothesis could immediate do this and quite effectively if it supported the W3C recommended Micropub spec. In short, it’s a standard and open source method for publishing data to a broad spectrum of surfaces so that developers don’t need to build custom solutions for each of thousands of snowflake platforms.
That is, in addition to its current functionality, you could add some code to make Hypothesis a Micropub client!
The quickest and most flexible approach I might suggest would be to allow users to publish their annotations/highlights not only to their accounts, but have UI to trigger a micropub request to their website, online notebook, or other platform.
There’s nothing more I’d want than an easy way to own all the data I’m collecting with Hypothesis and Micropub could quickly add it for a wide variety of set ups and systems. There are already implementations of Micropub servers for a variety of CMS software including WordPress, Drupal, Known, Craft, Jekyll, Kirby, Hugo, Blot, and Micro.blog with others being added, including Grav. Some of us are actively working on adding it to Wiki-related software as well. Since large portions of the Domain of One’s Own movement are built on these handful, you’d have some pretty quick coverage of not only all this space but even more.
I suspect your dev team could build an implementation in just a few days and it would open up a huge advantage for allowing users to more easily own their H related data on their own websites or in other online locations (while still utilizing the Hypothesis platform for more complex functionality).
There’s some solid documentation and a wealth of open source clients you could look at or borrow code from as well as a test suite. I suspect the IndieWeb Dev chat channel would surface a few additional developers to answer questions about any other issues as they crop up.
If you’d like a quick 5-10 minute demo of how this works for a handful of other clients in conjunction with something like WordPress, I’m happy to volunteer the time and spitball some potential ways Hypothesis could dovetail it and leverage its power.
Outline for a Hypothes.is Crash Course
I often find examples to be most immediately helpful. You might look at Literacy, Equity + Remarkable Notes = LEARN: Marginal Syllabus 2018-19 which has some solid multimedia resources around a group of educators annotating. It’s not only an interesting public example, but will introduce you to some helpful people in the space.
For a “textbook” example, I believe American Yawp may be one of the most annotated textbooks online.
I Annotate 2019 was an interesting conference and Hypothes.is has kindly aggregated videos of all(?) the talks. You can skim through some to find applications relevant to your interests. In addition to this example, the H blog is also a great resource for other examples and news.
More specific to your initial question, you’ve got a lot of options. You can open .pdfs on your local machine and annotate via Hypothesis, but if it’s for a bigger group, hosting it somewhere on the web that is easily accessible may be best. Hypothesis has also made some significant leaps for integrating their product into LMSes recently which also helps in seamlessly making accounts for new users.
Once it’s available to the group, you may want to decide whether you want the group to annotate in the public channel or if you want to annotate in a smaller private group.
Most importantly, explore. Have fun. There are lots of off-label uses you’ll run across using the tool as you play around.
Sadly, it seems like too many in the thread completely got lost on the “why” portion which was the best part of the question.
The best “modern” way would be to create a Micropub endpoint and then you can use some of the excellent multi-platform Micropub clients like Quill, Omnibear, Micropublish.net, etc. The benefit of this is that you get way more than just bookmarks.
I don’t know if anyone has set one up to work with Eleventy or Netlify, but there is some prior art for other static site generators.
The low brow solution may be to take the route I took with TiddlyWiki, but that includes some cutting and pasting, so it may be helpful, but isn’t a completely automatic solution. You’ll note there’s a reply at the bottom of the post that modified my code for use with Roam Research which also includes code for browser extensions as well.
If you want to go crazy with some .php, there’s Parse This code for a plugin for WordPress that might be co-opted. It will parse a variety of pages for microformats, JSON-LD, schema, OGP, etc. to return rich data on a huge variety of websites to give you lots of metadata to create a bookmark, but this may be over and above anything you might want. I use it as a built-in product in the Post Kinds Plugin for WordPress to create a wide variety of post types for reply contexts.