💾 Archived View for space.matthewphillips.info › posts › reader-friendly-browser captured on 2022-06-03 at 22:51:10. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

A Reader Friendly Browser

As a user of the web I spend a lot of my time either disappointed or frustrated with sites I visit. After watching a movie I might hop over to the relevant Fandom page to learn about a character but instead get an irrelevant video taking up the entire screen.

Fandom example

Or maybe I'm looking up a recipe and the page forces me to scroll down for 15 seconds before I actually reach the content. And there's usually an autoplaying video there too.

Example of a bad recipe page

The web is fundamentally broken as a mechanism for reading content. I want to do something about it.

A new protocol

The problems of the web can't be fixed with HTTP and HTML. The ultimate sin of the web is that it puts publishers in control over presentation, which allows them to deprioritize UX (user-experience) in favor of things they care about more, mostly SEO and ad clicks.

That's why we need a new protocol that sheds these fundamental issues the web has. A protocol that combines the user experience of something like an ereader with the openness of the web. Where a publisher could have a direct relationship with their customers, charge them and take all of the profit, but in a way where the customer has guarantees over UX and ownership of the content they purchase.

Previously I would have thought this was too tall of a task, but getting into Gemini changed my opinion here. Creating a new protocol is not as hard as it sounds. Especially if you shed the complexity of the web and focus on content.

Project Gemini

I'll do a separate post on this, but my wishlist of a new protocol includes:

For the user:

Browser support for Markdown, epub, and a variety of other user-friendly formats.
Specialized formats for common things like recipes so that they can be displayed in a consistent and user friendly way.
Themes for formats so that a user can install a recipe theme that they like and use that on every recipe they visit.

For the publisher:

Some easier way to do payment, maybe with the browser facilitating it, to enable microtransactions more easily. This would not substitute for the publisher's ability to do its own credit card processing and retain all of the profit.
User certificates as part of the request, allowing the server to uniquely identify each user (if they opt-in, that is). This is taken from Gemini.

The path

Getting to a new protocol will take some time and I don't want to jump in just quite yet. It will take some experimentation and talking to publishers about what they need in order to strike the right balance.

So the first step is to build a browser that works on the existing web and upgrades the content. You can follow along as I explore this part of the idea in this Twitter thread:

Twitter thread

The idea here is to extract the relevant content from existing web pages. For recipes you can use the JSON-LD that most recipe pages already provide, for SEO reasons.

JSON-LD site

For articles there are many article extraction libraries. For things like navigation pages it will be trickier. Coming up with a format that works well with all navigation type pages (think homepages on news sites) might be impossible.

The idea here is to inform what is needed for the protocol. The ultimate goal is an ereader like experience in an open protocol using open browsers. Allowing publishers to break free of the ereader store model and the web's ad driven model into something where they retain control of the content and user relationship while handling over UX to the browser (the user agent) which can provide a more consistent experience to users.

This is not an easy task and I might fail. I'd prefer to fail trying to build something worthwhile than to give up and double-down on an unfixable platform like the web.

"We do these things not because they are easy but because they are hard." John F. Kennedy, September 12, 1962.