Show HN: Booklet – Async forums as an alternative to chat (booklet.group)
I built Booklet to solve the problem of too many chat messages at work.
Booklet updates classic internet forums and email groups to have a modern UI and high polish. It organizes communications into threads, and summarizes activities into a neat email newsletter - so members can stay updated without having to stay logged in. The async format promotes deeper discussions, while also increasing engagement by making conversations easy to follow.
My goal is to make communications more asynchronous - so that I can get back to work, instead of slacking all day. Most early communities have been hobby groups, but my goal is to mature Booklet into a tool that sits alongside Slack in companies.
Try it out, and let me know what you think!
130 comments
[ 2.7 ms ] story [ 309 ms ] threadDefinitely rooting for this to take off.
Based on the launch feedback so far today, I think I need to build a Slack integration - primarily as a separate channel to deliver the daily newsletter. It seems like lots of people don't even open their work email anymore, so the chat + forum need to work together.
I wrote more about why chat fails for work communication in my launch post here - summarized as "our workplace communication looks like the floor of a 1980s stock exchange, not a place for writing code." https://www.contraption.co/news/launching-booklet/
Think of HN here. How many feature requests have they implemented over the last 10 years?
For instance, a few people have requested "pinned posts." I personally don't want the same post stuck at the top of my screen forever, and upon digging in deeper I find that people really want a "Welcome" post that all new users see and can access. So, I'm exploring some ways of accomplishing that without pinning - such as a dismissible post for new members.
I think it's actually horrendous for things you want to use forums for. I don't remember using IRC in lieu of forums (did we?), why do we use Discord for the same?
Discord is really good at sucking you into conversation and capturing your attention/time. Its way better than IRC ever was. But that doesn't mean its a good format for information, issue threads, work discussion and such.
There are thousands of forums that require sign up just to read posts. Always has been.
Something in the middle sounds lovely.
My impression after today's launch is that I need to deliver Booklet's daily summary over Slack, not just email. Would that work better for you?
It’s really a social issue more than a technical one. How to get people to stop playing, “guess which platform I sent you an urgent message on, which nobody else you work with uses to contact you, ever?”
Threading and history I think are necessary for the email thread set.
The irony is not lost on me that Booklet is almost rebuilding email, but for internal-only usage. I think about this a lot.
Was also a terrible move in foresight. :)
1. People are impatient, and chat makes everything urgent
2. Chat make posting easy, so authors post more and with less intentionality
I wrote a long post about this on our blog as I announced Booklet: https://www.contraption.co/news/launching-booklet/
Chat works great for a small group of friends, I don't think it is a good fit for a community
"Do people scroll through the threads?"
Most won't, so the same things and questions get discussed again and again. If the mod is engaged he will create sticky notes, but people also often ignore those. So - yeah, I agree. Not a good fit for a community. They sort of upgrade it though regulary, and now you can have subgroups in groups that can work as forum threads, but I experience it not as a good UX and I regulary delete telegram as it is really hard filtering out useful comments from noise.
I experience it as very slow and bloated, even though it somewhat improved.
Still, compared to a good email client, it’s not so fast. Which is why I personally read Discourse forums mainly via email, only visiting the actual site for long threads or when I want to reply. It’s not perfect, since Discourse allows editing posts but doesn’t notify email users of edits. But it’s fine. I actually like it better than real mailing lists, because I prefer Discourse’s composing interface.
- not hijack my scroll or do that infinite page thing. Please load the entire thread or at least let me use classical pagination.
- not hijack CTRL-f for its own built-in search. I want my browser's on page search, and I know what I'm doing.
Just in case you(or others) don't know, you can press Ctr-F twice to get the native browser page search.
Discourse is definitely not fast. Whenever Google sends me to a discourse page I just end up giving up on waiting for it after staring for over 8 seconds at a blank page.
Can you open up a sandboxed forum so that people don't need to register to try the product out? I think you'll get much higher conversion if people can see what it looks like before they commit to registering.
Yes, communities can be public - check out https://hq.booklet.group which is a public forum where I share updates about booklet.
For something with more data, check out https://demo.booklet.group
I also tried making a little video demo + walkthrough of the product: https://www.youtube.com/watch?v=yf03XsD4pvo
are you getting hugged to death or what?
---
you'll also want to exercise caution leaving user-provided filenames in the URI as that's some pentester funsies: https://bklt-storage.s3.us-east-2.amazonaws.com/p4x0bznob52y...
For the filenames - I'll take a look. I'm using some popular libraries for files, which I hope address things like this.
Funnily enough, I found their root password eventually in a config file. It was "internet" :|
I'm glad you have spent all this energy reinventing ruby on rails based forums, but this is not the way
or, actually, in the spirit of being constructive: what is your experience clicking on those links? does it shows some loading indicator for you? does it load faster than 2 seconds for you?
I do some performance monitoring (using https://skylight.io) and have identified some opportunities for speed-up. I'm working on getting those updated.
I also just resized the database - it seems that some read queries were being slow.
I'm continuing to dig into the postgres settings and indexes to make sure everything is good, too.
--
Update: I'm seeing ~300ms responses on each of those endpoints now in my browser.
There are some moderation tools build in, and some where the API is done but just needs a front end finished.
Which major features do you feel are missing?
Send me an email (Philip at contraption.co) and we can discuss self hosting.
[1] https://element.io/pricing
The lack of a unified backend makes it much harder to build native mobile apps.
That response comes across as disingenuous. The lack of a unified backend makes a lot of monetisation models hard, but should pose zero problems for native mobile apps. Point at an API and done.
Contrast is also low and it's just bad to read. Too many UX people touched it.
Real time editing doesn't seem like a useful feature unless you expect people to keep threads open.
How do other solve this? Based on the reactions here, it seems like hiding the scroll bar may not be the best approach.
Right now it supports a custom brand color, logo, optional separate logo for dark backgrounds, and icon. (There’s some fun code for determining where and how to use the brand color to maintain sufficient color contrast).
If there are missing controls you want let me know!
We’ve apparently already had that discussion though: https://news.ycombinator.com/item?id=22801233
Who said they have to? I doubt many people even care, previous messages are just included recursively by all the major email client apps by default. I suspect most of the people don't even know.
The interesting thing is that if you use a conventional email client that supports actual threading using the Message-Id and In-Reply-To and References header values, and you edit the email message to trim quoted content and reply inline, the conversation view implementation in their email client breaks and it shows a blank message.
I blame conversation view.
Also please make sure it works without javascript, like discourse does. It can be ugly with JS turned off; people who turn off JS don't care about pretty.
I'm being facetious. Take note all ye.
They’re async as in the technical ‘async’, vs. async as in “async communication” (which is what you’re saying).
But the key is that you don’t have to force an update — updates happen in real-time, even edits (they’re pushed). In traditional forums, you’re forced to pull updates.
TLDR: it has the feel of chat, with the structure of forums.
On paper it's a good idea, in practice I found it cumbersome. It requires for people to think a little about how to structure their conversation, and thinking is hard, too hard when you can just send a disorganized group chat.
0: https://zulip.com/help/move-content-to-another-topic
[1] https://getbootstrap.com/
We need people working on open source protocols and tools to make things like this possible with existing protocols and in a secure way, federated/decentralized.
I saw in a comment below what I expected, it already exists LemmyBB!
Have you considered that some people don't see value in the decentralised/federated setup? They want to go to one site, that all there friends go to, without having to play guessing games to ensure that the server they are using is part of the federation that their friend is using.
It's also bad form to call out something just because it is proprietary: Ever used AWS, Azure or GCP products? Why is their "proprietary crap" better than this "proprietary crap"
Your implementation is probably not based on Ruby - which makes it more interesting - but it's not open source. In terms of features, they don't seem to compare at all as this is really early stage.
The idea behind the project is good, and I think this is the future. I successfully pushed the company I work for to use internally a Discourse instance to overcome the same issues you faced - and it works. We now have an "internal StackOverflow" and an engaging community. It's not a new concept (see Google's YAQS), but it's a (IMHO) working one that many more companies should adopt as it really increases knowledge sharing and productivity!
Best of luck with your project, I think you're on the right path but you should definitely start comparing this to Discourse and define why should anyone get this - and why must it be SaaS (some big companies are against SaaS for their stuff).
> <link rel="icon" type="image/png" href="https://delivery.booklet.group/rails/active_storage/represen...">
Also, it doesn't use Ember.js, which is another plus in my book.
[1] https://github.com/superfly/fly-ruby
Also, the custom domain pricing on Render is fairly high - probably due to the Cloudflare custom domain licenses.
That's a valid question - I'm pushing to launch at the "minimum viable" stage. But, I plan to mature Booklet into more of a managed service, intended for invite-only networks and internal company discussions.
Discourse is a great product. However, I know of a couple very large companies that started to use Discourse and even went as far as paying design firms to customize it, only to back out due to challenges. I think a lot of the complexity of Discourse comes from its reputation system - which is designed to prevent spam. But, for an internal company use case - those tools are not useful, and become annoying. Even if there's a way to turn them off, I think it gives the software a clunky feel.
There's something elegant about an "omakase" approach, where companies can use it out of the box.
From the makers of todoist, they made a comms tool for their async remote workflow and then made a SaaS out of it.
In my experience, Twist doesn't get notifications or channels quite right. I haven't used it recently, but I think it was easy to miss discussions.
I'm attempting to solve this issue in Booklet by building a deep email integration. I've talked a lot about the summary email. But, one little feature I haven't discussed much is the following mechanism on threads. When subscribed to a thread, all replies trigger emails, and the emails thread in your inbox like a Google Group. (Post via email is on my to-do list, too). My vision is that people can continue to use Booklet from their email (and, perhaps other tools in the future) without needing to log in to the app.
It seems that the core feature is the AI generated summary. This could be a paid plugin for the most important discussion platforms in the wild, for example: old-school PHP discussion boards, Discord, Slack, Twitter, Facebook and others. This plugin also could offer AI-augmented search or AI logging. The pro: people don't need to leave their platform to profit!
Another idea: Discord seems to be controversial. Some people love it, some people hate it. Instead of a plugin offer a discussion back-end with two frontends, one behaving like Discord, the other like a traditional discussion board.
Or do both. Whatever. One problem I see is missing focus. People might not understand what you do.
I talk in the demo about the 1% rule for users (1% post, 9% like/reply, and 90% just read). I envision each of these three as separate levels of engagement within Booklet:
1. Some users will post and create threads
2. Some users will read the summary email and never get deeper
3. Some users will see a thread in the summary email and get very engaged in that thread (for example, by commenting or following it)
Based on my experience, chat does a good job of #1, a mediocre job of #2, and a terrible job of #3. Specifically - long-running threads lack discoverability or engagement in chat, so people can't modulate their engagement to the topics they care about.
This is why I built discussions from the ground-up, rather than making some Slack plugin.
Another option might be to filter out important discussions and elevate it on a certain (“BB or mailing list worthy”) level - that seems to be a challenge, that the threading function does not sufficiently solve (also, as users don’t always adher to the technical aspect of replying to a thread).
It will be interesting how LLM/AI might solve some of these issues of organizing the knowledge that is generated in these different formats. That’s a task that so far seems to be too tedious to be done by humans, after all. A wiki generated by AI to certain discussions and topics? Summaries in the chat software to certain keywords/discussions and suggestions on further reading?
> In today’s chat-centric environment, there’s a skewed emphasis on the ease of posting. We rarely pause to consider the broader implication: for every message posted, it’s likely to be read 100 times by other people. Yet, we continue to post more and more low-value messages, because it’s easy to do so.
> For the vast 99% majority who are on the receiving end, chat becomes a source of stress. Constant notifications require frequent context shifts. Unstructured discussions make it difficult to follow along. And, the lack of summaries means onlookers are left out of the loop.
> Knowledge work becomes more productive when non-urgent communication gets shifted to an asynchronous format. Thoughtful, long-form communications promote deeper thinking and better decision-making. This insight led Amazon to ban PowerPoint in meetings, and instead require 6-page memos to be read silently at the start of meetings. Programmers have long recognized the efficiency of this approach in their work, utilizing batch processing to have computers efficiently handle repetitive tasks. We need to apply a batching approach to our communication.
Getting the newsletter right, including relevance scoring and summarization, is a really fun opportunity. I am experimenting with some GPT approaches - it's quite really effective at summarization.
[1] https://www.contraption.co/news/launching-booklet/
No JavaScript at all