[xwiki-devs] Email this page feature
Sergiu, You are in charge of the email this page feature for 2.6. Is there a design page for it ? I wanted to suggest some additional functionnality to that feature if you have time for it. When sending the page or when saving (the email this page feature could be just under the save button), the user would have the ability to ask for an automatic email this page on every change (content and comments). The user would be able to say: [ ] All Contributors Additional users or groups: [ ] Additional manual emails: [ ] [ ] email all changes Then automatically the email this page would be activated on each change. A required feature would be an exclude list and a way for the user to unsubscribe. Finally we could add an email box so that we can load comments sent as a reply to an email sent by the wiki. The rationale for this feature is that when working on a document that requires some discussion and validation, the email discussion is not captured and the changes in the wiki are not triggering a fast enough reaction thus slowing down the discussion around the document (I know the Watch List exists, but since it requires manual subscription, most participants won't do it and the speed of notification of the watch list is not fast enough for discussion). WDYT ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On 10/30/2010 11:49 AM, Ludovic Dubost wrote:
Sergiu,
You are in charge of the email this page feature for 2.6. Is there a design page for it ? I wanted to suggest some additional functionnality to that feature if you have time for it. When sending the page or when saving (the email this page feature could be just under the save button), the user would have the ability to ask for an automatic email this page on every change (content and comments).
The user would be able to say:
[ ] All Contributors Additional users or groups: [ ] Additional manual emails: [ ] [ ] email all changes
Then automatically the email this page would be activated on each change. A required feature would be an exclude list and a way for the user to unsubscribe.
I don't like this, it's intrusive. Personally I wouldn't like at all being forcefully invited into a conversation. There are other ways of doing this which don't involve waking up with 30 emails in my inbox, most of which will be implemented in the 3.x cycle as part of the social improvements. I agree about a "notify me of changes" checkbox under the action buttons, if Vincent doesn't think it crowds the editor UI.
Finally we could add an email box so that we can load comments sent as a reply to an email sent by the wiki.
Yep, this is also an idea kept in the background, but too complex to be included inside the "email this page" development.
The rationale for this feature is that when working on a document that requires some discussion and validation, the email discussion is not captured and the changes in the wiki are not triggering a fast enough reaction thus slowing down the discussion around the document (I know the Watch List exists, but since it requires manual subscription, most participants won't do it and the speed of notification of the watch list is not fast enough for discussion).
One idea of improvement for the watchlist was to have instant notifications, but this is another topic. In summary: - add a new level for the watchlist which sends notifications as soon as a document is sent (as implementation, it will use the observation mechanism and not a scheduler job) - the current notification interval configuration will be kept as the default - for each item in the watchlist it will be possible to specify its own interval setting Isn't your last paragraph contradicting your proposal? Email is slow and deprecated, and one of the main points when presenting XWiki is how much better it is than emails. Why would moving the discussion to emails help collaborative writing? -- Sergiu Dumitriu http://purl.org/net/sergiu/
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
I don't like this, it's intrusive. Personally I wouldn't like at all being forcefully invited into a conversation. There are other ways of doing this which don't involve waking up with 30 emails in my inbox, most of which will be implemented in the 3.x cycle as part of the social improvements.
I don't agree with you that the social improvements do anything in this area or maybe I'm missing something. If it's activity streams or other real time features, oin many cases, you can't go all the time to the wiki to check if an important document is evolving, for which the discussion needs to be fast. You might not like it, but this really creates dynamicity when discussing on a wiki document. The lack of such a features leads to discussions staying in email exchanges and therefore no work on the wiki document itself (when it was at all created). Think about a discussion about a feature in the devs mailing list. None of it is captured in the wiki page where the feature is described. Think also about non technical people that need to learn how to work with wikis. Concerning being forced in a conversation, you can drop out in one click if you don't like it and it's the responsibility of the person sending the notification to actually decide to do that push. Of course this should not be done by default on all documents as this is meant for important docs for which a discussion is really needed, like a project manager bringing in 3 people he works with in a discussion. Managers need to be sure that what they want to do reaches their target. If editing the wiki page or commenting on a wiki page is not sure to reach it's target, the manager will reach out to other means (email, skype or even telephone). Once this happens you have lost of lot of valuable content. Without the forcing, you can be sure that since some people will be missing the discussion won't work as well. In any case please don't think about this feature for public discussions. It's meant for business users so that they can get the work done.
I agree about a "notify me of changes" checkbox under the action buttons, if Vincent doesn't think it crowds the editor UI.
That's definitively already usefull as any editor/commentor can decide to get instant notifications. But the minute you are not sure that the other user will get your comment, people will loose confident is this way of discussing.
Finally we could add an email box so that we can load comments sent as a reply to an email sent by the wiki. Yep, this is also an idea kept in the background, but too complex to be included inside the "email this page" development. I agree that it's some work and might be too much for this version. The rationale for this feature is that when working on a document that requires some discussion and validation, the email discussion is not captured and the changes in the wiki are not triggering a fast enough reaction thus slowing down the discussion around the document (I know the Watch List exists, but since it requires manual subscription, most participants won't do it and the speed of notification of the watch list is not fast enough for discussion). One idea of improvement for the watchlist was to have instant notifications, but this is another topic. In summary:
- add a new level for the watchlist which sends notifications as soon as a document is sent (as implementation, it will use the observation mechanism and not a scheduler job) - the current notification interval configuration will be kept as the default - for each item in the watchlist it will be possible to specify its own interval setting
Isn't your last paragraph contradicting your proposal? Email is slow and deprecated, and one of the main points when presenting XWiki is how much better it is than emails. Why would moving the discussion to emails help collaborative writing?
email usage should move from being the actual place of discussion to a notification tool. It's still a good notification tool for the important ones. Clearly if you are overloaded in one of your channels, then it's stops being effective. But well done it's a good notification tool. RSS or Twitter which are good at being notification tool for massive amounts of information are actually bad for the smaller amounts of important information. In my view it's about learning how to use a combination of these tools for that. Back to the wiki, my objective here is not to move the discussion to emails, but to make sure that any discussion in the wiki get the same efficiency as email when it comes to notification of the discussion events. As for capturing responses in emails into the wiki this is to ease transition from email to wiki. I would expect that experiences users would click on the link to comment in the wiki since you would have more features there. Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Nov 8, 2010, at 1:44 AM, Ludovic Dubost wrote:
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
I don't like this, it's intrusive. Personally I wouldn't like at all being forcefully invited into a conversation. There are other ways of doing this which don't involve waking up with 30 emails in my inbox, most of which will be implemented in the 3.x cycle as part of the social improvements.
I don't agree with you that the social improvements do anything in this area or maybe I'm missing something. If it's activity streams or other real time features, oin many cases, you can't go all the time to the wiki to check if an important document is evolving, for which the discussion needs to be fast.
You might not like it, but this really creates dynamicity when discussing on a wiki document. The lack of such a features leads to discussions staying in email exchanges and therefore no work on the wiki document itself (when it was at all created). Think about a discussion about a feature in the devs mailing list. None of it is captured in the wiki page where the feature is described. Think also about non technical people that need to learn how to work with wikis.
I think a wiki is in general a terrible tool for discussions. It's good for creating content collaboratively but bad for discussion. The proof is that you want to send notifications by mail which proves mail is still the best place for discussions. Personally I'd never take the time to open a wiki, navigate to the page, write something in there, just to have my feedback sent by mail. I'd directly write that mail or respond to a previous mail. Unless it was as easy to do it in the wiki as it is in my email client (see below). However I agree that notifications is important but again I don't think that email is good. Actually it's quite bad. We're trying hard with various tool to remove email clutter. This is why we have RSS feeds, Tweets, etc. So while I agree it's good to have the possibility in the watchlist to send email notifications whenever a document is modified, this must be chosen by the user and not forced onto him. I envision a workflow like this one: - I'm writing a page and I want to invite people to it. I send a mail to them - In that mail (or on the page that the mail opens when you click on the link), there's a button to add the page to one's watchlist. Thus the user can choose to receive email notification either immediatly when there are changes or at his own pace. He can also decide to subscribe by RSS feed in which case he'll also receive immediate notifications. Again IMO the wiki is not a discussion tool and it's not meant to be a place for rapid discussions. There are way better tools for this: - mailing list or mailing groups (average response time == few hours) - chat (average response time == minutes) For the wiki the average response time is around days IMO. Now if we really wanted discussions to happen in the wiki we would need to make a mailing list bridge or IM bridge so that when people reply to mails or chat messages the content gets added to the wiki. We would need a way to separate content modification (ie the content is modified in the wiki page) from comments (either added inline as an annotation or at the bottom) in some ways. Another idea which I love is to do like zapplets were doing (back around 2000) and receive an HTML email containing the full page with the ability on the email client side to make modifications directly to the page inside the mail client and send that modification to the server. And when the email is refreshed you can also see the modified content from the server. Zapplets were really great tools and I loved them at the time. Anyway I'm not strongly opposed to any of what"s been discussed. We just need to be careful that we need to release the mailto feature today so that we don't miss our XE 2.6 deadline, so we need a minimal first implementation that works and we can add new features later on in the 3.x cycle. Thanks -Vincent
Concerning being forced in a conversation, you can drop out in one click if you don't like it and it's the responsibility of the person sending the notification to actually decide to do that push. Of course this should not be done by default on all documents as this is meant for important docs for which a discussion is really needed, like a project manager bringing in 3 people he works with in a discussion. Managers need to be sure that what they want to do reaches their target. If editing the wiki page or commenting on a wiki page is not sure to reach it's target, the manager will reach out to other means (email, skype or even telephone). Once this happens you have lost of lot of valuable content.
Without the forcing, you can be sure that since some people will be missing the discussion won't work as well.
In any case please don't think about this feature for public discussions. It's meant for business users so that they can get the work done.
I agree about a "notify me of changes" checkbox under the action buttons, if Vincent doesn't think it crowds the editor UI.
That's definitively already usefull as any editor/commentor can decide to get instant notifications. But the minute you are not sure that the other user will get your comment, people will loose confident is this way of discussing.
Finally we could add an email box so that we can load comments sent as a reply to an email sent by the wiki. Yep, this is also an idea kept in the background, but too complex to be included inside the "email this page" development. I agree that it's some work and might be too much for this version. The rationale for this feature is that when working on a document that requires some discussion and validation, the email discussion is not captured and the changes in the wiki are not triggering a fast enough reaction thus slowing down the discussion around the document (I know the Watch List exists, but since it requires manual subscription, most participants won't do it and the speed of notification of the watch list is not fast enough for discussion). One idea of improvement for the watchlist was to have instant notifications, but this is another topic. In summary:
- add a new level for the watchlist which sends notifications as soon as a document is sent (as implementation, it will use the observation mechanism and not a scheduler job) - the current notification interval configuration will be kept as the default - for each item in the watchlist it will be possible to specify its own interval setting
Isn't your last paragraph contradicting your proposal? Email is slow and deprecated, and one of the main points when presenting XWiki is how much better it is than emails. Why would moving the discussion to emails help collaborative writing?
email usage should move from being the actual place of discussion to a notification tool. It's still a good notification tool for the important ones. Clearly if you are overloaded in one of your channels, then it's stops being effective. But well done it's a good notification tool. RSS or Twitter which are good at being notification tool for massive amounts of information are actually bad for the smaller amounts of important information. In my view it's about learning how to use a combination of these tools for that.
Back to the wiki, my objective here is not to move the discussion to emails, but to make sure that any discussion in the wiki get the same efficiency as email when it comes to notification of the discussion events. As for capturing responses in emails into the wiki this is to ease transition from email to wiki. I would expect that experiences users would click on the link to comment in the wiki since you would have more features there.
Ludovic
On 11/08/2010 01:44 AM, Ludovic Dubost wrote:
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
I don't like this, it's intrusive. Personally I wouldn't like at all being forcefully invited into a conversation. There are other ways of doing this which don't involve waking up with 30 emails in my inbox, most of which will be implemented in the 3.x cycle as part of the social improvements.
I don't agree with you that the social improvements do anything in this area or maybe I'm missing something. If it's activity streams or other real time features, oin many cases, you can't go all the time to the wiki to check if an important document is evolving, for which the discussion needs to be fast.
You might not like it, but this really creates dynamicity when discussing on a wiki document. The lack of such a features leads to discussions staying in email exchanges and therefore no work on the wiki document itself (when it was at all created). Think about a discussion about a feature in the devs mailing list. None of it is captured in the wiki page where the feature is described. Think also about non technical people that need to learn how to work with wikis.
I don't think we're talking about the same thing. I'm referring to "send notification to this bunch of people EVERY TIME THE PAGE CHANGES". I agree about the "send notification", but not about the "every time". I also agree with subscribing myself to notifications (a.k.a. "add to MY watchlist").
Concerning being forced in a conversation, you can drop out in one click if you don't like it and it's the responsibility of the person sending the notification to actually decide to do that push. Of course this should not be done by default on all documents as this is meant for important docs for which a discussion is really needed, like a project manager bringing in 3 people he works with in a discussion. Managers need to be sure that what they want to do reaches their target. If editing the wiki page or commenting on a wiki page is not sure to reach it's target, the manager will reach out to other means (email, skype or even telephone). Once this happens you have lost of lot of valuable content.
Without the forcing, you can be sure that since some people will be missing the discussion won't work as well.
In any case please don't think about this feature for public discussions. It's meant for business users so that they can get the work done.
I agree about a "notify me of changes" checkbox under the action buttons, if Vincent doesn't think it crowds the editor UI.
That's definitively already usefull as any editor/commentor can decide to get instant notifications. But the minute you are not sure that the other user will get your comment, people will loose confident is this way of discussing.
Finally we could add an email box so that we can load comments sent as a reply to an email sent by the wiki. Yep, this is also an idea kept in the background, but too complex to be included inside the "email this page" development. I agree that it's some work and might be too much for this version. The rationale for this feature is that when working on a document that requires some discussion and validation, the email discussion is not captured and the changes in the wiki are not triggering a fast enough reaction thus slowing down the discussion around the document (I know the Watch List exists, but since it requires manual subscription, most participants won't do it and the speed of notification of the watch list is not fast enough for discussion). One idea of improvement for the watchlist was to have instant notifications, but this is another topic. In summary:
- add a new level for the watchlist which sends notifications as soon as a document is sent (as implementation, it will use the observation mechanism and not a scheduler job) - the current notification interval configuration will be kept as the default - for each item in the watchlist it will be possible to specify its own interval setting
Isn't your last paragraph contradicting your proposal? Email is slow and deprecated, and one of the main points when presenting XWiki is how much better it is than emails. Why would moving the discussion to emails help collaborative writing?
email usage should move from being the actual place of discussion to a notification tool. It's still a good notification tool for the important ones. Clearly if you are overloaded in one of your channels, then it's stops being effective. But well done it's a good notification tool. RSS or Twitter which are good at being notification tool for massive amounts of information are actually bad for the smaller amounts of important information. In my view it's about learning how to use a combination of these tools for that.
Back to the wiki, my objective here is not to move the discussion to emails, but to make sure that any discussion in the wiki get the same efficiency as email when it comes to notification of the discussion events. As for capturing responses in emails into the wiki this is to ease transition from email to wiki. I would expect that experiences users would click on the link to comment in the wiki since you would have more features there.
Ludovic
-- Sergiu Dumitriu http://purl.org/net/sergiu/
hi sergiu Le 8 nov. 2010 à 10:35, Sergiu Dumitriu a écrit :
On 11/08/2010 01:44 AM, Ludovic Dubost wrote:
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
I don't like this, it's intrusive. Personally I wouldn't like at all being forcefully invited into a conversation. There are other ways of doing this which don't involve waking up with 30 emails in my inbox, most of which will be implemented in the 3.x cycle as part of the social improvements.
I don't agree with you that the social improvements do anything in this area or maybe I'm missing something. If it's activity streams or other real time features, oin many cases, you can't go all the time to the wiki to check if an important document is evolving, for which the discussion needs to be fast.
You might not like it, but this really creates dynamicity when discussing on a wiki document. The lack of such a features leads to discussions staying in email exchanges and therefore no work on the wiki document itself (when it was at all created). Think about a discussion about a feature in the devs mailing list. None of it is captured in the wiki page where the feature is described. Think also about non technical people that need to learn how to work with wikis.
I don't think we're talking about the same thing. I'm referring to "send notification to this bunch of people EVERY TIME THE PAGE CHANGES". I agree about the "send notification", but not about the "every time". I also agree with subscribing myself to notifications (a.k.a. "add to MY watchlist").
Then let's talk about what users are waiting for. We present xwiki as an enterprise wiki that proposes an overall experience to avoid some disagreement from the existing tools, such as discussion entropy in mails. BUT it doesn't mean xwiki has to stand alone in the universe, that is why we introduced the "watch" notification features. We also have the invitation manager that covers other needs, but we have a missing link : invitation to a page, or more basic : "share this page" or "send this page by mail". In my mind, this feature is key to power and dummy users. More, it atuomates and makes simple the simple act to share a page (usually, we copy the link, or make a pdf of the page, and then we go in our mail client and create a mail to ... anybody we want to share this page with), the feature we are talking about here prevents to do all this manual stuff. Therefore this feature should allow the user to send the page with the methods he prefers (link, html, pdf), to who he wants. the user might also send with it an invitation (what about merging invitation manager with "share this page" ?) I would see this feature as a unique action (meaning do not allow to "force" the "watch" opt'in). Result, this feature would be presented both in the page edit bar in "export" or "more actions", as a "send by mail" action menu. It can be presented also as an option next to the "save" button : "save this page" opt'in, when selected it opens the related fields. The content should be : SEND BY MAIL To : [ ] all contributors [ ] additionnal users or groups [field] [ ] additionnal email [field] => we could here include an invitation manager option ? As : [ ] a link [ ] html content [ ] pdf Email title : [ <wiki name>, <space name>, <page name> ] => can be edited Email additional message : [ ] => a resume of the message could be added in the page comments, then we loose nothing thanks gregory
Hi, I hope a single paragraph from an user could be welcome here... Gregory GUENEAU wrote:
hi sergiu
Le 8 nov. 2010 à 10:35, Sergiu Dumitriu a écrit :
On 11/08/2010 01:44 AM, Ludovic Dubost wrote:
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
I don't like this, it's intrusive. Personally I wouldn't like at all being forcefully invited into a conversation. There are other ways of doing this which don't involve waking up with 30 emails in my inbox, most of which will be implemented in the 3.x cycle as part of the social improvements.
I don't agree with you that the social improvements do anything in this area or maybe I'm missing something. If it's activity streams or other real time features, oin many cases, you can't go all the time to the wiki to check if an important document is evolving, for which the discussion needs to be fast.
You might not like it, but this really creates dynamicity when discussing on a wiki document. The lack of such a features leads to discussions staying in email exchanges and therefore no work on the wiki document itself (when it was at all created). Think about a discussion about a feature in the devs mailing list. None of it is captured in the wiki page where the feature is described. Think also about non technical people that need to learn how to work with wikis.
I don't think we're talking about the same thing. I'm referring to "send notification to this bunch of people EVERY TIME THE PAGE CHANGES". I agree about the "send notification", but not about the "every time". I also agree with subscribing myself to notifications (a.k.a. "add to MY watchlist").
Then let's talk about what users are waiting for. We present xwiki as an enterprise wiki that proposes an overall experience to avoid some disagreement from the existing tools, such as discussion entropy in mails. BUT it doesn't mean xwiki has to stand alone in the universe, that is why we introduced the "watch" notification features.
We also have the invitation manager that covers other needs, but we have a missing link : invitation to a page, or more basic : "share this page" or "send this page by mail".
In my mind, this feature is key to power and dummy users. More, it atuomates and makes simple the simple act to share a page (usually, we copy the link, or make a pdf of the page, and then we go in our mail client and create a mail to ... anybody we want to share this page with), the feature we are talking about here prevents to do all this manual stuff.
Therefore this feature should allow the user to send the page with the methods he prefers (link, html, pdf), to who he wants. the user might also send with it an invitation (what about merging invitation manager with "share this page" ?)
Let's add something here thinking about how our users do work with XWiki. First of all, let me say that I support Ludovic and Vicent ideas about the necessity of having some kind of method to trigger discussion and conduct the flow toward XWiki moving it out of email exchange. I recognize the prevalence of email in ICT landscape nowadays and agree with Sergiu about the fact that subscription must be optional for users once they are aware a given work has been launched. They must be able to choose between the different alternatives XWiki offers to be aware of changes once they get a first warning. I see This "send this page by email" utility like an improvement in this sense. I will add a complement though: one a document is created and the creator will be allowed to select users and/or groups to be warned about this fact, the creator will be allowed to select what users can do what think. I mean, the same utility that allow the creator to select what users will receive the email message, will add trustees to the document. For us here the default condition for newly created documents is giving me some headaches. If the creator is allowed to select what users to warn and the same action adds trustees to the newly created document, will avoid many problems I'm facing here. Thanks for your work!
I would see this feature as a unique action (meaning do not allow to "force" the "watch" opt'in).
Result, this feature would be presented both in the page edit bar in "export" or "more actions", as a "send by mail" action menu. It can be presented also as an option next to the "save" button : "save this page" opt'in, when selected it opens the related fields.
The content should be :
SEND BY MAIL
To : [ ] all contributors [ ] additionnal users or groups [field] [ ] additionnal email [field] => we could here include an invitation manager option ?
As : [ ] a link [ ] html content [ ] pdf
Email title : [ <wiki name>, <space name>, <page name> ] => can be edited
Email additional message : [ ]
=> a resume of the message could be added in the page comments, then we loose nothing
thanks
gregory
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems
Le 08/11/10 10:35, Sergiu Dumitriu a écrit :
On 11/08/2010 01:44 AM, Ludovic Dubost wrote:
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
I don't like this, it's intrusive. Personally I wouldn't like at all being forcefully invited into a conversation. There are other ways of doing this which don't involve waking up with 30 emails in my inbox, most of which will be implemented in the 3.x cycle as part of the social improvements.
I don't agree with you that the social improvements do anything in this area or maybe I'm missing something. If it's activity streams or other real time features, oin many cases, you can't go all the time to the wiki to check if an important document is evolving, for which the discussion needs to be fast.
You might not like it, but this really creates dynamicity when discussing on a wiki document. The lack of such a features leads to discussions staying in email exchanges and therefore no work on the wiki document itself (when it was at all created). Think about a discussion about a feature in the devs mailing list. None of it is captured in the wiki page where the feature is described. Think also about non technical people that need to learn how to work with wikis. I don't think we're talking about the same thing. I'm referring to "send notification to this bunch of people EVERY TIME THE PAGE CHANGES". I agree about the "send notification", but not about the "every time". I also agree with subscribing myself to notifications (a.k.a. "add to MY watchlist"). I am talking about the "send notification to this bunch of people EVERY TIME THE PAGE CHANGES" with the possibility for users to opt out. The objective, and I'm probably repeating myself, is allow for PARTICULAR documents, to speed up the turnaround speed when working on a document, to avoid the current side effect of having a parallel discussion by email around the document without actually making any changes to the document and leaving all the work to the initial author.
The objective is to NOT NEED a separate discussion, it's not like Vincent seems to have understood it, to have discussions in the Wiki. The objective is that you only work with Wiki changes and Annotations so that you have a real workflow that really leads to improving the document. Currently and without such a feature we are undermining the Wiki concept by making it more difficult for people to centralize the content in the Wiki. Therefore people will stick to emails and the whole benefit of having a wiki page is moot. The manual subscription mecanism is a progress and it would be great to at least do that, but I can tell you that as a project manager, I would find annoying to not have a way to invite 2 or 3 people to this notification mecanism to make sure that the discussion can happen in the wiki instead of having a parallel track in emails Ludovic
Concerning being forced in a conversation, you can drop out in one click if you don't like it and it's the responsibility of the person sending the notification to actually decide to do that push. Of course this should not be done by default on all documents as this is meant for important docs for which a discussion is really needed, like a project manager bringing in 3 people he works with in a discussion. Managers need to be sure that what they want to do reaches their target. If editing the wiki page or commenting on a wiki page is not sure to reach it's target, the manager will reach out to other means (email, skype or even telephone). Once this happens you have lost of lot of valuable content.
Without the forcing, you can be sure that since some people will be missing the discussion won't work as well.
In any case please don't think about this feature for public discussions. It's meant for business users so that they can get the work done.
I agree about a "notify me of changes" checkbox under the action buttons, if Vincent doesn't think it crowds the editor UI.
That's definitively already usefull as any editor/commentor can decide to get instant notifications. But the minute you are not sure that the other user will get your comment, people will loose confident is this way of discussing.
Finally we could add an email box so that we can load comments sent as a reply to an email sent by the wiki. Yep, this is also an idea kept in the background, but too complex to be included inside the "email this page" development. I agree that it's some work and might be too much for this version. The rationale for this feature is that when working on a document that requires some discussion and validation, the email discussion is not captured and the changes in the wiki are not triggering a fast enough reaction thus slowing down the discussion around the document (I know the Watch List exists, but since it requires manual subscription, most participants won't do it and the speed of notification of the watch list is not fast enough for discussion). One idea of improvement for the watchlist was to have instant notifications, but this is another topic. In summary:
- add a new level for the watchlist which sends notifications as soon as a document is sent (as implementation, it will use the observation mechanism and not a scheduler job) - the current notification interval configuration will be kept as the default - for each item in the watchlist it will be possible to specify its own interval setting
Isn't your last paragraph contradicting your proposal? Email is slow and deprecated, and one of the main points when presenting XWiki is how much better it is than emails. Why would moving the discussion to emails help collaborative writing?
email usage should move from being the actual place of discussion to a notification tool. It's still a good notification tool for the important ones. Clearly if you are overloaded in one of your channels, then it's stops being effective. But well done it's a good notification tool. RSS or Twitter which are good at being notification tool for massive amounts of information are actually bad for the smaller amounts of important information. In my view it's about learning how to use a combination of these tools for that.
Back to the wiki, my objective here is not to move the discussion to emails, but to make sure that any discussion in the wiki get the same efficiency as email when it comes to notification of the discussion events. As for capturing responses in emails into the wiki this is to ease transition from email to wiki. I would expect that experiences users would click on the link to comment in the wiki since you would have more features there.
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On 11/08/2010 03:23 PM, Ludovic Dubost wrote:
Le 08/11/10 10:35, Sergiu Dumitriu a écrit :
On 11/08/2010 01:44 AM, Ludovic Dubost wrote:
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
I don't like this, it's intrusive. Personally I wouldn't like at all being forcefully invited into a conversation. There are other ways of doing this which don't involve waking up with 30 emails in my inbox, most of which will be implemented in the 3.x cycle as part of the social improvements.
I don't agree with you that the social improvements do anything in this area or maybe I'm missing something. If it's activity streams or other real time features, oin many cases, you can't go all the time to the wiki to check if an important document is evolving, for which the discussion needs to be fast.
You might not like it, but this really creates dynamicity when discussing on a wiki document. The lack of such a features leads to discussions staying in email exchanges and therefore no work on the wiki document itself (when it was at all created). Think about a discussion about a feature in the devs mailing list. None of it is captured in the wiki page where the feature is described. Think also about non technical people that need to learn how to work with wikis. I don't think we're talking about the same thing. I'm referring to "send notification to this bunch of people EVERY TIME THE PAGE CHANGES". I agree about the "send notification", but not about the "every time". I also agree with subscribing myself to notifications (a.k.a. "add to MY watchlist"). I am talking about the "send notification to this bunch of people EVERY TIME THE PAGE CHANGES" with the possibility for users to opt out. The objective, and I'm probably repeating myself, is allow for PARTICULAR documents, to speed up the turnaround speed when working on a document, to avoid the current side effect of having a parallel discussion by email around the document without actually making any changes to the document and leaving all the work to the initial author.
The objective is to NOT NEED a separate discussion, it's not like Vincent seems to have understood it, to have discussions in the Wiki.
The objective is that you only work with Wiki changes and Annotations so that you have a real workflow that really leads to improving the document.
Currently and without such a feature we are undermining the Wiki concept by making it more difficult for people to centralize the content in the Wiki. Therefore people will stick to emails and the whole benefit of having a wiki page is moot.
The manual subscription mecanism is a progress and it would be great to at least do that, but I can tell you that as a project manager, I would find annoying to not have a way to invite 2 or 3 people to this notification mecanism to make sure that the discussion can happen in the wiki instead of having a parallel track in emails
So by sending much more emails we keep people off emails and in the wiki? This logic really escapes me. If the manager wants to invite people to actively be involved in writing that document, he can send a notification once, telling in the custom message that "Hey bozos, this is critical, let's work on it", and the coworkers will find a way to work better together. Instant messaging is the best tool at the moment for fast collaboration. Realtime editing with integrated chat will be better. Email is just noise. In this end, this is about privacy. Why would we allow people to push things into other person's watchlist? Let's not go the Google Buzz way, we'd better think of how features can be used wrongly, too.
Concerning being forced in a conversation, you can drop out in one click if you don't like it and it's the responsibility of the person sending the notification to actually decide to do that push. Of course this should not be done by default on all documents as this is meant for important docs for which a discussion is really needed, like a project manager bringing in 3 people he works with in a discussion. Managers need to be sure that what they want to do reaches their target. If editing the wiki page or commenting on a wiki page is not sure to reach it's target, the manager will reach out to other means (email, skype or even telephone). Once this happens you have lost of lot of valuable content.
Without the forcing, you can be sure that since some people will be missing the discussion won't work as well.
In any case please don't think about this feature for public discussions. It's meant for business users so that they can get the work done.
I agree about a "notify me of changes" checkbox under the action buttons, if Vincent doesn't think it crowds the editor UI.
That's definitively already usefull as any editor/commentor can decide to get instant notifications. But the minute you are not sure that the other user will get your comment, people will loose confident is this way of discussing.
Finally we could add an email box so that we can load comments sent as a reply to an email sent by the wiki. Yep, this is also an idea kept in the background, but too complex to be included inside the "email this page" development. I agree that it's some work and might be too much for this version. The rationale for this feature is that when working on a document that requires some discussion and validation, the email discussion is not captured and the changes in the wiki are not triggering a fast enough reaction thus slowing down the discussion around the document (I know the Watch List exists, but since it requires manual subscription, most participants won't do it and the speed of notification of the watch list is not fast enough for discussion). One idea of improvement for the watchlist was to have instant notifications, but this is another topic. In summary:
- add a new level for the watchlist which sends notifications as soon as a document is sent (as implementation, it will use the observation mechanism and not a scheduler job) - the current notification interval configuration will be kept as the default - for each item in the watchlist it will be possible to specify its own interval setting
Isn't your last paragraph contradicting your proposal? Email is slow and deprecated, and one of the main points when presenting XWiki is how much better it is than emails. Why would moving the discussion to emails help collaborative writing?
email usage should move from being the actual place of discussion to a notification tool. It's still a good notification tool for the important ones. Clearly if you are overloaded in one of your channels, then it's stops being effective. But well done it's a good notification tool. RSS or Twitter which are good at being notification tool for massive amounts of information are actually bad for the smaller amounts of important information. In my view it's about learning how to use a combination of these tools for that.
Back to the wiki, my objective here is not to move the discussion to emails, but to make sure that any discussion in the wiki get the same efficiency as email when it comes to notification of the discussion events. As for capturing responses in emails into the wiki this is to ease transition from email to wiki. I would expect that experiences users would click on the link to comment in the wiki since you would have more features there.
Ludovic
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Le 08/11/10 15:54, Sergiu Dumitriu a écrit :
On 11/08/2010 03:23 PM, Ludovic Dubost wrote:
Le 08/11/10 10:35, Sergiu Dumitriu a écrit :
On 11/08/2010 01:44 AM, Ludovic Dubost wrote:
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
I don't like this, it's intrusive. Personally I wouldn't like at all being forcefully invited into a conversation. There are other ways of doing this which don't involve waking up with 30 emails in my inbox, most of which will be implemented in the 3.x cycle as part of the social improvements.
I don't agree with you that the social improvements do anything in this area or maybe I'm missing something. If it's activity streams or other real time features, oin many cases, you can't go all the time to the wiki to check if an important document is evolving, for which the discussion needs to be fast.
You might not like it, but this really creates dynamicity when discussing on a wiki document. The lack of such a features leads to discussions staying in email exchanges and therefore no work on the wiki document itself (when it was at all created). Think about a discussion about a feature in the devs mailing list. None of it is captured in the wiki page where the feature is described. Think also about non technical people that need to learn how to work with wikis. I don't think we're talking about the same thing. I'm referring to "send notification to this bunch of people EVERY TIME THE PAGE CHANGES". I agree about the "send notification", but not about the "every time". I also agree with subscribing myself to notifications (a.k.a. "add to MY watchlist"). I am talking about the "send notification to this bunch of people EVERY TIME THE PAGE CHANGES" with the possibility for users to opt out. The objective, and I'm probably repeating myself, is allow for PARTICULAR documents, to speed up the turnaround speed when working on a document, to avoid the current side effect of having a parallel discussion by email around the document without actually making any changes to the document and leaving all the work to the initial author.
The objective is to NOT NEED a separate discussion, it's not like Vincent seems to have understood it, to have discussions in the Wiki.
The objective is that you only work with Wiki changes and Annotations so that you have a real workflow that really leads to improving the document.
Currently and without such a feature we are undermining the Wiki concept by making it more difficult for people to centralize the content in the Wiki. Therefore people will stick to emails and the whole benefit of having a wiki page is moot.
The manual subscription mecanism is a progress and it would be great to at least do that, but I can tell you that as a project manager, I would find annoying to not have a way to invite 2 or 3 people to this notification mecanism to make sure that the discussion can happen in the wiki instead of having a parallel track in emails
So by sending much more emails we keep people off emails and in the wiki? This logic really escapes me.
If the manager wants to invite people to actively be involved in writing that document, he can send a notification once, telling in the custom message that "Hey bozos, this is critical, let's work on it", and the coworkers will find a way to work better together. Instant messaging is Hey sergiu, I challenge you. Put the "email this page" spec on xwiki.org and tell "Hey bozos, this is critical, let's work on it" and then let's see the turnaround speed about this spec without regular emails to the dev list, and let's see how many comments about the spec will be put in the wiki instead of being posted to the dev list.
Personnaly I would prefer the solution: "Hey bozos, I've added you to the notification list for this document since I believe it's and important one. You can opt-out anytime" then "Hey bozos, I've created this document. Think about clicking the subscribe box so that you know about all changes" The result is simple: half the people will forget doing it. The people won't get notifications. The manager will finally have to resend emails regularly to make things move. This feature is trying to make the manager or content manager's life easier. You are dismissing and "optional" feature for wrong reasons which don't apply in the environment this feature is meant for.
the best tool at the moment for fast collaboration. Realtime editing with integrated chat will be better. Email is just noise. It might be noise but that's what many people work with. Realtime editing would be great but is not there, and still this does not work with slower turnaround.
Aren't you receiving all xwiki's JIRAs in your email ? Aren't we auto subscribed to ALL email threads of this list ? Basically there is no intermediary between 1/ subscribe yourself to the pages that are important to you 2/ autosubscribe to all pages What I'm proposing is to let my coworkers subscribe me to things that they think are important to me, while letting me change that
In this end, this is about privacy. Why would we allow people to push things into other person's watchlist? Let's not go the Google Buzz way, we'd better think of how features can be used wrongly, too. Because they can opt-out. In an intranet (work) environment I don't see where the problem is (I repeat that this solution is intended for people that already work together, not for total strangers). The management of the company can decide wether or not this feature is wanted internally (and can be off by default).
But if it's about privacy what about having an option where the user can say he accepts auto subscription or not ? Why not also trusting users to use this wisely ? Ludovic
Concerning being forced in a conversation, you can drop out in one click if you don't like it and it's the responsibility of the person sending the notification to actually decide to do that push. Of course this should not be done by default on all documents as this is meant for important docs for which a discussion is really needed, like a project manager bringing in 3 people he works with in a discussion. Managers need to be sure that what they want to do reaches their target. If editing the wiki page or commenting on a wiki page is not sure to reach it's target, the manager will reach out to other means (email, skype or even telephone). Once this happens you have lost of lot of valuable content.
Without the forcing, you can be sure that since some people will be missing the discussion won't work as well.
In any case please don't think about this feature for public discussions. It's meant for business users so that they can get the work done.
I agree about a "notify me of changes" checkbox under the action buttons, if Vincent doesn't think it crowds the editor UI.
That's definitively already usefull as any editor/commentor can decide to get instant notifications. But the minute you are not sure that the other user will get your comment, people will loose confident is this way of discussing.
Finally we could add an email box so that we can load comments sent as a reply to an email sent by the wiki. Yep, this is also an idea kept in the background, but too complex to be included inside the "email this page" development. I agree that it's some work and might be too much for this version. The rationale for this feature is that when working on a document that requires some discussion and validation, the email discussion is not captured and the changes in the wiki are not triggering a fast enough reaction thus slowing down the discussion around the document (I know the Watch List exists, but since it requires manual subscription, most participants won't do it and the speed of notification of the watch list is not fast enough for discussion). One idea of improvement for the watchlist was to have instant notifications, but this is another topic. In summary:
- add a new level for the watchlist which sends notifications as soon as a document is sent (as implementation, it will use the observation mechanism and not a scheduler job) - the current notification interval configuration will be kept as the default - for each item in the watchlist it will be possible to specify its own interval setting
Isn't your last paragraph contradicting your proposal? Email is slow and deprecated, and one of the main points when presenting XWiki is how much better it is than emails. Why would moving the discussion to emails help collaborative writing?
email usage should move from being the actual place of discussion to a notification tool. It's still a good notification tool for the important ones. Clearly if you are overloaded in one of your channels, then it's stops being effective. But well done it's a good notification tool. RSS or Twitter which are good at being notification tool for massive amounts of information are actually bad for the smaller amounts of important information. In my view it's about learning how to use a combination of these tools for that.
Back to the wiki, my objective here is not to move the discussion to emails, but to make sure that any discussion in the wiki get the same efficiency as email when it comes to notification of the discussion events. As for capturing responses in emails into the wiki this is to ease transition from email to wiki. I would expect that experiences users would click on the link to comment in the wiki since you would have more features there.
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On 11/10/2010 08:21 PM, Ludovic Dubost wrote:
Le 08/11/10 15:54, Sergiu Dumitriu a écrit :
On 11/08/2010 03:23 PM, Ludovic Dubost wrote:
Le 08/11/10 10:35, Sergiu Dumitriu a écrit :
On 11/08/2010 01:44 AM, Ludovic Dubost wrote:
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
I don't like this, it's intrusive. Personally I wouldn't like at all being forcefully invited into a conversation. There are other ways of doing this which don't involve waking up with 30 emails in my inbox, most of which will be implemented in the 3.x cycle as part of the social improvements.
I don't agree with you that the social improvements do anything in this area or maybe I'm missing something. If it's activity streams or other real time features, oin many cases, you can't go all the time to the wiki to check if an important document is evolving, for which the discussion needs to be fast.
You might not like it, but this really creates dynamicity when discussing on a wiki document. The lack of such a features leads to discussions staying in email exchanges and therefore no work on the wiki document itself (when it was at all created). Think about a discussion about a feature in the devs mailing list. None of it is captured in the wiki page where the feature is described. Think also about non technical people that need to learn how to work with wikis. I don't think we're talking about the same thing. I'm referring to "send notification to this bunch of people EVERY TIME THE PAGE CHANGES". I agree about the "send notification", but not about the "every time". I also agree with subscribing myself to notifications (a.k.a. "add to MY watchlist"). I am talking about the "send notification to this bunch of people EVERY TIME THE PAGE CHANGES" with the possibility for users to opt out. The objective, and I'm probably repeating myself, is allow for PARTICULAR documents, to speed up the turnaround speed when working on a document, to avoid the current side effect of having a parallel discussion by email around the document without actually making any changes to the document and leaving all the work to the initial author.
The objective is to NOT NEED a separate discussion, it's not like Vincent seems to have understood it, to have discussions in the Wiki.
The objective is that you only work with Wiki changes and Annotations so that you have a real workflow that really leads to improving the document.
Currently and without such a feature we are undermining the Wiki concept by making it more difficult for people to centralize the content in the Wiki. Therefore people will stick to emails and the whole benefit of having a wiki page is moot.
The manual subscription mecanism is a progress and it would be great to at least do that, but I can tell you that as a project manager, I would find annoying to not have a way to invite 2 or 3 people to this notification mecanism to make sure that the discussion can happen in the wiki instead of having a parallel track in emails
So by sending much more emails we keep people off emails and in the wiki? This logic really escapes me.
If the manager wants to invite people to actively be involved in writing that document, he can send a notification once, telling in the custom message that "Hey bozos, this is critical, let's work on it", and the coworkers will find a way to work better together. Instant messaging is Hey sergiu, I challenge you. Put the "email this page" spec on xwiki.org and tell "Hey bozos, this is critical, let's work on it" and then let's see the turnaround speed about this spec without regular emails to the dev list, and let's see how many comments about the spec will be put in the wiki instead of being posted to the dev list.
Personnaly I would prefer the solution:
"Hey bozos, I've added you to the notification list for this document since I believe it's and important one. You can opt-out anytime" then "Hey bozos, I've created this document. Think about clicking the subscribe box so that you know about all changes"
The result is simple: half the people will forget doing it. The people won't get notifications. The manager will finally have to resend emails regularly to make things move. This feature is trying to make the manager or content manager's life easier. You are dismissing and "optional" feature for wrong reasons which don't apply in the environment this feature is meant for.
the best tool at the moment for fast collaboration. Realtime editing with integrated chat will be better. Email is just noise. It might be noise but that's what many people work with. Realtime editing would be great but is not there, and still this does not work with slower turnaround.
Aren't you receiving all xwiki's JIRAs in your email ? Aren't we auto subscribed to ALL email threads of this list ? Basically there is no intermediary between
1/ subscribe yourself to the pages that are important to you 2/ autosubscribe to all pages
What I'm proposing is to let my coworkers subscribe me to things that they think are important to me, while letting me change that
In this end, this is about privacy. Why would we allow people to push things into other person's watchlist? Let's not go the Google Buzz way, we'd better think of how features can be used wrongly, too. Because they can opt-out. In an intranet (work) environment I don't see where the problem is (I repeat that this solution is intended for people that already work together, not for total strangers). The management of the company can decide wether or not this feature is wanted internally (and can be off by default).
But if it's about privacy what about having an option where the user can say he accepts auto subscription or not ?
Why not also trusting users to use this wisely ?
OK, there are valid use cases, so I'll implement this as well, as a configurable feature.
Concerning being forced in a conversation, you can drop out in one click if you don't like it and it's the responsibility of the person sending the notification to actually decide to do that push. Of course this should not be done by default on all documents as this is meant for important docs for which a discussion is really needed, like a project manager bringing in 3 people he works with in a discussion. Managers need to be sure that what they want to do reaches their target. If editing the wiki page or commenting on a wiki page is not sure to reach it's target, the manager will reach out to other means (email, skype or even telephone). Once this happens you have lost of lot of valuable content.
Without the forcing, you can be sure that since some people will be missing the discussion won't work as well.
In any case please don't think about this feature for public discussions. It's meant for business users so that they can get the work done.
I agree about a "notify me of changes" checkbox under the action buttons, if Vincent doesn't think it crowds the editor UI.
That's definitively already usefull as any editor/commentor can decide to get instant notifications. But the minute you are not sure that the other user will get your comment, people will loose confident is this way of discussing.
> Finally we could add an email box so that we can load comments sent > as a > reply to an email sent by the wiki. Yep, this is also an idea kept in the background, but too complex to be included inside the "email this page" development. I agree that it's some work and might be too much for this version. > The rationale for this feature is that when working on a document > that > requires some discussion and validation, the email discussion is not > captured and the changes in the wiki are not triggering a fast > enough > reaction thus slowing down the discussion around the document (I > know > the Watch List exists, but since it requires manual subscription, > most > participants won't do it and the speed of notification of the watch > list > is not fast enough for discussion). One idea of improvement for the watchlist was to have instant notifications, but this is another topic. In summary:
- add a new level for the watchlist which sends notifications as soon as a document is sent (as implementation, it will use the observation mechanism and not a scheduler job) - the current notification interval configuration will be kept as the default - for each item in the watchlist it will be possible to specify its own interval setting
Isn't your last paragraph contradicting your proposal? Email is slow and deprecated, and one of the main points when presenting XWiki is how much better it is than emails. Why would moving the discussion to emails help collaborative writing?
email usage should move from being the actual place of discussion to a notification tool. It's still a good notification tool for the important ones. Clearly if you are overloaded in one of your channels, then it's stops being effective. But well done it's a good notification tool. RSS or Twitter which are good at being notification tool for massive amounts of information are actually bad for the smaller amounts of important information. In my view it's about learning how to use a combination of these tools for that.
Back to the wiki, my objective here is not to move the discussion to emails, but to make sure that any discussion in the wiki get the same efficiency as email when it comes to notification of the discussion events. As for capturing responses in emails into the wiki this is to ease transition from email to wiki. I would expect that experiences users would click on the link to comment in the wiki since you would have more features there.
Ludovic
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (5)
-
[Ricardo Rodriguez] eBioTIC. -
Gregory GUENEAU -
Ludovic Dubost -
Sergiu Dumitriu -
Vincent Massol