[Proposal] Display user messages in the notifications.

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] Display user messages in the notifications.

Guillaume Delhumeau
Notifications application is almost ready to replace the Activity Stream's
UI. The only remaining thing is the display
of the messages from the Message Stream in the Notifications.

We have made a quick brainstorming with Caty and Vincent, and here is our
conclusions.

1/ We think it make sense to display user messages in the notifications
because it is typically what notifications
are made for: pop-up important information concerning what the user cares.
In the past, we decided to disable the
Message Stream by default because messages were lost in the Activity
Stream. But in the case of the notifications, users
can chose what they want to receive so there is less chance to miss
messages in the middle of thousand of events.

2/ Like all other types of notification, there should be a button in the
notification settings of each user to decide to
enable or disable these messages in the notifications. It should be enabled
by default.

3/ We should add the "send message" gadget in the "alert" menu (via an UIX)
so it's easy to find and to send messages.

4/ Provide a form to be able to reply to a personal message.

5/ Let the message stream disabled by default. Users who are used to it
will not lose the feature but we don't make it
visible for now until we make some other improvements.

This is what I am starting to implement right now with the hope it's done
for XWiki 10.5.

In the future, we should add the following features:

a/ Having a real "inbox" application (a "Message Center") to handle all
messages.

b/ Be notified when someone mention you in a content or in a comment
(example: "@vmassol: You may want to read this
page" will trigger a notification to Vincent Massol).

c/ Handling correcty messages sent to a group if the first implementation
do not handle it (group filtering could be a problem
with SQL).

Caty, Vincent, please reply if I've forget something.

All others: if you have any recommendation or counter argument, please post
it quickly :)

Thanks for you time and have a great day,

Guillaume

--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

Marius Dumitru Florea
On Thu, May 31, 2018 at 12:46 PM, Guillaume Delhumeau <
[hidden email]> wrote:

> Notifications application is almost ready to replace the Activity Stream's
> UI. The only remaining thing is the display
> of the messages from the Message Stream in the Notifications.
>
> We have made a quick brainstorming with Caty and Vincent, and here is our
> conclusions.
>
> 1/ We think it make sense to display user messages in the notifications
> because it is typically what notifications
> are made for: pop-up important information concerning what the user cares.
> In the past, we decided to disable the
> Message Stream by default because messages were lost in the Activity
> Stream. But in the case of the notifications, users
> can chose what they want to receive so there is less chance to miss
> messages in the middle of thousand of events.
>
> 2/ Like all other types of notification, there should be a button in the
> notification settings of each user to decide to
> enable or disable these messages in the notifications. It should be enabled
> by default.
>
>

> 3/ We should add the "send message" gadget in the "alert" menu (via an UIX)
> so it's easy to find and to send messages.
>

I'm not very convinced by this. It will clutter the notification menu. An
alternative is to show just an icon/button on the notification menu, that
opens a popup (modal) with the form to send message.


>
> 4/ Provide a form to be able to reply to a personal message.
>
> 5/ Let the message stream disabled by default. Users who are used to it
> will not lose the feature but we don't make it
> visible for now until we make some other improvements.
>
> This is what I am starting to implement right now with the hope it's done
> for XWiki 10.5.
>
> In the future, we should add the following features:
>
> a/ Having a real "inbox" application (a "Message Center") to handle all
> messages.
>
> b/ Be notified when someone mention you in a content or in a comment
> (example: "@vmassol: You may want to read this
> page" will trigger a notification to Vincent Massol).
>
> c/ Handling correcty messages sent to a group if the first implementation
> do not handle it (group filtering could be a problem
> with SQL).
>
> Caty, Vincent, please reply if I've forget something.
>
> All others: if you have any recommendation or counter argument, please post
> it quickly :)
>
> Thanks for you time and have a great day,
>
> Guillaume
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

vmassol
Administrator
In reply to this post by Guillaume Delhumeau
Hi Guillaume,

> On 31 May 2018, at 11:46, Guillaume Delhumeau <[hidden email]> wrote:
>
> Notifications application is almost ready to replace the Activity Stream's
> UI. The only remaining thing is the display
> of the messages from the Message Stream in the Notifications.
>
> We have made a quick brainstorming with Caty and Vincent, and here is our
> conclusions.
>
> 1/ We think it make sense to display user messages in the notifications
> because it is typically what notifications
> are made for: pop-up important information concerning what the user cares.
> In the past, we decided to disable the
> Message Stream by default because messages were lost in the Activity
> Stream. But in the case of the notifications, users
> can chose what they want to receive so there is less chance to miss
> messages in the middle of thousand of events.
>
> 2/ Like all other types of notification, there should be a button in the
> notification settings of each user to decide to
> enable or disable these messages in the notifications. It should be enabled
> by default.
>
> 3/ We should add the "send message" gadget in the "alert" menu (via an UIX)
> so it's easy to find and to send messages.

We actually mentioned that this would be for later and that Caty would start an investigation on this.

> 4/ Provide a form to be able to reply to a personal message.

Same here (for later).

> 5/ Let the message stream disabled by default. Users who are used to it
> will not lose the feature but we don't make it
> visible for now until we make some other improvements.

Actually we didn’t talk much about this. But we can decide what we do once the support is back in the notifications UI.

> This is what I am starting to implement right now with the hope it's done
> for XWiki 10.5.

Note that points 3 and 4 are not meant to be implemented now. FTM just displaying the messages in the Notif UI.

> In the future, we should add the following features:
>
> a/ Having a real "inbox" application (a "Message Center") to handle all
> messages.

We didn’t really discuss this. But this should go in Caty’s investigation.

> b/ Be notified when someone mention you in a content or in a comment
> (example: "@vmassol: You may want to read this
> page" will trigger a notification to Vincent Massol).
>
> c/ Handling correcty messages sent to a group if the first implementation
> do not handle it (group filtering could be a problem
> with SQL).

Yes we said the first impl will support at least messages sent to a user and to all.

Thanks
-Vincent

>
> Caty, Vincent, please reply if I've forget something.
>
> All others: if you have any recommendation or counter argument, please post
> it quickly :)
>
> Thanks for you time and have a great day,
>
> Guillaume
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

