81–90 of 220 posts
I also considered creating some biz comm software myself, but only jotted down some ideas[0]
0 - https://bitbucket.org/snippets/cretz/Xopoj/retzle-conceptual
Google Wave?
I worked at a Slack shop for several years, and share the author's opinion. I can't think of any five minute period during my entire tenure where the Slack tab didn't have a little red circle telling me that I absolutely needed to check it right this second. There was no way to filter notifications beyond "Everything", so that little bubble would go up every time anybody in the company pressed a key. And heaven forbi…
We've left the "social" era and have entered the era of interruptions. All the innovation this decade is in interruptions no longer human-interconnections. My smart watch for example post dates the social era so it has only minimal social features, but its deep in the interruption zone and spams me mercilessly until I block apps and if I block enough apps I may as well have a cheap dumb watch. Another way to look at…
Github Enterprise is so far the worst offender - I can't find a non-heuristic way to filter user merge messages (which contain the user name) from actual user comments.
Earlier quoted context omitted.
And heaven forbid somebody typed "Good morning, @channel" (which happened 20 times per morning per timezone), because then you'd get the dreaded Red Exclamation Mark in the tab. That isn't a problem with Slack. That's a problem with the way people are using Slack. If the only workable fix is to use a different tool you have a far bigger problem at your company. I can't fathom how anybody would have been able to work…
> That isn't a problem with Slack. That's a problem with the way people are using Slack. The notion that tools exist in some sort of vacuum away from users baffles me. Since Slack's only purpose is talking with other people, I don't how one can even theoretically evaluate it separate from usage. This is a very common thing that happens with Slack. If it were just one team struggling to use it well, you might have a p…
I don't think the fundamental problem is one of sync vs async communication. Of course synchronous communication is a flow killer, and of course having it as a team-wide or company-wide means of communication aggravates its problems. The async nature just makes it worse, as it has more bandwidth, and consumes more brain bandwidth as a result of more content than email and wider distribution than email. The problem li…
We built it to be Thread First AND have a thread-first inbox as well.
However, more importantly we realized that just thread-first is not sufficient. We saw three major problems with synchronous solutions like Slack and asynchronous solutions like email. 1) Lack of support for updatable content 2) Lack of support for easily moving from unstructured to structured content. 3) Difficulty catching up
So we added the notion of Updateable "Sections" to threads (in addition to conventional attachments).
These "Sections" come in various types, some of which lend themselves to making your thread structured. 1) Text 2) Form (structured) 3) Task List 4) Checklist (process) 5) Word, Excel, Powerpoint etc.
This allows one to create threads that have structured content. However, this still doesn't solve the "one-off" problem you described. So, we made it easy to take any thread and make it a "Template" that can be easily instantiated. This allows one to naturally to evolve towards lightweight processes starting from regular threads.
For example, here is one of the "industry solutions" pages which gives ideas for structured threads in a particular industry (in this case Manufacturing and Logistics)
https://tmail21.com/solutions/industries/manufacturing-and-l...
Lastly for the "difficulty catching up" problem, we took inspiration from the way git et al are built and decided to make "diffs" central to the catchup metaphor. We're talking not only diffs for Text, but also for Task Lists, Grids, Checklists, Forms and other "Sections".
We hope to make communication and collaboration significantly more productive. Would love to get any HN feedback.
ps) We integrate with Slack to marry their synchronous model with our asynchronous model.
Sametime was a big part of IBM culture. IBMs work from home policy was tied up with it. At work means you are online and responsive to Sametime. A typical meeting involves people sitting in a conference room Sametiming comments to each other about the speaker.
One nice thing about Sametime is that you chat history is in XML files on your computer. This allows you to use grep to find past information.
IBM started to use Slack when I left. On the one hand this allows you to collaborate with people outside IBM, but downside is you need both tools running. Slack for the cool kids, Sametime for the old guys.
My new job is giving me a new experience- video conferences using Google Hangouts. Many times with googlers on the Google bus.
Earlier quoted context omitted.
Real-time chat happens quickly — one line at a time — discouraging full, thoughtful conversations. Slack supports shift+CRLF for line breaks, so users can write epic poems broken up in to hundreds of stanzas if they want to. Using Slack as a one-line-at-a-time chat service is a choice that a user makes. Slack itself doesn't enforce it. Topics are all jumbled together in a channel so it’s nearly impossible to piece to…
It is true that Slack allows multi-line posts and discrete conversations, but both go totally against the grain of the system design. Expecting people to use Slack in a way it wasn't designed for can only result in failure or constant friction.
Earlier quoted context omitted.
And Slack is a modern version of IRC :) It keep being surprised by how much a fresh coat of CSS and a mobile app can reinvigorate these old ideas. Who knew how important adding gifs and emoticons would be?
https://grove.io/
Earlier quoted context omitted.
> That isn't a problem with Slack. That's a problem with the way people are using Slack. The notion that tools exist in some sort of vacuum away from users baffles me. Since Slack's only purpose is talking with other people, I don't how one can even theoretically evaluate it separate from usage. This is a very common thing that happens with Slack. If it were just one team struggling to use it well, you might have a p…
> The notion that tools exist in some sort of vacuum away from users baffles me This x1000 Software is developed and used in a social context. We can't disavow responsibility for the effects our Software cause.
Your company has hammers and screw drivers as your tools. If your employees only know how to use hammers, they are going to hammer screws. If your team only knows how to use screw drivers, they will shrug at nails. Hence, the tool is not always at fault for end user error.
Learning how and when it is appropriate to use the tools at hand is important.