Hello hello! We are so excited to announce our @lens integration!

Building social apps on decentralized rails just got easier.

Now you can:

⤷ ✨ Integrate Privy with the Lens SDK for seamless profile data access

⤷ ✨ Write directly to Lens using Privy's embedded wallets (or any wallet)

Simply head to our docs to get started and use Privy to read from Lens and mint a profile using your email or wallet.

→ <docs.privy.io/guide/react/recipes/misc/lens>

Major shoutout to @ipaulpro from the Lens community for making this happen 🙇🙏

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.