caubin
In reply to this post by Guillaume Delhumeau
Hi,

On 05/31/2018 11:46 AM, Guillaume Delhumeau wrote:

> Notifications application is almost ready to replace the Activity Stream's
> UI. The only remaining thing is the display
> of the messages from the Message Stream in the Notifications.
>
> We have made a quick brainstorming with Caty and Vincent, and here is our
> conclusions.
>
> 1/ We think it make sense to display user messages in the notifications
> because it is typically what notifications
> are made for: pop-up important information concerning what the user cares.
> In the past, we decided to disable the
> Message Stream by default because messages were lost in the Activity
> Stream. But in the case of the notifications, users
> can chose what they want to receive so there is less chance to miss
> messages in the middle of thousand of events.
>
> 2/ Like all other types of notification, there should be a button in the
> notification settings of each user to decide to
> enable or disable these messages in the notifications. It should be enabled
> by default.
>
> 3/ We should add the "send message" gadget in the "alert" menu (via an UIX)
> so it's easy to find and to send messages.
>
> 4/ Provide a form to be able to reply to a personal message.
>
> 5/ Let the message stream disabled by default. Users who are used to it
> will not lose the feature but we don't make it
> visible for now until we make some other improvements.
>
> This is what I am starting to implement right now with the hope it's done
> for XWiki 10.5.
>
> In the future, we should add the following features:
>
> a/ Having a real "inbox" application (a "Message Center") to handle all
> messages.
>
> b/ Be notified when someone mention you in a content or in a comment
> (example: "@vmassol: You may want to read this
> page" will trigger a notification to Vincent Massol).
>
> c/ Handling correcty messages sent to a group if the first implementation
> do not handle it (group filtering could be a problem
> with SQL).
>
> Caty, Vincent, please reply if I've forget something.
>
> All others: if you have any recommendation or counter argument, please post
> it quickly :)

I don't have a good knowledge of the "old" message stream
implementation, however, I'm concerned about the ability of the
notification system to act as a messaging center.

- When working on multiple documents, I might end up talking with
multiple people at the same time. What would happen to the notification
center ? Would I have a composite event with all of my conversations in
it, or one composite notification per user I'm talking with, which would
probably fill most of the notification center ?

- When being in a wiki, I might end up staying 1, 2 hours or more on the
same page, either to edit it or to read it and refer to it from time to
time. The messaging feature of the notification is interesting here if
and only if we have the ability to auto-refresh the notification center
every X seconds / minutes to check for new events or, in this case, new
messages. AFAIK, this feature isn't in place for now.

All in all, I'm very concerned that we try to ship a half finished
feature that cannot be used for real collaboration and that still takes
some place in the UI ; only to have an equivalent of a feature that we
disabled some years ago. If we want to promote messaging and more user
to user interaction in the wiki, maybe we should take more time to spec
it. If we had to vote for this, I'd say -0 for now.

> Thanks for you time and have a great day,
>
> Guillaume
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

vmassol
Administrator
Hi Clement,

> On 31 May 2018, at 14:56, Clément Aubin <[hidden email]> wrote:

[snip]

>>
>> All others: if you have any recommendation or counter argument, please post
>> it quickly :)
>
> I don't have a good knowledge of the "old" message stream
> implementation, however, I'm concerned about the ability of the
> notification system to act as a messaging center.
>
> - When working on multiple documents, I might end up talking with
> multiple people at the same time. What would happen to the notification
> center ? Would I have a composite event with all of my conversations in
> it, or one composite notification per user I'm talking with, which would
> probably fill most of the notification center ?

This is not supported ATM (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Message%20Stream%20Application/) so no issue FTM. You can only send messages to a given user, to a group or to everyone.

I don’t see a problem to add this feature later on if we need it.

> - When being in a wiki, I might end up staying 1, 2 hours or more on the
> same page, either to edit it or to read it and refer to it from time to
> time. The messaging feature of the notification is interesting here if
> and only if we have the ability to auto-refresh the notification center
> every X seconds / minutes to check for new events or, in this case, new
> messages. AFAIK, this feature isn't in place for now.

I don’t see this related at all to messaging. You have the same problem for any kind of notifications. This is related to live notifications and something generic for the notifications feature.

I don’t agree with "The messaging feature of the notification is interesting here if and only if we have the ability to auto-refresh the notification center every X seconds”. Again I don’t see why this is related only to messaging and also I find it more useful to have messaging than nothing (which is what you propose). I can imagine plenty of use cases where it’s still useful to have messaging without the auto refresh. I consider auto refresh to be a nice improvement to have not as a "must have or there’s no value”.

> All in all, I'm very concerned that we try to ship a half finished
> feature that cannot be used for real collaboration and that still takes
> some place in the UI ;

Maybe there’s a misunderstanding: We’re not trying to develop a messaging feature. This feature already exists and we’re not touching this.

All that we’re doing is add the ability to display messages in the notification UI if some messages are present in the Event Stream table.

This feature already exists today and not doing this would be to remove a feature that is now interesting to have thanks to the replacement of the AS by the Notifications UI.

> only to have an equivalent of a feature that we
> disabled some years ago.

We disabled it for 2 reasons and not for the reasons you mentioned above:
* Because the dashboard was on the home page and several users were not using the message sending UI and didn’t want it to take valuable space on the home page. This has been solved by moving the dashboard to a different space
* Because you couldn’t know when someone was sending a message to you and it was hard to check your personal AS (you had to nav to your user profile).

Those 2 problems are fixed so there’s no reason to not have it anymore.

> If we want to promote messaging and more user
> to user interaction in the wiki, maybe we should take more time to spec
> it. If we had to vote for this, I'd say -0 for now.

Yes and that’s why Caty is going to conduct a more general investigation on that.

I understand your POV and I don’t disagree with it in general. However, I feel that:
* I don’t like regressing/loosing features
* This is an opportunity to have something now. I can tell you that if we do nothing now, nothing will happen for at least 1 year
* We’re not redoing the messaging feature, just the display part in the notif UI
* I don’t see how there would much changes even if we spend 2 years designing a new messaging center.
* It’s not going to cost much (probably 1-2 days of work max). So at worse ,it’ll cost us 1-2 days if we had to redo everything.
* Also note that we're not changing the store or anything so even if we redo it completely differently it doesn’t matter and we will not loose anything
* This will allow us to gather feedback from the community about needs/improvements
* We can never implement a feature in one go. We need to work iteratively. We just need to make sure the architecture is not going to break. Since we’re not touching this part, there’s no real risk

