Hacker News Reader

Comment by wfme | Hacker News Reader

This is very reminiscent of the initial hn response to DropBox [0]. This is like saying that you can build a Tesla clone by attaching 3 pieces of wood together along with 4 wheels.

Although it is technically cool, it misses practically all of what makes Slack so popular - UX.

[0]: https://news.ycombinator.com/item?id=8863

View on HN

>it misses practically all of what makes Slack so popular - UX

I strongly disagree. Slack has nearly the same UX as every chat platform of the past 2-3 decades. It's a slightly change over AOL Instant Messenger. There's also a large amount of very similar software or straight-up slack clones that are not very popular at all.

I would say what makes Slack so popular is how easy it is to set up and get running, both as a service and for every user, combined with the availability of easy integrations/plugins.

> I would say what makes Slack so popular is how easy it is to set up and get running, both as a service and for every user, combined with the availability of easy integrations/plugins

That is part of the User eXperience. I.e. UX.

What you are describing is quite literally the UX, the user experience, and Slack overall has quite a good one. Although several of the newer features are somewhat lacking in that regard, like the threads feature.

there are a bunch of features in slack beyond the core chat stuff, like:

1. being connected to multiple communities and switching between them instantly

this can be of course simply replaced by connecting to different servers in a tabbed terminal and use the terminal's built-in cmd-1/2/... shortcut, which happens to be the same as in slack.

2. meta data about others, like their timezone or how to pronounce their name is quite important for distributed team work

this can be approximated by a world readable file on the chat server in every user's home, like .plan or motd files (https://github.com/ESWAT/john-carmack-plan-archive)

3. automatic idleness detection

im actually not sure how reliable is this even in slack, but in general, it can be useful, but im not sure how to solve it elegantly, when the chat runs remotely...

maybe we should just spawn a loop at the background, which gathers idleness status from the OS and uploads it when it changes, into world readable files and the remote clients can just check those file whenever they want.

4. extra status indication with automatic expiry, eg when someone is away from the keyboard, coz they are having lunch

we do use this feature often and it's a really helpful regarding when can we expect a response from someone.

again, quite simple to model this as a plain text file and we can even use emojis, to have a very similar effect to setting " lunch" on slack. ppl would need to know what's the emoji selector shortcut though... like cmd-ctrl-space on macos.

5. text search across all channels/rooms

assuming the chat is being logged into files, then a recursive (rip)grep could work to some extent, but then from the search results one might want to get back to the context of the result too.

6. threads

this complicates implementation a lot more, but we found it an obvious improvement over the single threaded IRC model of communication

7. having threads open on the side, so ppl can track 2 streams of comms at once at least

it would require starting the chat app multiple times and do some window management to see them side-by-side

now obviously all this can be done a lot simpler, but those implementations typically always lack somehow. not sure why is that...

see https://cancel.fm/ripcord/ or http://www.altme.com/what.html

the REBOL 3 programming language even had a quite full featured, text-mode chat built in: http://www.rebol.com/r3/docs/functions/chat.html !

Points 3 & 4 could be combined: like .plan, each user has an o+r .status file. Its contents are a user's status message, but its modified time is used specially to indicate when that user was last active. Anytime the usuc client writes a message to a channel, it would simply touch the .status file. And whenever an expanded usuc or some other tool lists the users in a channel (that is, all users in the group that owns the channel file), it would mark as idle any who had a .status mtime older than 30 minutes, say.

Reply on news.ycombinator.com