4 Jun
2018
4 Jun
'18
6:15 p.m.
Hi,
(sorry for not reading the discussions above, I hope to get to read them at
some point)
I just wanted to remind you that:
1. We (at least I did) have previously concluded that it was a *mistake* to
mix notifications with messages.
1.1 Notifications have transient lifecycle and can be easily discarded. The
previous ActivityStream implementation actually had a periodic
notifications/events cleaner that would automatically delete events older
than (e.g.) 30 days, for both storage and performance reasons.
1.2 Messages have a much longer lifecycle, some users choosing to never
delete them and keep record of all conversations they ever had with someone.
1.3 Mixing storage for the 2 is a recipe for disaster, IMO, and, if/when we
plan to handle it seriously, we should either implement or integrate a
separate solution for messaging, both on the storage and the UI level. IMO,
the biggest intersection between Notifications and Messaging is the ability
to receive a notification about the fact that you have received a message
from X. Reading the message and acting upon it (i.e. replying, etc.) should
be done in the dedicated UI of the Messaging Application (i.e. inbox/etc.).
2. We *don't have to* and *shouldn't* keep all the features of the previous
system. Instead, this was supposed to be a good opportunity to improve on
our previous mistakes, not repeat them, in a new and improved system.
3. The Network/Follow feature is still a nice feature to stay up to date
with the activity of some users of interest. The "Send message to
followers", however, is, IMO, outside the scope of Notifications.
4. When talking about Messaging, we can also distinguish 2 types of
messages: public and private.
4.1 Private messages should, IMO, necessarily be addressed with the
Messaging application detailed at 1. Also, private messages need to be
trustworthy, as they can/do usually contain sensitive information. The data
should not be deleted and it should be properly protected.
4.2 Public messages, that have a more transient nature, could be the scope
of some "Announcements" application, that could behave as Notifications.
Couple that with the ability to interact with events (i.e. reactions or
comments on the page displayed under the event) and you get a very live and
social environment.
Thanks,
Eduard
On Thu, May 31, 2018 at 7:19 PM, Vincent Massol <vincent(a)massol.net> wrote:
Mostly because user messages (as in private, user to user messages) can
be related from one to another (ie : the message B that you just sent me
is a response from the message A that I sent you). You will then need
some context to display the response from someone in your notification
center. I don't think that we have an easy way to do that now.
We could actually (since the event stream allows for 4-5 custom params).
However, I wouldn’t do answers FTM (I don’t think we had this before
either). Just ability to send messages.
UserMessageNotifications#HUserMessages
UserMessageNotifications#HUserMentions
UserMessageNotifications#HAppNotifications
On 31 May 2018, at 18:07, Clément Aubin
<aubincleme(a)gmail.com> wrote:
On 05/31/2018 05:44 PM, Vincent Massol wrote:
>
>
>> 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:
>>
>> […]
>>
>>>> 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?
>>
>> 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.
>
>>
>>> 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.
>
> I know and out of scope for now.
>
>>
>>>> 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”
>>
>> Please don't rephrase me like that :) . The current notifications are,
>> IMO correctly displayed (and we're not debating about how to display
>> notifications AFAIK).
>
> Sorry I meant ‘displaying messages in the notifications UI in the
proposed way
is a 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.
>
> It’s not proposed FTM. Maybe you’re mixing the display of messages when
there
are some with the messageSender macro usage on the dashboard?
I'm talking about user messages as in [1] ; so private, user to user
messages.
>> 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.
>
>>
>> […]
>>
>>>> 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…
>>
>> 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!
>
>> 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.
>
>>
>> […]
>>
>>>> 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”.
>>
>> 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.
>
>>
>>> 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 don’t understand your point. Why would a user tune anything? A user
simply
says what notifications they’re interested in seeing.
>
> If they select too many then they’ll have the same issue you have with
email
:)
>
>>
>>>
>>>> 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.
>>
>> See the beginning of my response.
>>
>>> 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.
>
> A message is an event for which the content is defined by the user. Not
sure
what you mean.
Not sure about what you mean too then … following your definition, [1]
is then a user message and [2] and [3] are not. At least, that's what I
understand as "user messages”.
I was trying to understand what you meant by “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.”.
Messages *ARE* implemented using the event stream :)
Thanks
-Vincent
>>
>>> * 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)") ;)
>
> What? You lost me completely here.
>
> Why does it discourage discussions to implement something?
>
> If you’re interested in working on a chat system in xwiki, please knock
yourself up and start a proposal/discussion. Nobody is preventing you from
doing that.
Thanks
-Vincent
>
>> * 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://design.xwiki.org/xwiki/bin/view/Proposal/