So I really believe that it’s more positive than negative to spend this little time to display messages in the notif UI.

WDYT?

Thanks
-Vincent

>
>> Thanks for you time and have a great day,
>>
>> Guillaume

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

caubin
On 05/31/2018 03:18 PM, Vincent Massol wrote:

> Hi Clement,
>
>> On 31 May 2018, at 14:56, Clément Aubin <[hidden email]> wrote:
>
> [snip]
>
>>>
>>> All others: if you have any recommendation or counter argument, please post
>>> it quickly :)
>>
>> I don't have a good knowledge of the "old" message stream
>> implementation, however, I'm concerned about the ability of the
>> notification system to act as a messaging center.
>>
>> - When working on multiple documents, I might end up talking with
>> multiple people at the same time. What would happen to the notification
>> center ? Would I have a composite event with all of my conversations in
>> it, or one composite notification per user I'm talking with, which would
>> probably fill most of the notification center ?
>
> This is not supported ATM (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Message%20Stream%20Application/) so no issue FTM. You can only send messages to a given user, to a group or to everyone.>
> I don’t see a problem to add this feature later on if we need it.

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.

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 ?

>> - When being in a wiki, I might end up staying 1, 2 hours or more on the
>> same page, either to edit it or to read it and refer to it from time to
>> time. The messaging feature of the notification is interesting here if
>> and only if we have the ability to auto-refresh the notification center
>> every X seconds / minutes to check for new events or, in this case, new
>> messages. AFAIK, this feature isn't in place for now.
>
> I don’t see this related at all to messaging. You have the same problem for any kind of notifications. This is related to live notifications and something generic for the notifications feature.
>
> I don’t agree with "The messaging feature of the notification is interesting here if and only if we have the ability to auto-refresh the notification center every X seconds”. Again I don’t see why this is related only to messaging and also I find it more useful to have messaging than nothing (which is what you propose). I can imagine plenty of use cases where it’s still useful to have messaging without the auto refresh. I consider auto refresh to be a nice improvement to have not as a "must have or there’s no value”.

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. 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.

>> All in all, I'm very concerned that we try to ship a half finished
>> feature that cannot be used for real collaboration and that still takes
>> some place in the UI ;
>
> Maybe there’s a misunderstanding: We’re not trying to develop a messaging feature. This feature already exists and we’re not touching this.
>
> All that we’re doing is add the ability to display messages in the notification UI if some messages are present in the Event Stream table.
>
> This feature already exists today and not doing this would be to remove a feature that is now interesting to have thanks to the replacement of the AS by the Notifications UI.
>
>> only to have an equivalent of a feature that we
>> disabled some years ago.
>
> We disabled it for 2 reasons and not for the reasons you mentioned above:
> * Because the dashboard was on the home page and several users were not using the message sending UI and didn’t want it to take valuable space on the home page. This has been solved by moving the dashboard to a different space
> * Because you couldn’t know when someone was sending a message to you and it was hard to check your personal AS (you had to nav to your user profile).

Actually, I would be interested to know the other reasons for disabling
the Message Stream some time ago. In the original message ([1]), this
was the only point mentionned, but maybe Nicolas had more reasons.

> Those 2 problems are fixed so there’s no reason to not have it anymore.
>
>> If we want to promote messaging and more user
>> to user interaction in the wiki, maybe we should take more time to spec
>> it. If we had to vote for this, I'd say -0 for now.
>
> Yes and that’s why Caty is going to conduct a more general investigation on that.
>
> I understand your POV and I don’t disagree with it in general. However, I feel that:
> * I don’t like regressing/loosing features
> * This is an opportunity to have something now. I can tell you that if we do nothing now, nothing will happen for at least 1 year
> * We’re not redoing the messaging feature, just the display part in the notif UI
> * I don’t see how there would much changes even if we spend 2 years designing a new messaging center.
> * It’s not going to cost much (probably 1-2 days of work max). So at worse ,it’ll cost us 1-2 days if we had to redo everything.
> * Also note that we're not changing the store or anything so even if we redo it completely differently it doesn’t matter and we will not loose anything
> * This will allow us to gather feedback from the community about needs/improvements
> * We can never implement a feature in one go. We need to work iteratively. We just need to make sure the architecture is not going to break. Since we’re not touching this part, there’s no real risk
>
> So I really believe that it’s more positive than negative to spend this little time to display messages in the notif UI.
>
> WDYT?

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 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. 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.

Thanks,
Clément

[1] https://markmail.org/message/pw6wtx2lkn72rupv

> Thanks
> -Vincent
>
>>
>>> Thanks for you time and have a great day,
>>>
>>> Guillaume
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

vmassol
Administrator


> On 31 May 2018, at 16:23, Clément Aubin <[hidden email]> wrote:
>
> On 05/31/2018 03:18 PM, Vincent Massol wrote:
>> Hi Clement,
>>
>>> On 31 May 2018, at 14:56, Clément Aubin <[hidden email]> wrote:
>>
>> [snip]
>>
>>>>
>>>> All others: if you have any recommendation or counter argument, please post
>>>> it quickly :)
>>>
>>> I don't have a good knowledge of the "old" message stream
>>> implementation, however, I'm concerned about the ability of the
>>> notification system to act as a messaging center.
>>>
>>> - When working on multiple documents, I might end up talking with
>>> multiple people at the same time. What would happen to the notification
>>> center ? Would I have a composite event with all of my conversations in
>>> it, or one composite notification per user I'm talking with, which would
>>> probably fill most of the notification center ?
>>
>> This is not supported ATM (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Message%20Stream%20Application/) so no issue FTM. You can only send messages to a given user, to a group or to everyone.>
>> I don’t see a problem to add this feature later on if we need it.
>
> 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.

> 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”
* 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!

