Comparing Inoreader’s user interface for their internal tweets versus RSS tweets

For a long time I’ve been consuming the majority of my Twitter feed within various feed readers. My most frequent feed reader is Inoreader, though I’ve been experimenting with and using some IndieWeb influenced microsub-based feed readers for quite a while.

Earlier today I thought I’d try out Inoreader’s Twitter integration and subscribe to some of my twitter lists using that instead of importing feeds directly from outside services. (I’ve been a big fan of using Ryan Barrett’s Twitter-Atom and related tools.) One of the things that had always bothered me about third party RSS feeds into most feed readers is that the author of the post is in such tiny text and there is no avatar indicator of who wrote the post. As a result I’m stuck spending a lot more cognitive load trying to discern the author of a tweet before or after reading it. It just boils down to less than optimal user interface.

Fortunately Inoreader seems to have a slightly better method for doing this (since they control the user interface and are presumably using the Twitter API). Within their reader, Tweets look a tad bit more standard with respect to the usual Twitter client and include an avatar and the name of the author in larger font. Sadly, though they have control over the UI, they’re still including a bolded version of the the text of the tweet as a title and thereby needlessly duplicating some of the content. It would be far better for notes, status updates and other content that typically doesn’t have (or need) a title if they would simply just leave it out. They could then use the extra space to have a larger font for reading the short status update. In fact, most of the IndieWeb-based feeds I read in Inoreader have these unnecessary titles included which typically not only look bad from a UI perspective, but they again needlessly duplicate content I don’t need.

Below I’m including screenshots of the two different methods of reading Tweets via Inoreader. I’m also including a screenshot of how Tweets look like in Monocle when fed in via the same Atom feed that was used in the Inoreader case. In Monocle’s version, it’s got a nice larger and easier to discern author name, but it too is missing the author photo (or avatar), in part because the feed doesn’t include it as a default. I suspect that if the feed included it, Monocle would display it properly though the Inoreader version probably wouldn’t. The Monocle version also includes a copy of the photo in the Tweet twice because the feed adds it in a second time as an enclosure.

UI example of a tweet within Inoreader using their native Twitter support.
UI example of a tweet within Inoreader imported using a third party RSS-based client.
UI example of a tweet within Monocle imported using a third party RSS-based client.

For completeness, I’m including the text of the Atom feed for this particular tweet so that we can see what is or isn’t being included in the Inoreader and Monocle versions.

<entry>
<author>
 <activity:object-type>http://activitystrea.ms/schema/1.0/person</activity:object-type>
 <uri>https://twitter.com/BigHistoryPro</uri>
 <name>Big History Project</name>
</author>
    <activity:object-type>http://activitystrea.ms/schema/1.0/note</activity:object-type>
  <id>https://twitter.com/BigHistoryPro/status/1195385992728985600</id>
  <title>In an ideal world, you’d have 1-on-1 time with every student to discuss every...</title>
  <content type="xhtml">
  <div xmlns="http://www.w3.org/1999/xhtml">
In an ideal world, you’d have 1-on-1 time with every student to discuss every aspect of every writing assignment. With BHP score, you come close. <br />
<a href="https://bh-p.co/2N1xopV">bh-p.co/2N1xopV</a>
<p>
<a class="link" href="https://twitter.com/BigHistoryPro/status/1195385992728985600">
<img class="u-photo" src="https://pbs.twimg.com/media/EJbdObjXkAQ6QNw.jpg" alt="" />
</a>
</p>
  </div>
  </content>
  <link rel="alternate" type="text/html" href="https://twitter.com/BigHistoryPro/status/1195385992728985600" />
  <link rel="ostatus:conversation" href="https://twitter.com/BigHistoryPro/status/1195385992728985600" />
      <link rel="ostatus:attention" href="https://bh-p.co/2N1xopV" />
      <link rel="mentioned" href="https://bh-p.co/2N1xopV" />   <activity:verb>http://activitystrea.ms/schema/1.0/post</activity:verb>
  <published>2019-11-15T17:00:04+00:00</published>
  <updated>2019-11-15T17:00:04+00:00</updated>
  <link rel="self" type="application/atom+xml" href="https://twitter.com/BigHistoryPro/status/1195385992728985600" />
      <link rel="enclosure" href="https://pbs.twimg.com/media/EJbdObjXkAQ6QNw.jpg" type="image/jpeg" />
</entry>

In sum, I generally like the UI of the Inoreader version, though they could still do with removing the redundant and unnecessary title. The Monocle version is likely the best, but I’d need to find a feed method that also includes the avatar to have a better representation of the original Tweet. Even with these differences, I think I tend to prefer Monocle at the end of the day because it also automatically includes Micropub functionality which means that I can post my reactions (likes, reposts, or comments) directly to my website and syndicate copies directly to Twitter. (This is also in consideration of my previously having set up some separate functionality for forcing Inoreader to allow me to post some of this same sort of data to my website by other means.)

