41–50 of 81 posts
Google Wave came out a few years too early...
Na the reason Google wave failed was that the idea was great but the realization sucked. 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.
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…
I hate to say it but I concur... mostly. 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... th…
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.
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…
Why not just use email? This was asked by a ton of people and we have addressed it here: https://help.twistapp.com/hc/articles/115003654589 Email is great and we are fans of it, but not for internal team communication.
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?
[ 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.
They keep saying it’s not email, but it looks a lot like email with preconfigured filters. What am I missing? What’s so mindful about this?
It's more a mix of wiki+email+chat.
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…
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…
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).
How is this different from Google Wave, besides being less clunky? How will it overcome the adoption issues that Google Wave had?
What were the issues that Google Wave had? Why didn't it succeed?
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…
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'
Earlier quoted context omitted.
Curious: I've always used slack from a web browser rather than their native app. What, if anything, do you personally miss from the web app in slack?
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.