31 May
2018
31 May
'18
5:44 p.m.
On 31 May 2018, at 17:28, Clément Aubin
<aubincleme(a)gmail.com> wrote:
On 05/31/2018 04:42 PM, Vincent Massol wrote:
[…]
Oh I'm sure that you didn't said that, but this would need a more
in-depth investigation, and not just 2 days of implementation.
No no this is out of scope for now.
I'm
here describing my own usage of collaborative platforms or social
networks. If it wasn't supported before today, maybe we should think
about it, because usually, people with only one friend to talk to are
rare. Having multiple conversation is something that we should at least
think about.
Did I say we should not think about it? Also as I wrote you can send to a group and to
everyone too so yes you can send to multiple people.
I'm not talking about sending a message to groups, but to multiple
individuals. Also, as
you mentioned it in the end of your previous mail, "if we do
nothing now, nothing will happen for at least 1 year", what makes you
think that we'll have the time to improve the feature later on, even if
we do need it ?
Ok so we have a big disagreement:
* You say “displaying notifications in the proposed way is bad thing and there’s no use
case for it” However, I don't think that the notification
center has been crafted to correctly display user messages. Merging
events coming from the wiki and messages coming from the message stream
is tricky.
Why? They’re both coming from the same location, i.e. event table…
* I say “‘displaying notifications for those who
want to send messages to a single person, to a group or to everyone is better than not
being able to do it”.
Also note that it’s disabled by default ATM so by default you get what you want, i.e.
nothing!
It's disabled by default for now, but it's actually proposed to enable
it, else the proposal (2) would not make any sense. That also raises a problem : how can I be sure that
you will be able to
receive my message if I don't know in advance if you have enable or
disabled your ability to receive messages in your notification preferences ?
The proposal Guillaume is implementing is to have them enabled by default.
But indeed that could be refinement in the future that you can’t send messages to someone
if they have disabled the reception. It’s out of scope though.
[…]
Ha ok, indeed, I didn't though about a non-live implementation of a
messaging system. IMO that's still something old (as nowadays, almost
every messaging system are live, even on forums and boards, that used to
propose this idea of personal messages a lot).
email is old but the most used system :) So old doesn’t mean useful!
Yes, this
is a feature that is also nice to have for all kind of
notification, however, this is what I mean by "shipping a half finished
feature" : messaging is something done in real time.
Again we don’t agree about this. We’re not implementing a chat. We’re implementing
message sending as in email sending. Live message sending is another feature.
If you forget to
refresh your page, you forget to get new messages. Imagine if you had to
refresh a page every time you wanted to see a new message on IRC.
This is exactly what you do with your email and I don’t think you can say that email is
useless… This could be an improvement idea if and only if we
have an "inbox" or
something in which we can put the messages that a user received in order
for him to check on them later.
Yes notifications is an inbox for notifications. We have that already. you can even ack
them.
[…]
Using your example, you're not just displaying emails, you're also
displaying a ton of notifications about the documents that have been
updated in your wiki.
We’re displaying notifications.
So
we're putting back something that has been disabled by default since
more than one year without giving it enough features to be usable for a
standard user (things like being able to get messages in real time, for
example). For me, it's both a waste of time, and this might even degrade
the image of XWiki as it (IMO) won't be a very useful feature.
I disagree with you and I’ve already explained in details the reasons in a bullet point
list.
I think that sending messages into the event
stream was kind of a bad
idea from the beginning as messages don't have the same "weight" as
other wiki events.
The event stream has nothing to do with weight. It’s a timeline thing. It’s like saying:
“having emails displayed in the order they are sent is a bad idea”. The way even stream events are displayed is an
implementation detail. They can be filtered, grouped, etc.
I don't think that you should require a user to tune his notification
preferences in order not to be flooded by notifications. Having messages
is kind of a risk here because this implementation detail does not
protect the user enough from the messages hiding other important events. I do understand that you don't like loosing
features,
but since I've known XWiki, I've never heared of the Message Stream in a
good, useful and productive way.
Then you shouldn’t care at all since it’s not going to be used and you’re not the one
implementing it. It’s also off by default. So reading between the line, in the end you’re
saying:
* We shouldn’t have a messaging feature because what we need is a chat feature
Actually, I don't think that a chat feature would be mandatory, but I do
think that it would be more attracting to people.
* There’s no way that people could use messages,
it’s not useful
I see some use cases for live messages, but I'm indeed having a hard
time seeing use cases for non-live messages as people can use another
chat tool aside from their wiki if we don't propose an "inbox" solution.
It won't be reliable to send a message as :
* It can be filtered out by the recipient notification preferences
* It can be ditched in the bottom of the notifications of a user if he /
she does not clean his / her notifications quickly enough
* There's no way to access this message once the notification center has
been cleared
What I’m saying:
* We don't have chat feature and that’s a very large feature to develop with a
completely different architecture.
At least we agree on that :)
* A messaging feature is still interesting even
if we have a chat feature one day. Example use case: "send a message to everyone that
the xwiki will be be upgraded tomorrow”, “ notify a group of person to review a document”,
etc.
Note that what you described are events and can actually be implemented
using the event stream, so I'm not sure that those are correct examples. * It costs little to be back to iso feature (1-2
days) and it’s taking almost the same amount of time just to discuss not doing it in this
thread ;)
I don't like this idea as this is kind of discouraging the discussion on
features that we have to put in the platform ([1], especially "Ensure
agreement on the work being done (it's too stupid to do a lot of work
and only find when it's finished that it wasn't the right way to do it
and it has to be all redone again)") ;) * I don’t see why messaging would be bad and
affect the XWiki usage
negatively. Especially since message stream is off by
default.
See the beginning of my response.
Thanks
-Vincent
Thanks,
Clément
[1]
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneral…