Leaflet R&D idea bucket
This is where we collect & digest ideas as you all test the app!
Hit us with any thoughts by email and we'll think out loud here about what we're exploring!
R&D mailbox!
Drop your email here for updates when we add new posts ✨
older posts
the pre-mailbox archives :) see above for new posts
Trading off Jank vs. Joy
Brendan, 7.19.24
One thing we're coming to believe pretty strongly is that it's worth leaving some rough edges in order to focus more on things that are new, unique, exciting, fun…i.e. delightful!
Trading off Jank vs. Joy
Brendan, 7.19.24
One thing we're coming to believe pretty strongly is that it's worth leaving some rough edges in order to focus more on things that are new, unique, exciting, fun…i.e. delightful!
Things on our list that are useful and expected, but also not very exciting or differentiated, and are a lot of work, include: really solid cut/copy/paste, and undo/redo support throughout the app.
We're okay getting to these a bit later. For now, we want to prioritize shipping things that concretely make the app more expressive — like drag and drop for blocks, nice list / outliner handling, and new block / page types.
Not having undo can be annoying, but not being able to move things around the page is more of an actual blocker to expressive use.
It's a balance; we do want to fix glaring bugs and make the current features of the app work well. This means shipping fewer features and being very intentional about those we add, as well as mitigating papercuts or confusion by being clear about the app's alpha status.
One we do want to add soon is a doc homepage, where you can see your recent docs. It's not strictly essential, but helps with concerns around losing docs, and makes it more fast and seamless to find and switch between them…which feels important!
This is also why we put in non-essential but fun and distinctive things, large (theming! multi-page docs!) and small (custom highlight colors, pretty link previews, themed favicons!) right from the start :)
What are Leaflets (Good) For?
Brendan, 7.22.24
We want Leaflet to be flexible, good for a range of expressive uses.
What are Leaflets (Good) For?
Brendan, 7.22.24
We want Leaflet to be flexible, good for a range of expressive uses.
We also want it to compare well with other apps — but it's important to keep in mind we're not going for full feature parity with [insert complex app that's been around for many years here]!
So far, it seems like vibes are key — Leaflet doesn't need every feature under the sun if it's fast, expressive, and fun to use.
How are people actually using it and describing how it feels? So far we've heard that Leaflet feels good for:
- quick light simple shared docs
- low-friction mobile creation and editing
- living / WIP / unfinished documents
- collections, especially visual link collections
Particular things that make it feel fun and unique include multiple pages, nice link / page previews, easy custom theming, and solid image support.
If Leaflet can be great for things like public collections, wikis, or shared notes, it's okay if it's less ideal for use cases that require the long tail of document power features, like tracking changes or inline tables. For now, plenty of room to win on other dimensions.
Poking at programmability
Jared, 7.28.24
One direction we've been thinking about for the future of leaflet is programmability. What if you could write code to make your documents come alive?
Poking at programmability
Jared, 7.28.24
One direction we've been thinking about for the future of leaflet is programmability. What if you could write code to make your documents come alive?
There would be three APIs:
Reading: An API to query for the contents of docs
Writing: An API to add/edit/delete blocks from documents
Reacting: An API to register hooks that get called when things happen in a doc
We have some loose ideas for things we could build with these. One broad category is input/output. You could write a script to pull data into a leaflet from an outside source, or one that takes the content of your leaflet and dumps it as files on your computer.
Or you could write up a whole word game, having a section your doc controlled by code and another section for submitting input. You could have some kind of shortcut for executing code inline and replacing it with the output. Or perhaps even implement things like a comment section or a full fledged forum.
Honestly the fun part here is that we can't fully anticipate what you could build with this. The goal would be to make something extremely fun to iterate with, so you can set up the integration and then just see where it takes you.
But the way our current web apps are structured makes them tricky to program. Their permissions model is built around teams, admins, and organizations. Here, we could do API access the leaflet way, scoped to individual documents, simple, lightweight, and still pretty powerful.
Proposal for Mailboxes, AKA Subscribables
Celine, 7.31.24
The next direction for Leaflet should NOT focus on how we can make it a better doc.
Proposal for Mailboxes, AKA Subscribables
Celine, 7.31.24
The next direction for Leaflet should NOT focus on how we can make it a better doc.
Instead, we should focus on using docs as a medium to give people new, more malleable abilities online! Ways to do something new — but simple and tangible — with the internet itself!
Features that would make for better docs, but don't lend users building blocks to make something completely new and unachievable elsewhere. They are compelling, and can help make a social interaction richer, but in and of themselves don't unlock enough:
Canvas or Collections
Comments
More block media types (video, sound, etc)
Features that allow users to orchestrate new social experiences on the internet!
Mailboxes (or "subscribables")
Block-level granular roles and permissioning
API access
Maybe annotations belong here…
I am excited about Roles and Permissions. In conjunction with APIs or input blocks, we could make some really interesting spaces / scenes / games with this. But right now, with what we have, the use case looks too narrow. It seems like an over-optimization for a problem that not THAT many people grumble about. And it would really only be handy for the select few making things like worksheets. I believe that one day it'll be powerful, but there's just not enough there for it to synergize with just yet.
I'm also really excited about Annotations. It could open a lot of new options for use cases and make our doc more interactive in a lot of creative ways. But it's a really heavy set of tools. It'll add a lot of complexity to our UI. We don't quite have enough direction to know what sorts of features we need to support in Annotations, and it seems risky to add a bunch of complexity without much certainty.
I think our best shot is Mailboxes. It's a pretty simple / lightweight addition to our UI (just a button and a little update input) but it will unlock so many new possibilities, not just within Leaflet, but on the internet in general.The three big buckets I can imagine:
A simple and scoped way of organizing something with a constant stream of announcements, like events
An very easy, fast, lightweight way to send regular or semi regular updates, like a newsletter or a progress log
A way to collaborate async by notifying people of jobs to be done, events upcoming, or tasks that have been completed
We can provide creators with something better than existing options.
Ideas for custom blocks
Brendan, 8.12.24
Jared has been exploring ideas for programmability in the context of blocks that can execute code and render custom components. I got excited about the possibilities and wrote up a list of things this could enable in Leaflet. Here's a summary!
Ideas for custom blocks
Brendan, 8.12.24
Jared has been exploring ideas for programmability in the context of blocks that can execute code and render custom components. I got excited about the possibilities and wrote up a list of things this could enable in Leaflet. Here's a summary!
Leaving aside more complex possibilities for custom code that could affect a doc in more global ways, I think customizable blocks could help enable a number of interesting feature requests we've gotten:
image flexibility: resizing or otherwise editing images, e.g. applying filters or themes
formatting: things like custom divider blocks, or multi-column text within a page
custom nav: e.g. adding a table of contents for a book, syllabus, or link in bio site
embeds: for audio, video, maps, and more
simple annotations: we're exploring how to make this a built-in feature, but maybe we could prototype with custom blocks
And all kinds of other things that'd be fun!
ad hoc layout engine: render existing block types differently, e.g. display link collections in a grid or images as a lightboxed album; or hide card borders, or make blocks display with offsets and rotation to look more collage-like…etc.!
emphasis + organization: define new ways to visually highlight parts of a doc, like "to do" vs. "done" sections in a list
custom actions: e.g. buttons to duplicate a block as a template, or to export a document's data
contextual formatting: could each user's blocks render differently based on a per-device cookie? could link blocks render differently based on the source url?
interactive workbooks: create a simple form builder that sends data to sub-pages; maybe even a way to "submit" and send an update using mailboxes
I think this can be a great foundation for making docs feel more personal, custom, and extensible. It's an easy to understand starting point but can potentially go in lots of directions, from reactivity to a more global doc API to reusable template blocks.