I've been loving their responsiveness lately /s. I `ctrl-k` jump to another convo and start typing and the lag between `ctrl-k` closing and switching to the new convo is enough that I end up typing a few characters into the prior conversation - then I need to jump back to clear out the draft.
Their channel listing is generally crap though, I gave up on trying to navigate it and just use `ctrl-k` jumping for everything, which isn't terrible because it means I spend less time on the mouse.
It's hilarious to think that there's almost nothing the Slack client is doing that a fat desktop app couldn't trivially do with nearly zero latency in 1999 in 1/20th the amount of RAM.
If someone built an emacs plu-(pardon me a moment, * googles furiously * , * laughs * )
Okay, someone built an emacs plugin for slack[1], it doesn't look like a very usable version of slack, but I'm pretty sure it'd be quite possible to fix this up a bit, prettify the UI, and end up with a much more performant version.
We have a culturally enforced strict rule of moving literally ALL new conversations into a subthread and I absolutely LOVE it. This means that if you want to respond to a comment, you never do it in the channel but in the subthread of _that_ comment.
This means that when you browse the channel itself, each individual line represents a conversation on a specific topic. You can essentially browse the "headlines" of the day all in one screen (for most channels), and if you care to hear more about how Bob resolved his problem with those third party build dependencies then you can view the conversation in the subthread.
This also enables folks to opt-in to notifications for channels, if they so desire, without getting overwhelmed with every new message that comes in.
We do this, too, but I really dislike the thread UX.
Threads should behave like nested channels. Today, that works okay if you click on the "5 replies" link under a message, though it opens up a cramped sidebar instead of taking you to something that feels "nested".
But when there are multiple threads, the only way to juggle them is that "Threads" entry in the man sidebar. It leads to a weird page that doesn't behave like a regular channel. For one, new messages don't come in automatically; it just shows "1 unread reply" or whatever which has to be clicked. Secondly, if you have multiple threads active at once, the view crams all of them into a single scrollable pane.
Threads should, in my opinion, show up as separate entries in the sidebar. And Slack should support having multiple windows open for separate threads and channels, which would make it easier to have multiple conversations going on at the same time.
That would be easier to do if Slack had better support for threading. But you can only have one thread open at a time, and if you're in the overall "Threads" view you have to click every single time a new comment comes in before it will show the comment.
This is how I imagined threads working when they were announced, but it seems they are never used consistently. How exactly do you manage to enforce that rule?
Even if this worked, it's just a nice step toward a full comment tree (like HN or reddit). I get the impression some people find that format confusing, but I think it's vastly superior. I assume programmers generally prefer it.
If it's an actual comment tree and not a single level that also mixes in multiple conversations, then it works. Otherwise, it's like trying to use something like Facebook for a discussion platform.
How would HN or reddit look like if every reply to a post also had a single level nested thread that actually consisted of multiple subthreads of conversations with everything at the same level of nesting? It would be much more difficult to follow different subtopics of interest since it would be impossible to filter out posts that aren't pertinent to it.
This isn't our standard for all channels, but we do have a channel dedicated to this approach that's meant to contain large direction decisions that are soliciting team opinions. We've also enforced keeping that opening message to a minimum (sort of like a title).
I don't know how I'd feel about all channels being this way (since visibility and notification control are much weaker in this format) but for time limited discussions that may warrant revisiting it's quite helpful.
Isn't this just Microsoft Teams? Not to be a shill (I prefer Teams over Slack but don't love either). In Teams the editor box in each channel creates a new post on which people then comment. Is Slack, a channel is just another group chat. What you do turns Slack into Teams in this regard seems to me. Which as far as I'm concerned is a better system, I just wish Slack had tools to enforce it stricter ways than as a cultural rule.
Just to provide a counterpoint, threads are very useful for channels with hundreds of members, so that anyone can ask a question but the responses don't make other questions invisible. In that case, the lack of threads would hide important information.
In that situation, I think I would go insane, or resign to preserve my sanity!
Our slack channels have at most a dozen active members and my channel list has approximately a dozen channels with permutations of the same dozen people organized topically. I have turned off almost all notifications as they are so ridiculous and look at the sidebar once in a while to see which channels are active.
I consider slack content ephemeral, even if slack disagrees. If I want to track issues, I use an issue tracker. If I want a threaded conversation, I'd probably write an email still. If I want to find content, I search a wiki or an email archive.
My preference for threads is as appears in my old school mail client or my fading memories of the "trn" threaded news reader for usenet. Threads do not hide messages, they only reorder them into a hierarchical index. It is easy to move back up the index to skim prior content in the tree, but it is also trivial to press a key and jump to the next unread message sorted first by thread and next by message time (to break ties or decide which thread to visit next after exhausting one).
Recently I had the absurd situation of someone using threaded replies in a direct message channel. It was astounding to me that this person thought this was a good idea, and also that the slack UX could so completely obfuscate an attempt at communication...
> Recently I had the absurd situation of someone using threaded replies in a direct message channel
My colleagues and I sometimes discuss far-ranging topics in temporal proximity. While in the heat of the chat I can keep replies straight in my head, it helps to have them grouped for later review; furthermore, they reduce the need for segues in and out of conversational contexts, which I find incredibly liberating.
Is this in the context of a public slack? For our internal slack I'd strongly question why questions needed to be raised in a channel with so many people - at my office we have two channels that most people are in, a #general for company announcement and releases and #random.
Otherwise I think dedicated team interaction channels are the biggest of ours and we try and keep those pretty small still.
I like threads for this purpose.
I really wish I could see a filtered chain of conversation as a subtopic of a main channel.
Not sure how UX or exposure to this feature would look, but that wont stop me from dreaming.
You can answer and the original post is shown below your answer. You can do the same with Slack by sharing the post, but other solutions make it way simpler, basically just one click.
this sounds dumb, but it's most likely due to patents [0]. in fact whenever you find really simple behavior missing from an app from a large organization you should first assume IP litigation played a role
Do you feel the same way about email threads? If you're on too many email threads, there are too many emails in your company, right? I guess this is scale invariant with enterprise size too, right?
Sure, but Slack channels are somewhere between email subscription lists and recurring email threads, in the space of corporate communication.
Channels may exist for each corporate customer, of which there may be a hundred or more, where CS reps subscribe to subsets that they're focused on, country managers subscribe to those that are local, product managers subscribe broadly by vertical but only scan to get a feel, sales may subscribe by function or region, etc. This is an easy way to get a large number of useful channels that simultaneously cuts down on noise.
BTW, you're surprisingly dictatorial in what you say. Emergent behaviour is far more interesting to me, because - along with conscious reflection - it evolves uses that can't easily be foreseen. Where did you get your rules handed down from on high, how were they justified, and what right do you have to think they are correct?
> BTW, you're surprisingly dictatorial in what you say. Emergent behaviour is far more interesting to me
Sorry, you're right. Nothing is set in stone, all rules have their exceptions, etc.
My point was that having too many channels can lead to a constant sense of urgency, FOMO, and increased anxiety. If you have a carefully defined way of using them, without a sense of urgency, and without a need to see everything, it may work.
I provided that /feedback as soon as it rolled out (to me) I guess 6mo ago. I even got a reply along the lines that it was totally reasonable and eminently sensible, and yet here we are.
I provided feedback to slack once and got a reply similar to that. I wonder if they say that just to make you feel good and then throw the feedback in the bin.
