This was my problem with Wave. I found the UI really confusing (and the value prop not high enough to get over the learning curve) and incredibly slow. I tried it a few times and decided I didn't care for it.
Looks nice, sadly I can't use it because I'm not sure all in my team are fine with an English UI. Also still a lot of worries about the cloud. So it is still sending back and forth Word documents and the hope you didn't miss any because people didn't pay attention to whom they sent the emails.
it looks a bit more complicated than the Slack one, because of the thread/comment difference, but the "Automatic URL Report" and "Loop in" email based input looks very powerful as well.
I will try this out with our company, because this is exactly how I wanted Slack to have threading.
But Twists API to create either thread/comment in an integration will be more complicated to do than Slack and their attachments are not very powerful (yet?), migrating our existing Slack related code might proof difficult.
Right off the bat, this has much better performance on my laptop than Slack; Slack really spins the fans. Also, that extra layer of organization provided by the thread column was needed badly. I personally was hoping for tags and tag-groups in Slack, but this should also do nicely.
We have been using Slack as a UI for our backend services, for example, and it is a great way to present reports and alerts, and offer basic controls to the relevant person. For me, whether or not I actually adopt Twist will depend on how easily I can interact with it from my own software.
I would suggest making the integrations page easier to find - I had to troll through the Zendesk archive to find it, even though it is a core feature. Also, a link to the API docs on the help page would be nice. (Edit: Didn't realize until now that integrations are at the channel level, not the top level.)
Well, the native Slack app is just an Electron wrapper around their web app, as far as I can tell. The performance feels roughly the same for both web and desktop.
The main reason I kept the desktop app, is so that I don't need to "download" the app every time my browser's cached copy is invalidated or expires. But being able to start the app with a couple keystrokes from my OS's quick launch menu is also nice.
Interesting. So you're saying that it really 'spins the fans' when you run slack as a pure web app as well? It seems quite lightweight to me, on latest chrome in Ubuntu on a late 2016 macbook pro.
Just tested again. Performance is good when idling, but while loading content in a heavy channel, scrolling gets laggy and one CPU plateaus for a while. Maybe the app is inserting DOM nodes individually, in a loop?
I guess it's too early for me to evaluate the performance of Twist, because I am not on any large teams there. But I can see that Slack at least, has room for improvement in rendering performance. Perhaps there is some general optimization they are missing out on, like immutable state + shouldComponentUpdate. That one saved a flailing app of mine in the past.
The native app gives you a red badge when there are unread items which I find super useful. I also like that I can cmd+tab to it without having to fish for the right tab in Chrome. Sometimes I completely close Chrome and forget that Slack isn't open anymore and I wont be notified when people are trying to reach me.
Hmm. It seems that these chat applications are more and more becoming like a polished webmail system. Now they've introduced threads, it's searchable forever, you can mail erm. I mean send messages to individuals or even groups. This new technology is amazing. Seriously there is nothing wrong with using e-mail (apart from the dated protocol) and for knowledge sharing your team is better of with some kind of wiki with organized information.
allright, let´s play this game, from your help page:
> An email inbox is unorganized
Mine isn´t. Between folders and labels, my inbox is clean and organised.
> Email chains easily become long and difficult to read, and can splinter off into multiple chains
The multiple threads/chains is a feature. I want to be able to splinter off a discussion. Also, if you frequently have massive email chains, you might want to just call a webex.
> when someone goes on vacation or leaves your team, progress grinds to a halt
That is an organisational problem, not a communications-tool problem.
> your email inbox is just one of many places where your team communicates.
And twist is going to be yet another place to look.
[rehash of email is bad]
> On top of that, Twist gives your team the space to get deep work done by allowing you to snooze all notifications.
So, like slack, snoozed, but looks like email? When I need to put my head down to get stuff done I switch stuff off, which appears to be the easier option.
Email never interrupts me. I have all audible and popup notifications turned off and generally check if I have new email only when it suits me. I make this super fast and simple by checking if my email icon on my phone has a little red number. Takes two seconds. If I have email, I can read them, if I don't, great.
Like you, I use filters and labels to keep my inbox clean. Automated emails and mailing lists get filtered away right away (and I check them manually when I feel like it). My inbox itself then takes a few seconds to clean leaving only stuff I have to act on. I use the Spark mail client which is very similar to google inbox in that I can quickly deal wia h messages or "snooze" those I can't deal with right now.
This way, I have zero unread messages in my inbox most of the time. (And I get OCD when I see other peopl ea phones or screenshots with 30k unread messages... wtf is wrong with people!)
I don't see anything there that cannot be solved by a client.
I only see a proprietary email service here, one that cannot be used with other existing solutions. Why not build this on top of the current email protocols and offer a good client for reading it and an easy way to setup a mailing list (with an easy way to browse the archives)? That way this could be used with other clients and existing mail bots. No need for another integration API or to install another bloated client.
If the user experience is really what sets this apart from mailing lists then you shouldn't have problems monetizing it.
Also the point about
> An email inbox is essentially just another list to manage.
Twist is the same, but everyone already has an email account, why should I add yet another one?
I see what you mean with this. I think NNTP is still a great protocol for discussions, it's just that over the years it got a bad rap for being a warez/porn haven.
The server/client mechanism is robust and scalable. With a good client UI, it could be turned into quite a smart social/work platform.
I've been toying with attempting such a NNTP client, but it's way down on my list of projects.
The idea that is different here is that it is an invite only system - meaning no spam.
The first question that came up for me was 'who do I invite' - I had to think who in the team is an early adopter and would be receptive to trying something new. Then my next thought was to Hangouts them and tell them what I was doing so they did not see an invite for something unknown... then I thought... Why don't I just email them... and lastly... Why am I doing this again? I have already everything I need to talk to them... What is the advantage of this service?
So I had a few minutes to think about my response and am going to respond to my own question... With a potential solution.
Much of what I am reading is that it has better thread handling - I will assume that it does. I have also read the part where it is better for new team members - I get that, a new member can pop in and see the trail (how often that would actually happen? - unknown). I also read the sync vs async argument - sure, I like async but at times I need sync, like hard sync with red lights and bells (sms and whatsapp + phone calls and knocking on doors at night).
I think at the core there is a kernel of greatness that can be built upon: Everything is a 'topic' and has potential triggers to external systems. I think this could be a system that has everything in it eventually. If a topic is a lazy topic then it could be tagged as such, for example a message about next weeks dev lunch, but if the site is down then tag it with a critical tag and the alarms could go off. I see the real power here is that it can be connected to external things much better than email can without significant rfc822 parsing. There is opportunity here to supplant your current email stream.
The other coolness I can see is the potential for archiving everything - I think in certain circumstances Hangouts is too ephemeral. Daily standups should be recorded for remote teams or brainstorming sessions for SR&ED (Canadian tax thing). Even whiteboards and phone calls should be archived against a topic. Connect the system to a SIP service and all calls about a topic could be logged. Perhaps WebRTC would be the cool kids way of doing things.
I would use a service that recorded everything (that I wanted to be recorded) and had ways of moving from async to hard sync fluidly.
And even the spam isn't a very good argument. You could easily set your email account to block everything that isn't from a specific domain. You can even do this in Gmail.
"raw" email doesn't help much when someone new comes in to the project, and has no access to the previous emails. systems like these keep most of the ceremony of emails, but provide historical access.
Of course, you can set up email group systems with archiving and search in those, but... that's more work, now you may have multiple systems for people to have access to, etc.
systems like this are logical extensions of the ceremony of email with some added benefits.
It's email that gets to reinvent ~30 years of formal and informal specs and interoperability hacks because it controls all clients, and all servers in between. And yes, there's a lot wrong with email, it's just that it's familiar and we've figured out how to work around/live with a lot of the badness.
The org I work for has used [Flowdock](flowdock.com) for several years now and I have to say that threaded semi-real time communication is a huge boon. So, on the face of it I'm not against Twist but, as a user of a similar application, I have several questions:
1. Must all messages be thread topics or thread replies?
2. Are messages presented in the order they were sent/recieved or in some grouping based on thread?
3. Can messages be "re-threaded" so that replies
i. become their own thread topic?
ii. become a reply to a different thread?
From my own research, it seems the answers are:
1. yes, all messages are either thread topics or replies;
2. messages are only grouped by thread and can't be seen as a stream where real-time communication across threads can happen;
3. and, no, messages cannot be re-threaded.
Which, if true, I think makes it decidedly worse than Flowdock. Its true that Flowdock also does not support re-threading and for that I will eternally hate Rally/CA for never adding but in all other aspects where Flowdock attempts to be something fundamentally different than email, Twist attempts to be, like Slack before it, an email killer.
For Flowdock default communication in a channel is just a message and only reifies into a thread topic when it recieves a reply. Also, the default presentation of messages is "real-time" group chat with color coding to identify threads and a dedicated thread viewer to "focus" on a single discussion if needed. Essentially Flowdock is standard group chat with an admittedly useful organizational concept of threads.
Twist seems to strip out the "group chat" part, leaving only threads and at that point I kind of agree that its just sexier email. I'd argue the whole reason Flowdock (or similiar) is necessary in addition to email is it reduces the barrier of what is "message worthy". If I want to send a message about my dog as an email, that feels weird. If I want to send the same message to a channel in Flowdock it doesn't; it may even become a thread but it doesn't disrupt useful work going on in other threads. Twist seems like it falls decidedly in the first camp and _that_ is why I won't switch to it from Flowdock. I simply can't use it for water-cooler style communication (group chat - Slack, Flowdock, even AIM win here) or productive real-time focused discussion _across problems_ (multi-threaded group chat so that one thread can dovetail/inform another in the public discussion - this is a Flowdock only thing AFAIK). The only problem it seems to solve is productive focused discussion on a single topic and honestly email already does that very well.
I will say searching is nice; of course, Flowdock has that too (as does Slack and many internet-based email solutions).
There is a simple reason that email is not a good team communication mechanism, and that is onboarding new members and capturing collective memory.
A threaded store and forward system works better for that as it allows new participants (members of the team) to read back in the historical documents about what happened before and what outcomes were created.
The three pillars of communication appear to me to be:
Time sensitive; communication of the specific moment (calendars are included here)
Evolved knowledge; communications of the group which represent the evolution of the group understanding of processes, challenges, and solutions.
Directive/Command; communications which direct individual or group action and recover group status.
The typical solutions fall into 'chat/calendar', 'news/bulleitin board', and 'email'
The knowledge you get at school or college is a kind "onboarding" new members. But it doesn't make you read every single piece that was ever written. You get a summary of both events and outcome, and most importantly the current state.
That's also how Wikipedia works: Articles don't get longer and longer, you can also summarize and put stuff into perspective. That's why there is a way to delete stuff (with version control, of course).
Moreover, onboarding new people (or maintaining the collective memory) isn't the only form of communication that happens in a team. Maybe it's not even the most important.
What about coordination? On the smaller stuff, on the daily stuff, but also on the bigger picture?
I don't disagree with your assessment but note that in 'school' the subject is taught from a text book which is a distilled version of the knowledge. Those text books get periodically rewritten. In an engineering organization it would be difficult to justify the expense (although it might be worth it!) to hire a writer to distill all of the learning that happened and the history of that learning into a text that could be handed to new members to bring them up to speed. As a result it is simpler and more cost effective to have a mailing list archive that can be reviewed.
Now it you want to create a product/company out of that practice, then you would build a system that would let people reviewing messages be able to 'vote them up' based on their importance to the over all work product. That sort of 'auto curation' would then let you scan just the list with a 'curation threshold' and just read the important bits rather than everything in the list.
That might be a good compromise between a dedicated historian/textbook writer and a list which had all the data but it was inter spersed with the occasional "lets gets the group together for a movie / which movie" discussion.
When I look at, for example, technical updates from the Facebook Engineering teams, it's really a little textbook, a distilled version of the knowledge at that point in time.
Same if you bring new team members up to speed by talking to that person.
There is typically no single "historical" document that does the job. Old documents (e-mails, descriptions, comments, ...) tend to be outdated. New documents tend to be increments, so they don't really make sense if you don't know what is written in the old documents.
I expect that in the near future, automatic summaries based on NLP would be able to do all the heavy lifting, so the head of engineering (or whoever is in charge) will only edit the doc, not write it from scratch.
> Seriously there is nothing wrong with using e-mail (apart from the dated protocol) and for knowledge sharing your team is better of with some kind of wiki with organized information.
I'm the co-founder of https://www.fwdeveryone.com, which implements the same sort of functionality on top of email. This way you can capture both the knowledge created within your organization, and also conversations between your coworkers and people outside your business. There is no new client to adopt, and your data already comes pre-exported into your gmail or google apps account. And if you have a conversation you'd like to share publicly then we provide tools, like requesting permission and redacting sensitive info, to make this easy also, e.g.: https://www.reddit.com/r/Connecticut/comments/65kbok/good_hi...
Wikis are great, but maintaining them is basically a full time job, which is why they tend to be terrible and out of date. And even in cases where you have a PM maintaining your wiki full time, the majority of organizational knowledge is still locked up in email. Given that the amount of personal non-spam email sent every day is something like 100x the total size of Wikipedia, it seems unlikely that chat programs, email replacement solutions, or wikis can ever really be a complete solution.
Also, everyone already knows how to write or respond to an email, but many people within organizations don't know how to do simple things like making an account on a website. It sounds like a trivial problem, but we've found that having a system where everyone can contribute without having to learn anything new is actually a big win.
Right now the person uploading the thread needs to be using gmail or a Google Apps account. We started there because there are 1.1 billion daily active users, but in the future it will work with other email service providers.
Being able to use DKIM and SPF to authenticate threads is part of our value proposition, and a key part of the value proposition of email in general. (For example, being able to prove that you agreed on X project requirements with a certain person on a certain date.) Doing this type of authentication requires every message in a thread, not just the last one, so the most pragmatic way to meet this requirement is to work with email service providers with available APIs. The alternative is storing the entire contents of your inbox, but this doesn't make sense until we're ready to roll out our enterprise offering.
I'm really impressed by the attention to detail for a brand new product.
I know they spent a couple years getting to this point, but I can really appreciate the quick, well-designed iOS app, and the native, non-Chromium / non-Electron Mac app that only uses 35MB of RAM and has no noticeable idle CPU draw. It's such a stark contrast with Slack and most of today's pseudo-native apps.
again? this was on HN just recently, but now it is "mindful" - said it then, and will say it again, it looks like email, and find that the hassle of yet another communications tool not worth it in this case (basically email with a default "reply-to-all" permanently jammed in place).
It's way better organized than email. You can edit things together following the same format (not the dozen different ways people will reply to emails), you can edit, know things will look the same for everybody, know for sure everybody has access to everything and can search, everybody sees the same categories (not your own special way of organizing things while other coworkers are lost in the their mess).
TL;DR: they just invented internet forum/message board but with nicer GUI.
And it's good.
I think internet went wrong way to ditch traditional internet forums/discussion groups/ and internet communication started to be based on real time chats (Slack, Messenger, Skype etc.), but I'm glad that we're returning to the oldschool (I'm waiting for Facebook to introduce "threads/topics" on its groups, because now Facebook groups are less functional than plain old phpBB.
The problem they claim to address is real. However, the product not really addresses it. It's too close to email and existing messengers.
[ Problem ]
- Meetings have the potential to really keep a team together
- Teams are distributed throughout geography, time zones or daily life patterns
- So how to bring GOOD meetings online, and perhaps even make them asynchronous?
"Meetings" come in different flavors, for example
- Weekly or monthly meetings to look back, learn, and discuss how to move on
- Daily scrum / daily standup to get a shared view of the day
- Ad hoc meetings to address a smaller but immediate issue
- Water cooler meetings which allow for serendipity
...
So for meetings in person, the real challenge is to get everyone attending, even if there is lot of urgent / important work to do. On the flip side: Keep the signal / noise ratio of the meeting so everyone feels it's time well spent.
[ Solution ]
So my vision for a better tool would include:
- Separation of reading mode and writing mode. You should be able to write in the sense of offloading thoughts without the need / option to read through everyone else's notes at the same time
- Asynchronous default. Stuff you write should be considered a draft until intentionally "published" (exception: urgent stuff
/ water cooler stuff). That would allow revising bigger thoughts before a "meeting".
- Even asynchronous, virtual meetings should have schedules. So for "daily" meetings, there should be a function that makes sure that everyone reads and writes at least once a day. For "monthly" at least once a month, but without that becoming a continuous "monthly meeting", which wouldn't allow to really focus on it.
I think this has lots of potential. I have thought before that if I could make two changes to Slack (which I already think is pretty great), they would be:
1. Hitting "Enter" doesn't send the message. This encourages writing actual paragraphs in response, rather than sending fragments of sentences
that can be interrupted across multiple lines
because you're not really sure if you've finished your sentence just yet
oh and you thought of one more thing so everyone else please take this line into consideration as well
Of course, you might say "train your team to not do that." Sure. But I'd rather use a tool that doesn't require breaking (perhaps reasonable) habits. And if communication shouldn't be through short bursty chunks by default, why make that the easiest thing to do?
2. Make threads more of a default way to respond, and make thread comments first-class citizens. Presented with the UX of Slack, it's really hard to move yourself towards using threads because the easiest way to respond to things is to type and hit enter. Also, threads live in their own "All threads" space, not organized by channel. Thread comments aren't first-class citizens like regular chat is because they can't have files attached, be posts or snippets, etc, so sometimes it feels like I actually _lose_ functionality by starting a thread.
Twist looks like it has what I love about Slack – good for newbies to join in and see organized, curated history (I can't show new folks _my_ inbox labels and organization, or spin up a new channel on a mailing list for each topic we want to discuss), good for lurking on projects that aren't your own but are related, and has emoji responses for celebration, quick feedback, and commiseration.
Threads are pretty awful. It's really easy for messages and discussions to get lost in them and for participants not to realize that more has been said.
This is a UI/UX problem. You can make the same argument about an unorganized spew tube that I now have to spend 50% of my cognitive ability to organize into a threaded conversation manually in my head.
Huh, I've never found following concurrent conversations in Slack particularly challenging, but then I spent a lot of time a handful of years back in fast-moving chats that often had several unrelated discussions going on at once. Maybe it's a learned skill.
That said, in 3 years at Slack-heavy companies, the level of interleaved conversation I've encountered is almost nil. Maybe that's cultural (though the consistency across multiple companies and teams suggests not). Maybe company or team size is a factor. Maybe it's a matter of breaking it out into enough channels that if there are multiple topics to discuss at once they're usually happening in separate channels anyway.
Sure, Slack could probably improve the threads UI. (Though I happen to think that threaded display and real-time discussion are in some ways conflicting goals.) As it stands, however, they're a black hole. My team has actually banned the use of threads (and no, it wasn't even my suggestion).
This almost exactly replicates the workflow my team uses with discourse. I don't see the advantage this has over plain old message boards... Perhaps there's a feature I'm missing
80 comments
[ 3.9 ms ] story [ 153 ms ] threadhttps://techcrunch.com/2017/06/21/twist-is-slack-without-the...
Most of my friend were unable to understand the UI. The thing was sloooooow. Trying to do anything meaningful would require a lot of tinkering.
it looks a bit more complicated than the Slack one, because of the thread/comment difference, but the "Automatic URL Report" and "Loop in" email based input looks very powerful as well.
But Twists API to create either thread/comment in an integration will be more complicated to do than Slack and their attachments are not very powerful (yet?), migrating our existing Slack related code might proof difficult.
We have been using Slack as a UI for our backend services, for example, and it is a great way to present reports and alerts, and offer basic controls to the relevant person. For me, whether or not I actually adopt Twist will depend on how easily I can interact with it from my own software.
I would suggest making the integrations page easier to find - I had to troll through the Zendesk archive to find it, even though it is a core feature. Also, a link to the API docs on the help page would be nice. (Edit: Didn't realize until now that integrations are at the channel level, not the top level.)
API docs: https://doist.gitbooks.io/twist-api/content/
The main reason I kept the desktop app, is so that I don't need to "download" the app every time my browser's cached copy is invalidated or expires. But being able to start the app with a couple keystrokes from my OS's quick launch menu is also nice.
I guess it's too early for me to evaluate the performance of Twist, because I am not on any large teams there. But I can see that Slack at least, has room for improvement in rendering performance. Perhaps there is some general optimization they are missing out on, like immutable state + shouldComponentUpdate. That one saved a flailing app of mine in the past.
I'm in Firefox on Linux, i7-4500U, 8GB ram.
Email is great and we are fans of it, but not for internal team communication.
[rehash of email is bad]
So, like slack, snoozed, but looks like email? When I need to put my head down to get stuff done I switch stuff off, which appears to be the easier option.Email never interrupts me. I have all audible and popup notifications turned off and generally check if I have new email only when it suits me. I make this super fast and simple by checking if my email icon on my phone has a little red number. Takes two seconds. If I have email, I can read them, if I don't, great.
Like you, I use filters and labels to keep my inbox clean. Automated emails and mailing lists get filtered away right away (and I check them manually when I feel like it). My inbox itself then takes a few seconds to clean leaving only stuff I have to act on. I use the Spark mail client which is very similar to google inbox in that I can quickly deal wia h messages or "snooze" those I can't deal with right now.
This way, I have zero unread messages in my inbox most of the time. (And I get OCD when I see other peopl ea phones or screenshots with 30k unread messages... wtf is wrong with people!)
I only see a proprietary email service here, one that cannot be used with other existing solutions. Why not build this on top of the current email protocols and offer a good client for reading it and an easy way to setup a mailing list (with an easy way to browse the archives)? That way this could be used with other clients and existing mail bots. No need for another integration API or to install another bloated client. If the user experience is really what sets this apart from mailing lists then you shouldn't have problems monetizing it.
Also the point about
> An email inbox is essentially just another list to manage.
Twist is the same, but everyone already has an email account, why should I add yet another one?
The server/client mechanism is robust and scalable. With a good client UI, it could be turned into quite a smart social/work platform.
I've been toying with attempting such a NNTP client, but it's way down on my list of projects.
The idea that is different here is that it is an invite only system - meaning no spam.
The first question that came up for me was 'who do I invite' - I had to think who in the team is an early adopter and would be receptive to trying something new. Then my next thought was to Hangouts them and tell them what I was doing so they did not see an invite for something unknown... then I thought... Why don't I just email them... and lastly... Why am I doing this again? I have already everything I need to talk to them... What is the advantage of this service?
As it stands, I get very little spam.
So what is the value prop?
Much of what I am reading is that it has better thread handling - I will assume that it does. I have also read the part where it is better for new team members - I get that, a new member can pop in and see the trail (how often that would actually happen? - unknown). I also read the sync vs async argument - sure, I like async but at times I need sync, like hard sync with red lights and bells (sms and whatsapp + phone calls and knocking on doors at night).
I think at the core there is a kernel of greatness that can be built upon: Everything is a 'topic' and has potential triggers to external systems. I think this could be a system that has everything in it eventually. If a topic is a lazy topic then it could be tagged as such, for example a message about next weeks dev lunch, but if the site is down then tag it with a critical tag and the alarms could go off. I see the real power here is that it can be connected to external things much better than email can without significant rfc822 parsing. There is opportunity here to supplant your current email stream.
The other coolness I can see is the potential for archiving everything - I think in certain circumstances Hangouts is too ephemeral. Daily standups should be recorded for remote teams or brainstorming sessions for SR&ED (Canadian tax thing). Even whiteboards and phone calls should be archived against a topic. Connect the system to a SIP service and all calls about a topic could be logged. Perhaps WebRTC would be the cool kids way of doing things.
I would use a service that recorded everything (that I wanted to be recorded) and had ways of moving from async to hard sync fluidly.
Of course, you can set up email group systems with archiving and search in those, but... that's more work, now you may have multiple systems for people to have access to, etc.
systems like this are logical extensions of the ceremony of email with some added benefits.
1. Must all messages be thread topics or thread replies? 2. Are messages presented in the order they were sent/recieved or in some grouping based on thread? 3. Can messages be "re-threaded" so that replies i. become their own thread topic? ii. become a reply to a different thread?
From my own research, it seems the answers are:
1. yes, all messages are either thread topics or replies; 2. messages are only grouped by thread and can't be seen as a stream where real-time communication across threads can happen; 3. and, no, messages cannot be re-threaded.
Which, if true, I think makes it decidedly worse than Flowdock. Its true that Flowdock also does not support re-threading and for that I will eternally hate Rally/CA for never adding but in all other aspects where Flowdock attempts to be something fundamentally different than email, Twist attempts to be, like Slack before it, an email killer.
For Flowdock default communication in a channel is just a message and only reifies into a thread topic when it recieves a reply. Also, the default presentation of messages is "real-time" group chat with color coding to identify threads and a dedicated thread viewer to "focus" on a single discussion if needed. Essentially Flowdock is standard group chat with an admittedly useful organizational concept of threads.
Twist seems to strip out the "group chat" part, leaving only threads and at that point I kind of agree that its just sexier email. I'd argue the whole reason Flowdock (or similiar) is necessary in addition to email is it reduces the barrier of what is "message worthy". If I want to send a message about my dog as an email, that feels weird. If I want to send the same message to a channel in Flowdock it doesn't; it may even become a thread but it doesn't disrupt useful work going on in other threads. Twist seems like it falls decidedly in the first camp and _that_ is why I won't switch to it from Flowdock. I simply can't use it for water-cooler style communication (group chat - Slack, Flowdock, even AIM win here) or productive real-time focused discussion _across problems_ (multi-threaded group chat so that one thread can dovetail/inform another in the public discussion - this is a Flowdock only thing AFAIK). The only problem it seems to solve is productive focused discussion on a single topic and honestly email already does that very well.
I will say searching is nice; of course, Flowdock has that too (as does Slack and many internet-based email solutions).
A threaded store and forward system works better for that as it allows new participants (members of the team) to read back in the historical documents about what happened before and what outcomes were created.
The three pillars of communication appear to me to be:
Time sensitive; communication of the specific moment (calendars are included here)
Evolved knowledge; communications of the group which represent the evolution of the group understanding of processes, challenges, and solutions.
Directive/Command; communications which direct individual or group action and recover group status.
The typical solutions fall into 'chat/calendar', 'news/bulleitin board', and 'email'
The knowledge you get at school or college is a kind "onboarding" new members. But it doesn't make you read every single piece that was ever written. You get a summary of both events and outcome, and most importantly the current state.
That's also how Wikipedia works: Articles don't get longer and longer, you can also summarize and put stuff into perspective. That's why there is a way to delete stuff (with version control, of course).
Moreover, onboarding new people (or maintaining the collective memory) isn't the only form of communication that happens in a team. Maybe it's not even the most important.
What about coordination? On the smaller stuff, on the daily stuff, but also on the bigger picture?
Now it you want to create a product/company out of that practice, then you would build a system that would let people reviewing messages be able to 'vote them up' based on their importance to the over all work product. That sort of 'auto curation' would then let you scan just the list with a 'curation threshold' and just read the important bits rather than everything in the list.
That might be a good compromise between a dedicated historian/textbook writer and a list which had all the data but it was inter spersed with the occasional "lets gets the group together for a movie / which movie" discussion.
Same if you bring new team members up to speed by talking to that person.
There is typically no single "historical" document that does the job. Old documents (e-mails, descriptions, comments, ...) tend to be outdated. New documents tend to be increments, so they don't really make sense if you don't know what is written in the old documents.
I expect that in the near future, automatic summaries based on NLP would be able to do all the heavy lifting, so the head of engineering (or whoever is in charge) will only edit the doc, not write it from scratch.
I'm the co-founder of https://www.fwdeveryone.com, which implements the same sort of functionality on top of email. This way you can capture both the knowledge created within your organization, and also conversations between your coworkers and people outside your business. There is no new client to adopt, and your data already comes pre-exported into your gmail or google apps account. And if you have a conversation you'd like to share publicly then we provide tools, like requesting permission and redacting sensitive info, to make this easy also, e.g.: https://www.reddit.com/r/Connecticut/comments/65kbok/good_hi...
Wikis are great, but maintaining them is basically a full time job, which is why they tend to be terrible and out of date. And even in cases where you have a PM maintaining your wiki full time, the majority of organizational knowledge is still locked up in email. Given that the amount of personal non-spam email sent every day is something like 100x the total size of Wikipedia, it seems unlikely that chat programs, email replacement solutions, or wikis can ever really be a complete solution.
Also, everyone already knows how to write or respond to an email, but many people within organizations don't know how to do simple things like making an account on a website. It sounds like a trivial problem, but we've found that having a system where everyone can contribute without having to learn anything new is actually a big win.
Good documentation is a full time job, via Wiki or whatever. It's not the Wiki's fault it's out of date.
Being able to use DKIM and SPF to authenticate threads is part of our value proposition, and a key part of the value proposition of email in general. (For example, being able to prove that you agreed on X project requirements with a certain person on a certain date.) Doing this type of authentication requires every message in a thread, not just the last one, so the most pragmatic way to meet this requirement is to work with email service providers with available APIs. The alternative is storing the entire contents of your inbox, but this doesn't make sense until we're ready to roll out our enterprise offering.
And we also have a very powerful API: https://api.twistapp.com/
And we are working on a lot more integrations.
What were the issues that Google Wave had? Why didn't it succeed?
Google was unable to properly explain to people what wave did and why they should use it, then killed it after 2 years citing adoption numbers.
One thing that would make me consider it, if I could open multiple windows at the same time for example.
I know they spent a couple years getting to this point, but I can really appreciate the quick, well-designed iOS app, and the native, non-Chromium / non-Electron Mac app that only uses 35MB of RAM and has no noticeable idle CPU draw. It's such a stark contrast with Slack and most of today's pseudo-native apps.
Impressive launch!
It's more a mix of wiki+email+chat.
And it's good.
I think internet went wrong way to ditch traditional internet forums/discussion groups/ and internet communication started to be based on real time chats (Slack, Messenger, Skype etc.), but I'm glad that we're returning to the oldschool (I'm waiting for Facebook to introduce "threads/topics" on its groups, because now Facebook groups are less functional than plain old phpBB.
[ Problem ]
- Meetings have the potential to really keep a team together
- Teams are distributed throughout geography, time zones or daily life patterns
- So how to bring GOOD meetings online, and perhaps even make them asynchronous?
"Meetings" come in different flavors, for example
- Weekly or monthly meetings to look back, learn, and discuss how to move on
- Daily scrum / daily standup to get a shared view of the day
- Ad hoc meetings to address a smaller but immediate issue
- Water cooler meetings which allow for serendipity
...
So for meetings in person, the real challenge is to get everyone attending, even if there is lot of urgent / important work to do. On the flip side: Keep the signal / noise ratio of the meeting so everyone feels it's time well spent.
[ Solution ]
So my vision for a better tool would include:
- Separation of reading mode and writing mode. You should be able to write in the sense of offloading thoughts without the need / option to read through everyone else's notes at the same time
- Asynchronous default. Stuff you write should be considered a draft until intentionally "published" (exception: urgent stuff / water cooler stuff). That would allow revising bigger thoughts before a "meeting".
- Even asynchronous, virtual meetings should have schedules. So for "daily" meetings, there should be a function that makes sure that everyone reads and writes at least once a day. For "monthly" at least once a month, but without that becoming a continuous "monthly meeting", which wouldn't allow to really focus on it.
1. Hitting "Enter" doesn't send the message. This encourages writing actual paragraphs in response, rather than sending fragments of sentences
that can be interrupted across multiple lines
because you're not really sure if you've finished your sentence just yet
oh and you thought of one more thing so everyone else please take this line into consideration as well
Of course, you might say "train your team to not do that." Sure. But I'd rather use a tool that doesn't require breaking (perhaps reasonable) habits. And if communication shouldn't be through short bursty chunks by default, why make that the easiest thing to do?
2. Make threads more of a default way to respond, and make thread comments first-class citizens. Presented with the UX of Slack, it's really hard to move yourself towards using threads because the easiest way to respond to things is to type and hit enter. Also, threads live in their own "All threads" space, not organized by channel. Thread comments aren't first-class citizens like regular chat is because they can't have files attached, be posts or snippets, etc, so sometimes it feels like I actually _lose_ functionality by starting a thread.
Twist looks like it has what I love about Slack – good for newbies to join in and see organized, curated history (I can't show new folks _my_ inbox labels and organization, or spin up a new channel on a mailing list for each topic we want to discuss), good for lurking on projects that aren't your own but are related, and has emoji responses for celebration, quick feedback, and commiseration.
That said, in 3 years at Slack-heavy companies, the level of interleaved conversation I've encountered is almost nil. Maybe that's cultural (though the consistency across multiple companies and teams suggests not). Maybe company or team size is a factor. Maybe it's a matter of breaking it out into enough channels that if there are multiple topics to discuss at once they're usually happening in separate channels anyway.
Sure, Slack could probably improve the threads UI. (Though I happen to think that threaded display and real-time discussion are in some ways conflicting goals.) As it stands, however, they're a black hole. My team has actually banned the use of threads (and no, it wasn't even my suggestion).