Hacker News Reader

Comment by philip1209 | Hacker News Reader

I'm tired of constant chatting.

Slack encourages quick, stream-of-consciousness, short responses. Plus, it's hard to find past discussion, and it's hard to jump in after being gone for a few days (or, even a few hours).

Threads are absolutely the answer. But, the defaults matter - Slack isn't encouraging threaded, long-form messages. Instead, it makes all messages feel urgent - and it makes the cost of sending a message way too cheap.

I'm on a mission to bring back forums, where threading is the default. Inspired by YC's Bookface software, I'm working on a project to make forums as slick as Slack or Notion [1]. I think that long-form discussions and slow notifications are the key to bringing sanity back to discussions. And, I think the key is one amazing email summary per day - and few (if any) other notifications.

If you're interested in this problem - please reach out!

[1] https://booklet.group

View on HN

My friend works at a company that -- on orders from legal -- has set a 5-day "disappearing messages" policy for all of the corp Slack. Unfortunately nearly all technical discussions happen on Slack. He tells me that it's not unusual for messages to start disappearing before the issue being worked on has even been resolved, and everyone has to re-ask the same questions and re-post the answers at that point, and sometimes things slip through the cracks. Then there's no way for people joining the company to get answers to already-asked-and-answered questions, and they end up spamming everyone on various channels with frequently-asked questions that often go ignored because people are tired of re-posting the same answers over and over again.

This seems like a very simple problem to solve - the issue owner should move important discussions to somewhere that isn't Slack. Writing a summary (or just cut and paste from the Slack messages) into a Jira or Github issue comment isn't much effort, and reading a summary of a problem is a lot easier for new people.

This actually highlights a problem of Slack. Reading an old Slack conversation is massively inefficient, especially if people have chimed in with irrevelevant stuff. Taking what you learn from a Slack conversation and using it to update proper docs or an issue is far better for anyone who isn't part of that conversation at the time.

The problem here isn’t Slack. Clearly the participants prefer discussing things like this in Slack over doing it in issues or Jira or whatever (which I understand, it’s a much nicer medium for discussion, IMHO), otherwise they would already be doing that. Your suggestion is essentially “just subvert the IT/legal policies by discussing it elsewhere, in a less efficient way”.

Clearly the problem here is the policy.

> move important discussions to somewhere that isn't Slack

