Hacker News Reader

Comment by mumblemumble | Hacker News Reader

Not really, because it still doesn't give people sufficiently fine-grained control over demands on their attention.

I think the ideal is the approach you get with discussion forums: Create a set of boards organized around topics, and place named, threaded conversations within those boards. People can join a board, in which case they will be able to get a list of new conversations related to that board's topic. They can then subscribe to just the conversations that interest them, and unsubscribe from ones that cease to be of interest.

View on HN

What’s the difference between that sort of topics and news groups or mailing lists (with archives)? If I want information on something, subscribe; if I don’t want information, unsubscribe: I can always follow/search the archive (or read digests)

The archive on NNTP is a first-class artifact that you can interact with in your newsreader via NNTP. You can do things like reply to old threads.

The archive on a mailing list is a second-class artifact, typically hosted via HTTP, and usually people don't care about the quality of the archive's UX.

The structural organization on NNTP is also a first-class artifact that everyone can refer to. A mailing list will go straight into everyone's inbox, with all their other mail, until they filter it away.

IMAP and Exchange support archives and subscriptions.

It's a second level of organization/subscription so that you can have more fine-grained control over how much you get spammed.

News groups and mailing lists don't scale super well, in that, when you subscribe, you then get sent everything. Maybe not terrible for the 5-10 emails a day from my kid's playgroup's email list, but absolutely awful for trying to keep up with a team of 100 people.

But the solution is exactly the same: create a new mailing list or newsgroup under the sort of circumstances where you’d add a topic to a forum or a channel in a Slack workspace. Open source projects, for example, will have foo-announce, foo-user, foo-devel, etc.

Or use digests, mail filters/folders and a convention for tagging message subjects.

So, that's the top level. The 2nd level would be more analogous to individual email threads within those groups.

Once you get down to the individual conversation level, the fine-grained management bits you talk about are not good UX, they're band-aids for dealing with bad UX.

Well, whether they’re good or bad UX depends on assumptions about whether the second-level categorization is more meaningful organization-wide or on a user-by-user basis.

In a newsgroup, you don't get sent anything. You can go to the group and see what's new. If there's a particular thread you're not interested, tell your news client to ignore it; if there's one you're particularly interested in, tell your news client to watch it:

https://superuser.com/questions/458136/thunderbird-watch-or-...

when you subscribe, you then get sent everything.

1. Killfiles

2. Contextually-scoped lists. If a topic is of limited concern yet intrusive, split it to a separate list. Moderation and management may be necessary. Technical teams should be scoped correspondingly. 100+ team members is excessive, 3-15 far more typical.

But isn't that how the typical chat works? Where's the difference? At least that's similar to how the channels in my company are organized. The only difference might be that there's faster feedback in a chat and this leads to shorter posts/messages. But I haven't really used any forum software in the past decade, so I don't know if they don't have similar notifications and unread status icons on threads today.

The problem with chat is the interruptive, thoughtless nature of it. In a large organization, you want durability that you won't get from chat.

Internal Q&A, forums, and email all work because you can have long-form conversations on them but an important consideration is discoverability. If a new user wants to find out why X is true for some service, they'd better be able to do that without interrupting someone else.

... why ... not ... just mute it? Also Slack's entire business model builds on storing chat for long and it has a not too bad search. (Though I hate it, because it's slow. But GMail is slow too. Even Thunderbird is, probably because it touches IMAP or whatever for just displaying what I'm currently typing.

VSCode is somehow fast despite running a bunch of linters/compilers/language-servers while typing, and similarly built on web tech, and ... in case of a JS/NodeJS/TS project it also handles tens/hundreds of thousands of files with ease, oh with full text search.)

I have found Slack search at work just sucks. Whenever I tried it gives wrong priority to results. Plus questions and replies are too short and search can not pickup on context.

Sounds like the approach taken by zulip. Check it out, it's a cool paradigm

Reply on news.ycombinator.com