Compare commits
1 commit
main
...
post-mm-th
Author | SHA1 | Date | |
---|---|---|---|
e9f07f105e |
1 changed files with 72 additions and 0 deletions
72
content/posts/im-threads.md
Normal file
72
content/posts/im-threads.md
Normal file
|
@ -0,0 +1,72 @@
|
|||
---
|
||||
title: "IM Threads"
|
||||
date: 2018-09-22T22:00:00+01:00
|
||||
draft: true
|
||||
---
|
||||
|
||||
I have had the opportunity to use [Mattermost](https://www.mattermost.org) for
|
||||
over a year, and I thought I would give some feedback on a feature I still
|
||||
have troubles dealing with: **threads**.
|
||||
|
||||
A bit of a disclaimer, Mattermost is the only solution of its kind
|
||||
(centralized, non-standard, one blessed client) that I have used extensively.
|
||||
I do not use Slack, Gitter, Discord or what have you. I generally use XMPP and
|
||||
IRC (via XMPP), in my terminal.
|
||||
|
||||
I haven't gone through all the stages of grief yet concerning this topic, so
|
||||
please bear with me. This article addresses usability issues with the web
|
||||
client. I do not have solutions to offer, but I hope that my criticism will be
|
||||
taken into account, and I would be happy to work with the project to try and
|
||||
improve the feature.
|
||||
|
||||
## What I understand people want
|
||||
|
||||
- A way to group discussions by topic.
|
||||
- Being able to talk without having to state context all the time.
|
||||
- Being able to refer to these discussions in their integrity, (via some URI,
|
||||
or else), to even read days later.
|
||||
- Not having to highlight every concerned party in every message.
|
||||
- Not being highlighted if you are not part of it
|
||||
|
||||
Out of context this feels like people just wanted _channels_, because this is
|
||||
exactly what I described, but certainly details are important here. What I
|
||||
think people want is _fine grained_ all-of-the-above, that is, have usual
|
||||
channels set a common topic, e.g., "programming", and be able to split
|
||||
discussions happening in this channel even more, with some kind of nested
|
||||
channels, or threads.
|
||||
|
||||
---
|
||||
WIP
|
||||
|
||||
This last bullet point is actually the most important part.
|
||||
|
||||
## Implementation case study
|
||||
|
||||
Mattermost, as other IM solutions, regroup most of these features under what
|
||||
they call __threads__.
|
||||
|
||||
I'll try to report a couple of things to upstream if possible, in the
|
||||
meantime here's what I think about it:
|
||||
|
||||
- In MM: missing fork feature: after 3 messages in a thread it's already
|
||||
diverged from the original discussion, and might get back to it at some
|
||||
point later on. What changes from a normal channel?
|
||||
|
||||
- In MM, UI is unintuitive:
|
||||
* Not easily accessible. You have to move your pointer to the small icon at
|
||||
the far right of your screen.
|
||||
* No keybindings to navigate between threads, that makes them a hard to use.
|
||||
* Thread messages appear in the channel, that makes the whole thing
|
||||
unreadable when there are multiple threads active at the same time.
|
||||
* Bug? threads window not scrolling down automatically.
|
||||
* possible resolution: change into short-lived channels?
|
||||
* Can only have one thread opened at a time. That means if I want to follow
|
||||
a thread, I can't reply to/follow any other threads.
|
||||
|
||||
- Too much micro-management to get right
|
||||
|
||||
|
||||
- Mattermost should allow users to attach anything (Direct Messages, Channels)
|
||||
where the current thread UI lives, so they don't have to start a "fake thread"
|
||||
just to be able to counter the limitations of the tool. Especially in 1:1
|
||||
Direct Messages, where most of the benefits of threads are moot.
|
Loading…
Reference in a new issue