Frames Kinda Suck (But They Don’t Have To)

It’s cool to see Lens Frames being supported by more apps, but I fear that the hype around Frames has passed, and now we’re stuck in the trough with a user experience that kind of sucks.

The Good

Frames allow for some interesting use cases, effectively turning links into interactive mini-apps. This is especially interesting when combined with onchain activity, like using Open Actions, and passive games.

Frames are built on the Open Graph meta tags system. This is something you’ve likely seen in many social apps — it’s those website preview images that are automatically shown when a post or message contains a link. Frames extend that format to allow for actual interactions; essentially adding buttons to those link embeds.

There are many benefits to supporting Frames, like reducing the need to leave the feed, associating the interactions with a user’s social graph, and removing some friction of interacting directly with smart contracts.

The Bad

The problem is they’re really slow to use and generally have poor UX design. Frames break most best practices when it comes to web design. A Frame can show up to four buttons and a single input field. These buttons have no visual indication of their importance, danger, or relevance to the content. They’re generally visually identical. The input fields aren’t capable of providing basic niceties that you’ve come to expect, like autocomplete, validation, and suggestions.

There’s no concept of navigation or history in Frames. You can’t simply go “back” to see a previous Frame, or refresh the current Frame unless one (or more) of the 4 buttons is dedicated to navigation. This breaks typical expectations in using web interfaces and forces the Frame to use the limited real estate for adding basic functions.

One of the biggest issues with Open Graph tags, in general, is that most apps download the entire HTML document, then parse for the tags. This can be fairly slow and is terribly inefficient. For instance, just the HTML for a single YouTube video page is close to a 1MB download. Add a few of those to a feed and their impact becomes noticeable. For this reason, apps typically cache Open Graph tags to cut down the load times. Unfortunately, caching isn’t always possible with Frames because the images are often dynamic.

Another huge limitation for Frames is the necessity to present the UI as an image. This is terrible for accessibility, an inefficient use of resources, and reminds me of the worst aspects of the Flash days.

The Solutions

For starters, Frame UIs should have built-in navigation and history stack. It shouldn’t be up to the Frame to provide basic affordances like “back” and “refresh”.

Frame buttons should allow for classification and denoting importance. Dangerous actions shouldn’t look the same as safe ones, and primary actions shouldn’t look the same as secondary or tertiary actions.

Apps that show Frames should use “streaming” to download only the header of an HTML document, rather than downloading the entire thing and then parsing. This is a basic feature supported by the standard Javascript library for making web calls (fetch). In my limited testing it’s 5 - 10x faster.

Lastly, we need UI kits that standardize the way UIs are built in Frame images, and standards for accessibility so things like screen readers work with Frames. This would make it much easier for developers to present interfaces in a way that is familiar and expected.

Something needs to be done about the bots.

It’s getting out of control, and this is with the “high signal” notification filter enabled. I’ve received about a dozen more just while writing this post.

What’s worse is that there’s no way to stop this because blocking doesn’t actually prevent you from getting notifications when tagged by a blocked user. If we don’t figure this out soon, Lens will die. I’m very close to ignoring notifications altogether because the signal to noise ratio is easily 1:100.

Note: if you’re unable to comment on this post it’s because the app you’re using doesn’t properly handle the “friends of friends” setting. This is the only thing I can do to stop the bot mirrors and comments.

Collect fees are too high!

You might not realize, but there are significant fees associated with Lens Collects. Depending on the apps you use, there may be up to 15% in fees for each Collect! Let’s break down where the fees are coming from, and how you can avoid most of them.

🌿 Lens Protocol automatically attaches a 5% fee to all Collects. This is deducted from the sale price and the tokens are held by the protocol treasury, where they will eventually be split amongst the apps used to publish and collect. You cannot avoid this fee.

⭕️ Orb adds an additional 5% on the buyer side. When someone Collects on Orb, they charge the buyer 5% on top of the sale price.

🌸 Hey adds an additional 5% revenue split. When you create a collectible post on Hey, you automatically split 5% of your revenue directly with Hey. This is deducted from the sale price on top of the protocol fee.

So if you create a collectible post on Hey, and someone Collects it on Orb, there was effectively ~15% in fees paid out. Frankly, this is ridiculous. 15% is almost an order of magnitude higher than the fees you pay elsewhere in Web3 (OpenSea: 2%, Magic Eden: 2%, Blur: 0%). Reminder that the 5% protocol fee will eventually be split with the apps, so any charges on top of it are essentially double-dipping.

How do you avoid these crazy fees? Simple: don’t create your collectible posts on Hey, and don’t collect posts on Orb. That’s it! There are no added fees when collecting from Hey, and no automatic split added when posting from @focalize, for example.

Other apps with high additional split fee on collects: Tape 5%, BloomersTV 5%. Orb is the only app, that I’m aware of, that adds fees on the buyer side.

I might make a website that breaks down all of this stuff. Essentially a “ranking” for Lens apps on how open and decentralized they are, what fees they’re adding, etc.