>
>>> - When being in a wiki, I might end up staying 1, 2 hours or more on the
>>> same page, either to edit it or to read it and refer to it from time to
>>> time. The messaging feature of the notification is interesting here if
>>> and only if we have the ability to auto-refresh the notification center
>>> every X seconds / minutes to check for new events or, in this case, new
>>> messages. AFAIK, this feature isn't in place for now.
>>
>> I don’t see this related at all to messaging. You have the same problem for any kind of notifications. This is related to live notifications and something generic for the notifications feature.
>>
>> I don’t agree with "The messaging feature of the notification is interesting here if and only if we have the ability to auto-refresh the notification center every X seconds”. Again I don’t see why this is related only to messaging and also I find it more useful to have messaging than nothing (which is what you propose). I can imagine plenty of use cases where it’s still useful to have messaging without the auto refresh. I consider auto refresh to be a nice improvement to have not as a "must have or there’s no value”.
>
> 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…

>
>>> All in all, I'm very concerned that we try to ship a half finished
>>> feature that cannot be used for real collaboration and that still takes
>>> some place in the UI ;
>>
>> Maybe there’s a misunderstanding: We’re not trying to develop a messaging feature. This feature already exists and we’re not touching this.
>>
>> All that we’re doing is add the ability to display messages in the notification UI if some messages are present in the Event Stream table.
>>
>> This feature already exists today and not doing this would be to remove a feature that is now interesting to have thanks to the replacement of the AS by the Notifications UI.
>>
>>> only to have an equivalent of a feature that we
>>> disabled some years ago.
>>
>> We disabled it for 2 reasons and not for the reasons you mentioned above:
>> * Because the dashboard was on the home page and several users were not using the message sending UI and didn’t want it to take valuable space on the home page. This has been solved by moving the dashboard to a different space
>> * Because you couldn’t know when someone was sending a message to you and it was hard to check your personal AS (you had to nav to your user profile).
>
> Actually, I would be interested to know the other reasons for disabling
> the Message Stream some time ago. In the original message ([1]), this
> was the only point mentionned, but maybe Nicolas had more reasons.
>> Those 2 problems are fixed so there’s no reason to not have it anymore.
>>
>>> If we want to promote messaging and more user
>>> to user interaction in the wiki, maybe we should take more time to spec
>>> it. If we had to vote for this, I'd say -0 for now.
>>
>> Yes and that’s why Caty is going to conduct a more general investigation on that.
>>
>> I understand your POV and I don’t disagree with it in general. However, I feel that:
>> * I don’t like regressing/loosing features
>> * This is an opportunity to have something now. I can tell you that if we do nothing now, nothing will happen for at least 1 year
>> * We’re not redoing the messaging feature, just the display part in the notif UI
>> * I don’t see how there would much changes even if we spend 2 years designing a new messaging center.
>> * It’s not going to cost much (probably 1-2 days of work max). So at worse ,it’ll cost us 1-2 days if we had to redo everything.
>> * Also note that we're not changing the store or anything so even if we redo it completely differently it doesn’t matter and we will not loose anything
>> * This will allow us to gather feedback from the community about needs/improvements
>> * We can never implement a feature in one go. We need to work iteratively. We just need to make sure the architecture is not going to break. Since we’re not touching this part, there’s no real risk
>>
>> So I really believe that it’s more positive than negative to spend this little time to display messages in the notif UI.
>>
>> WDYT?
>
> 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 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
* There’s no way that people could use messages, it’s not useful

What I’m saying:
* We don't have chat feature and that’s a very large feature to develop with a completely different architecture.
* 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.
* 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 see why messaging would be bad and affect the XWiki usage negatively. Especially since message stream is off by default.

Thanks
-Vincent

>
> Thanks,
> Clément
>
> [1] https://markmail.org/message/pw6wtx2lkn72rupv
>
>> Thanks
>> -Vincent
>>
>>>
>>>> Thanks for you time and have a great day,
>>>>
>>>> Guillaume

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

Guillaume Delhumeau
I see a problem. If the message stream is disabled, the preferences buttons
about the messages are still displayed in the notification settings...

The way it works is by fetching all components that match some the role
"RecordableEventDescriptor", but there is no conditional section to decide
either or not the preference concerning the event type should be displayed.

2018-05-31 16:42 GMT+02:00 Vincent Massol <[hidden email]>:

