2018-05-31 17:24 GMT+02:00 Guillaume Delhumeau < [email protected]>:
> 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 <[email protected]>: > >> >> >> > On 31 May 2018, at 16:23, Clément Aubin <[email protected]> wrote: >> > >> > On 05/31/2018 03:18 PM, Vincent Massol wrote: >> >> Hi Clement, >> >> >> >>> On 31 May 2018, at 14:56, Clément Aubin <[email protected]> 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 ([email protected]) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