At first I read this as having the discussion on a different medium in the first place, which seems a bit extreme. But from the rest of your comment I think mean just copy the discussion rather than move it, by copying and pasting (or manually re-summarising) elsewhere. I definitely agree with that. As you say at the end, that's a good idea even if Slack messages aren't auto-destroyed. (But there are definitely cases where it seems like you'll never need some scrap of information again and then it turns out you do.)

> Then there's no way for people joining the company to get answers to already-asked-and-answered questions, and they end up spamming everyone on various channels with frequently-asked questions that often go ignored because people are tired of re-posting the same answers over and over again.

In my office, Slack messages that live forever don't stop people from asking questions that have already been answered. The search tool is an afterthought.

I think the search tool could have been broken on purpose. It was somewhat-working in the previous, less "smart", version.

I'm struggle to understand a situation where that would ever be justifiable.

If they have a good reason for deleting messages, that's bad. If their legal team is overzealous and that power is unchecked, that's also bad.

A situation where the corporation is engaged in embarrassing or illegal shit and they're using Slack so they can do all the above-board, non-embarassing stuff via email that would show up in discovery.

5 day retention is so wildly impractical, it's a tacit admission the corp is up to something. Gives legal time to drag anything out in court until it's all gone. By the time the other party learns they have the 5-day retention, it's too late.

>By the time the other party learns they have the 5-day retention, it's too late.

Anyone hoping to use this trick to pull off the perfect caper will be dismayed to discover that not only is the other party allowed to talk to your employees, human testimony is admissible.

The idea of trying to make the past go away after five days, by deleting the digital records, reminds me of https://xkcd.com/1494/.

I'd also like to point out that this thread - where we're discussing the pros and cons of a technique for getting rid of inconvenient records, is itself the kind of awkward talk that, if found in a Slack channel during discovery, would turn in to something else entirely in the hands of some other company's lawyers. That sheds an interesting light on these retention policies.

If it wasn't for HN, I don't think that XKCD would have been anything more to me than a joke about programmers enjoying coming up with "cool hacks". But in the comments here I far too often find people trying to come up with legal loopholes that assume the system is perfectly rigid.

I was at a similar company. It's a bad sign when companies prioritize hiding errors over enabling success.

Has legal decreed you can't have a wiki as well?

I would guess that since wiki is less of an impulsive stream-of-consciousness type of a medium and more of a "sit down and write things in an organized manner after thinking things through" type, people are much less likely to put something that could create a problem for legal there (as opposed to Slack).

Not sure how factually true this is, but that rationale makes perfect sense in my head for why legal would make that rule for Slack/messaging while being totally cool with persistent wikis.

The sign up flow is really not great. Pick one and stick with it, but having to do “Phone Number” click “Insert verification code” click “Email” click, “Enter verification code” click. Either defer email verification, or get rid of phones altogether. It’s a forum, I’m not expecting replies in texts hopefully.

I closed the tab as soon as it asked for a phone number. Slack doesn't need it, neither does this thing.

I went to try out this service and the sign up process feels pretty invasive: a phone number, a code, my email, a code, and then "pick a username" - with no indication of what sort of visibility it's going to have or how far and wide on the service it's going to go.

I'd prefer to fill out a reCaptcha.

Good feedback - thanks!

I have tried Zulip but I think Twist has better UX & UI.

https://twist.com/slack-alternative

Supported by Doist which also supports Todoist which I am using

I've used Twist. It's a good piece of software, but I think it's too work-focused.

Consumerization of Enterprise is real - people don't want work to feel like work. Even Slack is more of a social tool than a work tool [1]. So, I think that the key to building a great work-focused tool is to start on non-work use cases - such as social groups.

Looking at Twist - I don't think it emphasizes usability, users in multiple workspaces, quality notifications, easy onboarding, and group discoverability. Take a look at the nav - it's built for hundreds of people, but groups will start with far fewer than that, and churn before they grow. Plus, it's entirely a logged-in experience - how many beloved forums are logged-in-only?

Twist is a good tool for certain uses - but I'm going for something more generalizeable.

[1] https://www.newyorker.com/culture/cultural-comment/slack-is-...

> So, I think that the key to building a great work-focused tool is to start on non-work use cases - such as social groups.

I've been thinking about this as I build a slack-meets-twitter like chat platform for public discourse (https://sqwok.im) and have had a few ppl ask if they could use it for a work communication tool.

It isn't my primary vision but it is something I've been thinking about and def open to hearing if other people would be interested in that.

I'll have to check out twist, had never heard of it!

No problem!

Please suggest more solutions.

We can always use more choices.

I am just mentioning what works for me (for now).

I never bother reading slack backlogs. I use slack to get quick answers to questions and then for any kind of design decisions, they go in to a diagram or wiki page which will be discussed in the next meeting.

Quite, slack is the equivalent of an office conversation, you can join in or ignore it. If someone wants you specifically they can @ you, and you can briefly glance at the context over the last few lines. Usually at that point you'll jump into a huddle / call, maybe you'll have to go back over it, but it only takes a few seconds to get the gist of what's being talked about, far easier than getting the gist of an office meeting that you've just been pulled into.

I don't see much point in having more than a few kilobytes of text in the scrollback. If it's persistent, put it in jira.

> jump into a huddle / call

... and first explain that they should use huddle, that works everywhere, instead of call, which is chrome-only. Great UX /s.

Slack is like twitter, if you are scrolling back through the feed bad things are happening.

Have the conversation and put the relevant stuff into the ticket / bug / wiki. If there are FAQ, time to write an FAQ!

If there is no discovery of things I wrote I don't care to write. Why should I write in slack if I have to write it again elsewhere?

Zulip solves the problem you mention extremely well.

I hadn't seen this - I'll check it out. Thanks!

Self-hosted software has its benefits. But, it's inaccessible to a lot of groups. So, I'm intentionally building more of a managed product. Controlling the deployment end-to-end will allow setting up new features more easily such as inbound email parsing.

Agreed, I guess that's why Zulip has a managed version as well.

The name is not great. The photo on first page is bad. And I couldn't find a demo at all. I was curious because forums where my go-place for online discussions growing up.

All valid feedback - and things I'll address. Thanks!

I’m interested in your idea, bringing what we’ve mastered in chat to the forum, but I don’t want to give my phone number or spin up a forum just to see. Is there an example forum?

I've been posting updates here, where you can see a demo: https://bookletupdates.substack.com

I'm working on "public" groups, so that I can link directly to a meta group about the project from the homepage. It should be live early next week!

I'm using phone number as primary login for these reasons:

1. I want passwordless login

2. Passwordless login with email is confusing because most people have multiple emails. But, most people have only one phone number.

3. I want to support per-group email preferences easily (i.e., multi-email)

4. iOS auto-fill makes it trivial to sign in

5. Phone number verification hopefully provides enough spam control that I can avoid deploying tools like Recaptcha - which I think are more invasive to privacy. (I'm aiming to be 100% Google-free and Facebook-free)

Let me share with you, this one quick, easy trick on how to lose 90% of sign ups.

Unfortunately, the data reflects this. I'll reevaluate phone-based login!

YMMV, but I'm absolutely not giving my phone number to a service of dubious providence because my employer told me to. I'd suggest federated login ASAP.

I personally find giving out my phone number as being several orders of magnitude more invasive to my privacy than filling out a simple captcha.

Thanks for the feedback!

It sounds like what should be brought back is NNTP or mailing list.

I think of Booklet as a better mailing list

That requires a web browser to use? No thanks.

I plan to build email bindings, too. But, I plan to start on web.

Landing page isn't particularly appetizing with "SATAN'S COFFEE" in big block letters.

Is that sentimental to you?

Yes, the homepage is a placeholder. Planning to update it in the next couple of weeks.

Satan's Coffee is a great little spot in Barcelona. The inspiration was that Booklet should feel like a fika [1] where once a day you sit down and participate in some thoughtful conversations.

I spent a couple of years as a digital nomad, and have fond memories of some cafes such as Satan's Coffee!

[1] https://en.wikipedia.org/wiki/Coffee_culture#Sweden

No wifi, no decaf, no bullshit.

Reply on news.ycombinator.com