>
>
> > On 31 May 2018, at 16:23, Clément Aubin <[hidden email]> wrote:
> >
> > On 05/31/2018 03:18 PM, Vincent Massol wrote:
> >> Hi Clement,
> >>
> >>> On 31 May 2018, at 14:56, Clément Aubin <[hidden email]> wrote:
> >>
> >> [snip]
> >>
> >>>>
> >>>> All others: if you have any recommendation or counter argument,
> please post
> >>>> it quickly :)
> >>>
> >>> I don't have a good knowledge of the "old" message stream
> >>> implementation, however, I'm concerned about the ability of the
> >>> notification system to act as a messaging center.
> >>>
> >>> - When working on multiple documents, I might end up talking with
> >>> multiple people at the same time. What would happen to the notification
> >>> center ? Would I have a composite event with all of my conversations in
> >>> it, or one composite notification per user I'm talking with, which
> would
> >>> probably fill most of the notification center ?
> >>
> >> This is not supported ATM (see http://extensions.xwiki.org/
> xwiki/bin/view/Extension/Message%20Stream%20Application/) so no issue
> FTM. You can only send messages to a given user, to a group or to everyone.>
> >> I don’t see a problem to add this feature later on if we need it.
> >
> > 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.
>
> > 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”
> * 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!
>
> >
> >>> - When being in a wiki, I might end up staying 1, 2 hours or more on
> the
> >>> same page, either to edit it or to read it and refer to it from time to
> >>> time. The messaging feature of the notification is interesting here if
> >>> and only if we have the ability to auto-refresh the notification center
> >>> every X seconds / minutes to check for new events or, in this case, new
> >>> messages. AFAIK, this feature isn't in place for now.
> >>
> >> I don’t see this related at all to messaging. You have the same problem
> for any kind of notifications. This is related to live notifications and
> something generic for the notifications feature.
> >>
> >> I don’t agree with "The messaging feature of the notification is
> interesting here if and only if we have the ability to auto-refresh the
> notification center every X seconds”. Again I don’t see why this is related
> only to messaging and also I find it more useful to have messaging than
> nothing (which is what you propose). I can imagine plenty of use cases
> where it’s still useful to have messaging without the auto refresh. I
> consider auto refresh to be a nice improvement to have not as a "must have
> or there’s no value”.
> >
> > 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…
>
> >
> >>> All in all, I'm very concerned that we try to ship a half finished
> >>> feature that cannot be used for real collaboration and that still takes
> >>> some place in the UI ;
> >>
> >> Maybe there’s a misunderstanding: We’re not trying to develop a
> messaging feature. This feature already exists and we’re not touching this.
> >>
> >> All that we’re doing is add the ability to display messages in the
> notification UI if some messages are present in the Event Stream table.
> >>
> >> This feature already exists today and not doing this would be to remove
> a feature that is now interesting to have thanks to the replacement of the
> AS by the Notifications UI.
> >>
> >>> only to have an equivalent of a feature that we
> >>> disabled some years ago.
> >>
> >> We disabled it for 2 reasons and not for the reasons you mentioned
> above:
> >> * Because the dashboard was on the home page and several users were not
> using the message sending UI and didn’t want it to take valuable space on
> the home page. This has been solved by moving the dashboard to a different
> space
> >> * Because you couldn’t know when someone was sending a message to you
> and it was hard to check your personal AS (you had to nav to your user
> profile).
> >
> > Actually, I would be interested to know the other reasons for disabling
> > the Message Stream some time ago. In the original message ([1]), this
> > was the only point mentionned, but maybe Nicolas had more reasons.
> >> Those 2 problems are fixed so there’s no reason to not have it anymore.
> >>
> >>> If we want to promote messaging and more user
> >>> to user interaction in the wiki, maybe we should take more time to spec
> >>> it. If we had to vote for this, I'd say -0 for now.
> >>
> >> Yes and that’s why Caty is going to conduct a more general
> investigation on that.
> >>
> >> I understand your POV and I don’t disagree with it in general. However,
> I feel that:
> >> * I don’t like regressing/loosing features
> >> * This is an opportunity to have something now. I can tell you that if
> we do nothing now, nothing will happen for at least 1 year
> >> * We’re not redoing the messaging feature, just the display part in the
> notif UI
> >> * I don’t see how there would much changes even if we spend 2 years
> designing a new messaging center.
> >> * It’s not going to cost much (probably 1-2 days of work max). So at
> worse ,it’ll cost us 1-2 days if we had to redo everything.
> >> * Also note that we're not changing the store or anything so even if we
> redo it completely differently it doesn’t matter and we will not loose
> anything
> >> * This will allow us to gather feedback from the community about
> needs/improvements
> >> * We can never implement a feature in one go. We need to work
> iteratively. We just need to make sure the architecture is not going to
> break. Since we’re not touching this part, there’s no real risk
> >>
> >> So I really believe that it’s more positive than negative to spend this
> little time to display messages in the notif UI.
> >>
> >> WDYT?
> >
> > 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 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
> * There’s no way that people could use messages, it’s not useful
>
> What I’m saying:
> * We don't have chat feature and that’s a very large feature to develop
> with a completely different architecture.
> * 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.
> * 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 see why messaging would be bad and affect the XWiki usage
> negatively. Especially since message stream is off by default.
>
> Thanks
> -Vincent
>
> >
> > Thanks,
> > Clément
> >
> > [1] https://markmail.org/message/pw6wtx2lkn72rupv
> >
> >> Thanks
> >> -Vincent
> >>
> >>>
> >>>> Thanks for you time and have a great day,
> >>>>
> >>>> Guillaume
>
>


--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

caubin
In reply to this post by vmassol
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.

> 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”

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). 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.

> * 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 ?

[…]

>> 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).

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.

[…]

>> 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.

> 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.

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.

> * 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#HGeneralDevelopmentFlow
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

Guillaume Delhumeau
In reply to this post by Guillaume Delhumeau
2018-05-31 17:24 GMT+02:00 Guillaume Delhumeau <
[hidden email]>:

> I see a problem. If the message stream is disabled, the preferences
> buttons about the messages are still displayed in the notification
> settings...
>
> The way it works is by fetching all components that match some the role
> "RecordableEventDescriptor", but there is no conditional section to decide
> either or not the preference concerning the event type should be displayed.
>

I will just introduce a new isEnabled() method to the descriptor. Sorry for
the noise.



