On 05/31/2018 05:44 PM, Vincent Massol wrote: > > >> On 31 May 2018, at 17:28, Clément Aubin <aubincl...@gmail.com> wrote: >> >> On 05/31/2018 04:42 PM, Vincent Massol wrote: >> >> […] >> >>>> I'm here describing my own usage of collaborative platforms or social >>>> networks. If it wasn't supported before today, maybe we should think >>>> about it, because usually, people with only one friend to talk to are >>>> rare. Having multiple conversation is something that we should at least >>>> think about. >>> >>> Did I say we should not think about it? >> >> Oh I'm sure that you didn't said that, but this would need a more >> in-depth investigation, and not just 2 days of implementation. > > No no this is out of scope for now. > >> >>> Also as I wrote you can send to a group and to everyone too so yes you can >>> send to multiple people. >> >> I'm not talking about sending a message to groups, but to multiple >> individuals. > > I know and out of scope for now. > >> >>>> Also, as you mentioned it in the end of your previous mail, "if we do >>>> nothing now, nothing will happen for at least 1 year", what makes you >>>> think that we'll have the time to improve the feature later on, even if >>>> we do need it ? >>> >>> Ok so we have a big disagreement: >>> * You say “displaying notifications in the proposed way is bad thing and >>> there’s no use case for it” >> >> Please don't rephrase me like that :) . The current notifications are, >> IMO correctly displayed (and we're not debating about how to display >> notifications AFAIK). > > Sorry I meant ‘displaying messages in the notifications UI in the proposed > way is a bad thing and there’s no use case for it” > >> However, I don't think that the notification >> center has been crafted to correctly display user messages. Merging >> events coming from the wiki and messages coming from the message stream >> is tricky. > > Why? They’re both coming from the same location, i.e. event table…
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