Has anyone found better/prettier or more useful ways of consuming Twitter in third party means while allowing one to own their data?

Reply to Stephen Downes on microsub readers

Replied to a post by Stephen DownesStephen Downes (downes.ca)
Building an IndieWeb Reader by Aaron Parecki
There's a lot to like in this description (I haven't tried out the actual product) of a reader that in many ways resembles what I'm trying to do with gRSShopper. This is a hard project: "there are a whole bunch of different parts to building a reader, many of which have no overlap in skillset: managing the subscription list, polling and fetching feeds, parsing feeds, data storage, rendering posts in a UI, providing inline action buttons to be able to reply and favorite posts, etc." There are some nice bits, especially the interoperability with Twitter and Github.
Also on Twitter
A WordPress plugin to help facilitate setting up these types of feed readers using Microsub was released yesterday: https://wordpress.org/plugins/aperture/

It’s obviously much more powerful if you’ve got Webmention and Micropub functionality set up too.

An IndieWeb Podcast: Episode 2 “IndieAuth”

Episode 2: IndieAuth

Summary: At long last, after about three weeks worth of work, David Shanske (along with help from Aaron Parecki) has added the ability for the IndieAuth plugin for WordPress to provide an IndieAuth endpoint for self-hosted versions of WordPress, but it also has the ability to provision and revoke tokens.

This week, David Shanske and I discuss IndieAuth and the WordPress plugin’s new functionality as well as some related micropub work David has been doing. To some extent, I alternate between acting innocent and serving as devil’s advocate as we try to tease out some of the subtleties of what IndieAuth is and what it means to the average user. As usual, David does an excellent job of navigating what can be some complicated territory.

 
Huffduff this Episode

Show Notes

Related IndieWeb Wiki Pages

Micropub Apps Mentioned in the episode

Closing discussion on IndieWeb Readers and Microsub Pieces

More Resources

If you need more IndieWeb content, guidance, or even help, an embarrassment of riches can be found on the IndieWeb wiki, including the following resources:

👓 It’s Time For an RSS Revival | Wired

Read It's Time For an RSS Revival (WIRED)
After years of letting algorithms make up our minds for us, the time is right to go back to basics.
This article, which I’ve seen shared almost too widely on the internet since it came out, could almost have been written any time in the past decade really. They did do a somewhat better job of getting quotes from some of the big feed readers’ leaders to help to differentiate their philosophical differences, but there wasn’t much else here. Admittedly they did have a short snippet about Dave Winer’s new feedbase product, which I suspect, in combination with the recent spate of articles about Facebook’s Cambridge Analytica scandal, motivated the article. (By the way, I love OPML as much as anyone could, but feedbase doesn’t even accept the OPML feeds out of my  core WordPress install though most feed readers do, which makes me wonder how successful feedbase might be in the long run without better legacy spec support.)

So what was missing from Wired’s coverage? More details on what has changed in the space in the past several years. There’s been a big movement afoot in the IndieWeb community which has been espousing a simpler and more DRY (don’t repeat yourself) version of feeds using simple semantic microformats markup like h-feed. There’s also been the emergence of JSON feed in the past year which many of the major feed readers already support.

On the front of people leaving Facebook (and their black box algorithmic monster that determines what you read rather than you making an implicit choice), they might have mentioned people who are looking for readers through which they can also use their own domains and websites where they own and maintain their own data for interaction. I’ve written about this in more depth last year: Feed reader revolution.

One of the more bleeding edge developments which I think is going to drastically change the landscape in the coming years for developers, feed readers, and the internet consumption space is the evolving Microsub spec which is being spearheaded by a group of projects known as the Aperture microsub server and the Together and Indigenous clients which already use it. Microsub is going to abstract away many of the technical hurdles that make it far more difficult to build a full-fledged feed reader. I have a feeling it’s going to level a lot of the playing field to allow a Cambrian explosion of readers and social related software to better leverage more easily reading content on the web without relying on third party black box services which people have been learning they cannot fully trust anymore. Aaron Parecki has done an excellent job of laying out some parts of it in Building an IndieWeb Reader as well as in recent episodes of his Percolator microcast. This lower hurdle is going to result in fewer people needing to rely solely on the biggest feed readers like Facebook, Twitter, and Instagram for both consuming content and posting their own content. The easier it becomes for people to use other readers to consume content from almost anywhere on the web, the less a monopoly the social networks will have on our lives.

I truly hope Wired circles around and gives some of these ideas additional follow up coverage in the coming months. They owe it to their readership to expand their coverage from what we all knew five years ago. If they want to go a step or two further, they might compare the web we had 15 years ago to some of the new and emerging open web technologies that are starting to take hold today.