>
> 2018-05-31 16:42 GMT+02:00 Vincent Massol <[hidden email]>:
>
>>
>>
>> > On 31 May 2018, at 16:23, Clément Aubin <[hidden email]> wrote:
>> >
>> > On 05/31/2018 03:18 PM, Vincent Massol wrote:
>> >> Hi Clement,
>> >>
>> >>> On 31 May 2018, at 14:56, Clément Aubin <[hidden email]> wrote:
>> >>
>> >> [snip]
>> >>
>> >>>>
>> >>>> All others: if you have any recommendation or counter argument,
>> please post
>> >>>> it quickly :)
>> >>>
>> >>> I don't have a good knowledge of the "old" message stream
>> >>> implementation, however, I'm concerned about the ability of the
>> >>> notification system to act as a messaging center.
>> >>>
>> >>> - When working on multiple documents, I might end up talking with
>> >>> multiple people at the same time. What would happen to the
>> notification
>> >>> center ? Would I have a composite event with all of my conversations
>> in
>> >>> it, or one composite notification per user I'm talking with, which
>> would
>> >>> probably fill most of the notification center ?
>> >>
>> >> This is not supported ATM (see http://extensions.xwiki.org/xw
>> iki/bin/view/Extension/Message%20Stream%20Application/) so no issue FTM.
>> You can only send messages to a given user, to a group or to everyone.>
>> >> I don’t see a problem to add this feature later on if we need it.
>> >
>> > 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.
>>
>> > 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”
>> * 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!
>>
>> >
>> >>> - When being in a wiki, I might end up staying 1, 2 hours or more on
>> the
>> >>> same page, either to edit it or to read it and refer to it from time
>> to
>> >>> time. The messaging feature of the notification is interesting here if
>> >>> and only if we have the ability to auto-refresh the notification
>> center
>> >>> every X seconds / minutes to check for new events or, in this case,
>> new
>> >>> messages. AFAIK, this feature isn't in place for now.
>> >>
>> >> I don’t see this related at all to messaging. You have the same
>> problem for any kind of notifications. This is related to live
>> notifications and something generic for the notifications feature.
>> >>
>> >> I don’t agree with "The messaging feature of the notification is
>> interesting here if and only if we have the ability to auto-refresh the
>> notification center every X seconds”. Again I don’t see why this is related
>> only to messaging and also I find it more useful to have messaging than
>> nothing (which is what you propose). I can imagine plenty of use cases
>> where it’s still useful to have messaging without the auto refresh. I
>> consider auto refresh to be a nice improvement to have not as a "must have
>> or there’s no value”.
>> >
>> > 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…
>>
>> >
>> >>> All in all, I'm very concerned that we try to ship a half finished
>> >>> feature that cannot be used for real collaboration and that still
>> takes
>> >>> some place in the UI ;
>> >>
>> >> Maybe there’s a misunderstanding: We’re not trying to develop a
>> messaging feature. This feature already exists and we’re not touching this.
>> >>
>> >> All that we’re doing is add the ability to display messages in the
>> notification UI if some messages are present in the Event Stream table.
>> >>
>> >> This feature already exists today and not doing this would be to
>> remove a feature that is now interesting to have thanks to the replacement
>> of the AS by the Notifications UI.
>> >>
>> >>> only to have an equivalent of a feature that we
>> >>> disabled some years ago.
>> >>
>> >> We disabled it for 2 reasons and not for the reasons you mentioned
>> above:
>> >> * Because the dashboard was on the home page and several users were
>> not using the message sending UI and didn’t want it to take valuable space
>> on the home page. This has been solved by moving the dashboard to a
>> different space
>> >> * Because you couldn’t know when someone was sending a message to you
>> and it was hard to check your personal AS (you had to nav to your user
>> profile).
>> >
>> > Actually, I would be interested to know the other reasons for disabling
>> > the Message Stream some time ago. In the original message ([1]), this
>> > was the only point mentionned, but maybe Nicolas had more reasons.
>> >> Those 2 problems are fixed so there’s no reason to not have it anymore.
>> >>
>> >>> If we want to promote messaging and more user
>> >>> to user interaction in the wiki, maybe we should take more time to
>> spec
>> >>> it. If we had to vote for this, I'd say -0 for now.
>> >>
>> >> Yes and that’s why Caty is going to conduct a more general
>> investigation on that.
>> >>
>> >> I understand your POV and I don’t disagree with it in general.
>> However, I feel that:
>> >> * I don’t like regressing/loosing features
>> >> * This is an opportunity to have something now. I can tell you that if
>> we do nothing now, nothing will happen for at least 1 year
>> >> * We’re not redoing the messaging feature, just the display part in
>> the notif UI
>> >> * I don’t see how there would much changes even if we spend 2 years
>> designing a new messaging center.
>> >> * It’s not going to cost much (probably 1-2 days of work max). So at
>> worse ,it’ll cost us 1-2 days if we had to redo everything.
>> >> * Also note that we're not changing the store or anything so even if
>> we redo it completely differently it doesn’t matter and we will not loose
>> anything
>> >> * This will allow us to gather feedback from the community about
>> needs/improvements
>> >> * We can never implement a feature in one go. We need to work
>> iteratively. We just need to make sure the architecture is not going to
>> break. Since we’re not touching this part, there’s no real risk
>> >>
>> >> So I really believe that it’s more positive than negative to spend
>> this little time to display messages in the notif UI.
>> >>
>> >> WDYT?
>> >
>> > 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 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
>> * There’s no way that people could use messages, it’s not useful
>>
>> What I’m saying:
>> * We don't have chat feature and that’s a very large feature to develop
>> with a completely different architecture.
>> * 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.
>> * 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 see why messaging would be bad and affect the XWiki usage
>> negatively. Especially since message stream is off by default.
>>
>> Thanks
>> -Vincent
>>
>> >
>> > Thanks,
>> > Clément
>> >
>> > [1] https://markmail.org/message/pw6wtx2lkn72rupv
>> >
>> >> Thanks
>> >> -Vincent
>> >>
>> >>>
>> >>>> Thanks for you time and have a great day,
>> >>>>
>> >>>> Guillaume
>>
>>
>
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>



--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

Ecaterina Moraru (Valica)
Here is how the message, mentions and app notif could look like
http://design.xwiki.org/xwiki/bin/view/Proposal/UserMessageNotifications

I also would not put the messageSender macro in the Notifications area,
since it will crowd it.
For me, if we want messages we really need an Inbox in the User Profile,
but that's something for the future.

So, what I would do is create the events and the notifications displays,
but leave the send message macro as it is. It can be integrated in the page
by using the macro and activate it from Administration, but is not
something we would recommend in the current state.

Thanks,
Caty


On Thu, May 31, 2018 at 6:34 PM, Guillaume Delhumeau <
[hidden email]> wrote:

> 2018-05-31 17:24 GMT+02:00 Guillaume Delhumeau <
> [hidden email]>:
>
> > I see a problem. If the message stream is disabled, the preferences
> > buttons about the messages are still displayed in the notification
> > settings...
> >
> > The way it works is by fetching all components that match some the role
> > "RecordableEventDescriptor", but there is no conditional section to
> decide
> > either or not the preference concerning the event type should be
> displayed.
> >
>
> I will just introduce a new isEnabled() method to the descriptor. Sorry for
> the noise.
>
>
>
> >
> > 2018-05-31 16:42 GMT+02:00 Vincent Massol <[hidden email]>:
> >
> >>
> >>
> >> > On 31 May 2018, at 16:23, Clément Aubin <[hidden email]> wrote:
> >> >
> >> > On 05/31/2018 03:18 PM, Vincent Massol wrote:
> >> >> Hi Clement,
> >> >>
> >> >>> On 31 May 2018, at 14:56, Clément Aubin <[hidden email]>
> wrote:
> >> >>
> >> >> [snip]
> >> >>
> >> >>>>
> >> >>>> All others: if you have any recommendation or counter argument,
> >> please post
> >> >>>> it quickly :)
> >> >>>
> >> >>> I don't have a good knowledge of the "old" message stream
> >> >>> implementation, however, I'm concerned about the ability of the
> >> >>> notification system to act as a messaging center.
> >> >>>
> >> >>> - When working on multiple documents, I might end up talking with
> >> >>> multiple people at the same time. What would happen to the
> >> notification
> >> >>> center ? Would I have a composite event with all of my conversations
> >> in
> >> >>> it, or one composite notification per user I'm talking with, which
> >> would
> >> >>> probably fill most of the notification center ?
> >> >>
> >> >> This is not supported ATM (see http://extensions.xwiki.org/xw
> >> iki/bin/view/Extension/Message%20Stream%20Application/) so no issue
> FTM.
> >> You can only send messages to a given user, to a group or to everyone.>
> >> >> I don’t see a problem to add this feature later on if we need it.
> >> >
> >> > 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.
> >>
> >> > 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”
> >> * 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!
> >>
> >> >
> >> >>> - When being in a wiki, I might end up staying 1, 2 hours or more on
> >> the
> >> >>> same page, either to edit it or to read it and refer to it from time
> >> to
> >> >>> time. The messaging feature of the notification is interesting here
> if
> >> >>> and only if we have the ability to auto-refresh the notification
> >> center
> >> >>> every X seconds / minutes to check for new events or, in this case,
> >> new
> >> >>> messages. AFAIK, this feature isn't in place for now.
> >> >>
> >> >> I don’t see this related at all to messaging. You have the same
> >> problem for any kind of notifications. This is related to live
> >> notifications and something generic for the notifications feature.
> >> >>
> >> >> I don’t agree with "The messaging feature of the notification is
> >> interesting here if and only if we have the ability to auto-refresh the
> >> notification center every X seconds”. Again I don’t see why this is
> related
> >> only to messaging and also I find it more useful to have messaging than
> >> nothing (which is what you propose). I can imagine plenty of use cases
> >> where it’s still useful to have messaging without the auto refresh. I
> >> consider auto refresh to be a nice improvement to have not as a "must
> have
> >> or there’s no value”.
> >> >
> >> > 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…
> >>
> >> >
> >> >>> All in all, I'm very concerned that we try to ship a half finished
> >> >>> feature that cannot be used for real collaboration and that still
> >> takes
> >> >>> some place in the UI ;
> >> >>
> >> >> Maybe there’s a misunderstanding: We’re not trying to develop a
> >> messaging feature. This feature already exists and we’re not touching
> this.
> >> >>
> >> >> All that we’re doing is add the ability to display messages in the
> >> notification UI if some messages are present in the Event Stream table.
> >> >>
> >> >> This feature already exists today and not doing this would be to
> >> remove a feature that is now interesting to have thanks to the
> replacement
> >> of the AS by the Notifications UI.
> >> >>
> >> >>> only to have an equivalent of a feature that we
> >> >>> disabled some years ago.
> >> >>
> >> >> We disabled it for 2 reasons and not for the reasons you mentioned
> >> above:
> >> >> * Because the dashboard was on the home page and several users were
> >> not using the message sending UI and didn’t want it to take valuable
> space
> >> on the home page. This has been solved by moving the dashboard to a
> >> different space
> >> >> * Because you couldn’t know when someone was sending a message to you
> >> and it was hard to check your personal AS (you had to nav to your user
> >> profile).
> >> >
> >> > Actually, I would be interested to know the other reasons for
> disabling
> >> > the Message Stream some time ago. In the original message ([1]), this
> >> > was the only point mentionned, but maybe Nicolas had more reasons.
> >> >> Those 2 problems are fixed so there’s no reason to not have it
> anymore.
> >> >>
> >> >>> If we want to promote messaging and more user
> >> >>> to user interaction in the wiki, maybe we should take more time to
> >> spec
> >> >>> it. If we had to vote for this, I'd say -0 for now.
> >> >>
> >> >> Yes and that’s why Caty is going to conduct a more general
> >> investigation on that.
> >> >>
> >> >> I understand your POV and I don’t disagree with it in general.
> >> However, I feel that:
> >> >> * I don’t like regressing/loosing features
> >> >> * This is an opportunity to have something now. I can tell you that
> if
> >> we do nothing now, nothing will happen for at least 1 year
> >> >> * We’re not redoing the messaging feature, just the display part in
> >> the notif UI
> >> >> * I don’t see how there would much changes even if we spend 2 years
> >> designing a new messaging center.
> >> >> * It’s not going to cost much (probably 1-2 days of work max). So at
> >> worse ,it’ll cost us 1-2 days if we had to redo everything.
> >> >> * Also note that we're not changing the store or anything so even if
> >> we redo it completely differently it doesn’t matter and we will not
> loose
> >> anything
> >> >> * This will allow us to gather feedback from the community about
> >> needs/improvements
> >> >> * We can never implement a feature in one go. We need to work
> >> iteratively. We just need to make sure the architecture is not going to
> >> break. Since we’re not touching this part, there’s no real risk
> >> >>
> >> >> So I really believe that it’s more positive than negative to spend
> >> this little time to display messages in the notif UI.
> >> >>
> >> >> WDYT?
> >> >
> >> > 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 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
> >> * There’s no way that people could use messages, it’s not useful
> >>
> >> What I’m saying:
> >> * We don't have chat feature and that’s a very large feature to develop
> >> with a completely different architecture.
> >> * 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.
> >> * 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 see why messaging would be bad and affect the XWiki usage
> >> negatively. Especially since message stream is off by default.
> >>
> >> Thanks
> >> -Vincent
> >>
> >> >
> >> > Thanks,
> >> > Clément
> >> >
> >> > [1] https://markmail.org/message/pw6wtx2lkn72rupv
> >> >
> >> >> Thanks
> >> >> -Vincent
> >> >>
> >> >>>
> >> >>>> Thanks for you time and have a great day,
> >> >>>>
> >> >>>> Guillaume
> >>
> >>
> >
> >
> > --
> > Guillaume Delhumeau ([hidden email])
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> >
>
>
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

vmassol
Administrator
In reply to this post by caubin


> On 31 May 2018, at 17:28, Clément Aubin <[hidden email]> 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?

> 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.

>
>> * 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://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneralDevelopmentFlow

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

caubin
On 05/31/2018 05:44 PM, Vincent Massol wrote:

>
>
>> On 31 May 2018, at 17:28, Clément Aubin <[hidden email]> 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…

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.

>>
>>> * 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".

>>
>>> * 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/UserMessageNotifications#HUserMessages
[2]
http://design.xwiki.org/xwiki/bin/view/Proposal/UserMessageNotifications#HUserMentions
[3]
http://design.xwiki.org/xwiki/bin/view/Proposal/UserMessageNotifications#HAppNotifications
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

vmassol
Administrator


> On 31 May 2018, at 18:07, Clément Aubin <[hidden email]> wrote:
>
> On 05/31/2018 05:44 PM, Vincent Massol wrote:
>>
>>
>>> On 31 May 2018, at 17:28, Clément Aubin <[hidden email]> 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…
>
> 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.

>
>>>
>>>> * 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/UserMessageNotifications#HUserMessages
> [2]
> http://design.xwiki.org/xwiki/bin/view/Proposal/UserMessageNotifications#HUserMentions
> [3]
> http://design.xwiki.org/xwiki/bin/view/Proposal/UserMessageNotifications#HAppNotifications

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

Eduard Moraru
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 <[hidden email]> wrote:

>
>
> > On 31 May 2018, at 18:07, Clément Aubin <[hidden email]> wrote:
> >
> > On 05/31/2018 05:44 PM, Vincent Massol wrote:
> >>
> >>
> >>> On 31 May 2018, at 17:28, Clément Aubin <[hidden email]> 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…
> >
> > 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.
>
> >
> >>>
> >>>> * 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/
> UserMessageNotifications#HUserMessages
> > [2]
> > http://design.xwiki.org/xwiki/bin/view/Proposal/
> UserMessageNotifications#HUserMentions
> > [3]
> > http://design.xwiki.org/xwiki/bin/view/Proposal/
> UserMessageNotifications#HAppNotifications
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

Guillaume Delhumeau
Hi.

The implementation is almost done, and is online on a branch:
https://github.com/xwiki/xwiki-platform/tree/feature-user-messages-in-notifications.


The good point is that it has forced me to improve our event descriptor
mechanism (ie: adding the ability to disable a recordable event descriptor
on some conditions), which could be useful.

I think we all agree the "Message Sender" application has a lot of problems
and should be replaced by something better, if we have the chance in the
future.

Now, I have just added what was missing to display them properly on the
notifications (without too much work), since they are already present in
the database. It means we can finally replace the AS by the notifications,
which is a great achievement (and I congratulate myself for that). We are
still aligned with our objectives to ensure retro-compatibility (old
messages can still be read) and to not break functionalities (no
regression).

At the end, we could create a new proposal to decide what should be the
future of the Message Sender, but I consider the current debate as closed
(except if everybody want to put my work in the trash bin).

Thanks,

Guillaume


2018-06-04 18:15 GMT+02:00 Eduard Moraru <[hidden email]>:

> 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 <[hidden email]>
> wrote:
>
> >
> >
> > > On 31 May 2018, at 18:07, Clément Aubin <[hidden email]> wrote:
> > >
> > > On 05/31/2018 05:44 PM, Vincent Massol wrote:
> > >>
> > >>
> > >>> On 31 May 2018, at 17:28, Clément Aubin <[hidden email]>
> 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…
> > >
> > > 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.
> >
> > >
> > >>>
> > >>>> * 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/
> > UserMessageNotifications#HUserMessages
> > > [2]
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/
> > UserMessageNotifications#HUserMentions
> > > [3]
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/
> > UserMessageNotifications#HAppNotifications
> >
> >
>



--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Display user messages in the notifications.

vmassol
Administrator


> On 5 Jun 2018, at 10:33, Guillaume Delhumeau <[hidden email]> wrote:
>
> Hi.
>
> The implementation is almost done, and is online on a branch:
> https://github.com/xwiki/xwiki-platform/tree/feature-user-messages-in-notifications.
>
>
> The good point is that it has forced me to improve our event descriptor
> mechanism (ie: adding the ability to disable a recordable event descriptor
> on some conditions), which could be useful.
>
> I think we all agree the "Message Sender" application has a lot of problems
> and should be replaced by something better, if we have the chance in the
> future.
>
> Now, I have just added what was missing to display them properly on the
> notifications (without too much work), since they are already present in
> the database. It means we can finally replace the AS by the notifications,
> which is a great achievement (and I congratulate myself for that). We are
> still aligned with our objectives to ensure retro-compatibility (old
> messages can still be read) and to not break functionalities (no
> regression).
>
> At the end, we could create a new proposal to decide what should be the
> future of the Message Sender, but I consider the current debate as closed
> (except if everybody want to put my work in the trash bin).

+1 to what you said and for the work you did.

It’ll be months (years?) before we have a better implementation of messages/chat/inbox center so it’s good to have this for the few users who might want to send messages to everyone, to a group or to someone (it’s off by default).

Thanks Guillaume
-Vincent

>
> Thanks,
>
> Guillaume
>
>
> 2018-06-04 18:15 GMT+02:00 Eduard Moraru <[hidden email]>:
>
>> 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 <[hidden email]>
>> wrote:
>>
>>>
>>>
>>>> On 31 May 2018, at 18:07, Clément Aubin <[hidden email]> wrote:
>>>>
>>>> On 05/31/2018 05:44 PM, Vincent Massol wrote:
>>>>>
>>>>>
>>>>>> On 31 May 2018, at 17:28, Clément Aubin <[hidden email]>
>> 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…
>>>>
>>>> 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.
>>>
>>>>
>>>>>>
>>>>>>> * 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/
>>> UserMessageNotifications#HUserMessages
>>>> [2]
>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/
>>> UserMessageNotifications#HUserMentions
>>>> [3]
>>>> http://design.xwiki.org/xwiki/bin/view/Proposal/
>>> UserMessageNotifications#HAppNotifications
>>>
>>>
>>
>
>
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project