[xwiki-devs] Should email invitation app be a top level application? How should I add it to the sandbox?
I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great. Caleb
Hi Caleb, On Tue, Apr 20, 2010 at 12:42, Caleb James DeLisle <[email protected]
wrote:
I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great.
Usually Vincent answers those but it looks like he doesn't have the time to do it right now. I think that it should indeed be a separate application (same level as panels or search or tags in JIRA). As for where to put it in the sandbox, I guess as a top-level application in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/ Guillaume
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On Apr 20, 2010, at 12:40 PM, Guillaume Lerouge wrote:
Hi Caleb,
On Tue, Apr 20, 2010 at 12:42, Caleb James DeLisle <[email protected]
wrote:
I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great.
Usually Vincent answers those but it looks like he doesn't have the time to do it right now.
To remove any ambiguity: I'm definitely not "assigned" to answer any type of question. We work as a community and all committers have the same powers and duties ;) (I know you didn't mean it in this sense but it could be misleading) Thanks -Vincent
I think that it should indeed be a separate application (same level as panels or search or tags in JIRA). As for where to put it in the sandbox, I guess as a top-level application in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/
Guillaume
On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote:
I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great.
+1 for a top level app in platform/applications (which means a jira for it too). As for the process, I'm proposing: 1) explain what this app would do (maybe you already did?) and show a mockup of its UI so that we can agree about it and get help for our community designers 2) send a vote mail to include the invitation manager in XE by default (if not already done) 3) code it, you could start in the sandbox indeed or directly in platform/applications if 1) and 2) have been agreed on. Thanks -Vincent
Another matter is what should it be named, I have been calling it "friendInviter" which is an awkward name but invitation manager is a name which will lead to confusion since it does not use the invitation manager plugin. Vincent Massol wrote:
On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote:
I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great.
+1 for a top level app in platform/applications (which means a jira for it too).
As for the process, I'm proposing: 1) explain what this app would do (maybe you already did?) I described what I hoped to achieve here: http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
and show a mockup of its UI so that we can agree about it and get help for our community designers There has been one here for a while, I rewrote the code but the UI is the same. http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
2) send a vote mail to include the invitation manager in XE by default (if not already done) I'd like to have something concrete in the sandbox to vote on.
3) code it, you could start in the sandbox indeed or directly in platform/applications if 1) and 2) have been agreed on. I will commit to the sandbox later today.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Apr 20, 2010, at 2:45 PM, Caleb James DeLisle wrote:
Another matter is what should it be named, I have been calling it "friendInviter" which is an awkward name but invitation manager is a name which will lead to confusion since it does not use the invitation manager plugin.
Since it's meant to replace the existing invitation manager so it seems a good name for me. It's the invitation manager plugin done using the component architecture. It could also simply be called xwiki-invitation, i.e. the "Invitation" module.
Vincent Massol wrote:
On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote:
I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great.
+1 for a top level app in platform/applications (which means a jira for it too).
As for the process, I'm proposing: 1) explain what this app would do (maybe you already did?) I described what I hoped to achieve here: http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
and show a mockup of its UI so that we can agree about it and get help for our community designers There has been one here for a while, I rewrote the code but the UI is the same. http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
Jerome, Caty: do you think you could comment on that? - I'm mentioning Jerome since he's the one who coded the invitation manager for XWS. We need to make sure it's not missing anything important in term of features or ease of use - I'm mentioning Caty since she's been participating a lot to our XE design for a while Everyone should participate of course! Please all voice your opinions about what the invitation module should have both in term of features and UI.
2) send a vote mail to include the invitation manager in XE by default (if not already done) I'd like to have something concrete in the sandbox to vote on.
3) code it, you could start in the sandbox indeed or directly in platform/applications if 1) and 2) have been agreed on. I will commit to the sandbox later today.
Thanks -Vincent
Hi, On Tue, Apr 20, 2010 at 14:58, Vincent Massol <[email protected]> wrote:
On Apr 20, 2010, at 2:45 PM, Caleb James DeLisle wrote:
Another matter is what should it be named, I have been calling it "friendInviter" which is an awkward name but invitation manager is a name which will lead to confusion since it does not use the invitation manager plugin.
Since it's meant to replace the existing invitation manager so it seems a good name for me. It's the invitation manager plugin done using the component architecture.
It could also simply be called xwiki-invitation, i.e. the "Invitation" module.
"xwiki-invitation" sounds good to me.
Vincent Massol wrote:
On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote:
I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great.
+1 for a top level app in platform/applications (which means a jira for it too).
As for the process, I'm proposing: 1) explain what this app would do (maybe you already did?) I described what I hoped to achieve here:
http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
and show a mockup of its UI so that we can agree about it and get help
for our community designers
There has been one here for a while, I rewrote the code but the UI is the same. http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
Jerome, Caty: do you think you could comment on that?
- I'm mentioning Jerome since he's the one who coded the invitation manager for XWS. We need to make sure it's not missing anything important in term of features or ease of use
One nice feature that used to be there is "invite mailing list". I'm not sure it's supported in the current version. It allowed to send a message to a list such as [email protected] and all users clicking the link from that email were able to register for a period of 30 days (or something like that). Maybe a bit dangerous from a security standpoint though. Guillaume
- I'm mentioning Caty since she's been participating a lot to our XE design for a while
Everyone should participate of course! Please all voice your opinions about what the invitation module should have both in term of features and UI.
2) send a vote mail to include the invitation manager in XE by default (if not already done) I'd like to have something concrete in the sandbox to vote on.
3) code it, you could start in the sandbox indeed or directly in platform/applications if 1) and 2) have been agreed on. I will commit to the sandbox later today.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi Caleb, Caleb James DeLisle wrote:
Another matter is what should it be named, I have been calling it "friendInviter" which is an awkward name but invitation manager is a name which will lead to confusion since it does not use the invitation manager plugin.
xwiki-invitation sounds good to me too, as Vincent suggested.
Vincent Massol wrote:
On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote:
I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great. +1 for a top level app in platform/applications (which means a jira for it too).
As for the process, I'm proposing: 1) explain what this app would do (maybe you already did?) I described what I hoped to achieve here: http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
and show a mockup of its UI so that we can agree about it and get help for our community designers There has been one here for a while, I rewrote the code but the UI is the same. http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
I couldn't find a mockup for displaying the list of invitations (pending/accepted) sent by the user. I think this should appear somewhere on the user profile. Also, is it possible to cancel an invitation? I have two use cases in mind: * the user sends the invitation to the wrong email address * the user wants to delete invitations that haven't been accepted in a specific amount of time (e.g. the invitee is asked to register before a given date) How is the invitation application going to work in a wiki where registration is disabled? i.e. you have to be invited to be able to register. Regarding the send invitation form, I think it would be useful to add explanatory text below each label. For instance, it's not clear that the user has to enter an email address in the "Who you are inviting:" field (can I enter multiple email addresses?). Also on the same page we should describe what happens with the invitation (the fact than an email is sent to the specified email address) and ask the user to not abuse this feature because his right to send invitations can be removed if his invitations are reported as spam. Hope this helps, Marius
2) send a vote mail to include the invitation manager in XE by default (if not already done) I'd like to have something concrete in the sandbox to vote on.
3) code it, you could start in the sandbox indeed or directly in platform/applications if 1) and 2) have been agreed on. I will commit to the sandbox later today. Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea < [email protected]> wrote:
Hi Caleb,
Caleb James DeLisle wrote:
Another matter is what should it be named, I have been calling it "friendInviter" which is an awkward name but invitation manager is a name which will lead to confusion since it does not use the invitation manager plugin.
xwiki-invitation sounds good to me too, as Vincent suggested.
Vincent Massol wrote:
On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote:
I have a working prototype of the invitation mail sender and I would
like to put it in the sandbox.
I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great. +1 for a top level app in platform/applications (which means a jira for it too).
As for the process, I'm proposing: 1) explain what this app would do (maybe you already did?) I described what I hoped to achieve here:
http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
and show a mockup of its UI so that we can agree about it and get help for our community designers There has been one here for a while, I rewrote the code but the UI is the same. http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
I couldn't find a mockup for displaying the list of invitations (pending/accepted) sent by the user.
After all people accepted, do we still keep the list of invited people? Is this a token of user's popularity? :P Just like Gmail, you could have a limited number of people you could invite in the wiki and take care of your followers :) we shouldn't do that, but was just an idea.
I think this should appear somewhere on the user profile. Also, is it possible to cancel an invitation? I have two use cases in mind:
* the user sends the invitation to the wrong email address * the user wants to delete invitations that haven't been accepted in a specific amount of time (e.g. the invitee is asked to register before a given date)
If this step would be for the administrator, would be nice from the list of accepted users, that we can apply batch operations for giving rights and adding people in certain groups. Again, just an idea.
How is the invitation application going to work in a wiki where registration is disabled? i.e. you have to be invited to be able to register.
Regarding the send invitation form, I think it would be useful to add explanatory text below each label. For instance, it's not clear that the user has to enter an email address in the "Who you are inviting:" field (can I enter multiple email addresses?). Also on the same page we should describe what happens with the invitation (the fact than an email is sent to the specified email address) and ask the user to not abuse this feature because his right to send invitations can be removed if his invitations are reported as spam.
I don't understand why you have 2 interfaces that do the same thing. Why there is a version if you have edit right for the page? If you don't have edit rights you shouldn't see a form, but just the labels and content of the form elements, or nothing at all. The first problem I see in the usability is, like Marius said, inviting multiple people in the same step. This step is essentially for the productivity and is working different in the view/pretendEdit right mode. In the pretendEdit mode you have a textarea for entering lists of emails with separators. The view mode has validation for the email field. Do you plan to validate the multiple mails too? Also users are not very good at following directions like "*with a comma and a space*". A solution for this would be just like the way we add Tags. Provide an overlay for entering emails one by one. This way you can validate them in the overlay and also take care of the separators. The emails could be deleted using the corner X. The problem with this solution is if the user is experimented and he has a standard list of emails he wants to paste, without entering one by one. We should satisfy both use cases. Caty
Hope this helps, Marius
2) send a vote mail to include the invitation manager in XE by default
(if not already done)
I'd like to have something concrete in the sandbox to vote on.
3) code it, you could start in the sandbox indeed or directly in platform/applications if 1) and 2) have been agreed on. I will commit to the sandbox later today. Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Also, when you hit the Preview, you actually see that Subject and Message fields have standard content. This content should be displayed from the start and the user should have control over it. Most of the users will leave the standard configurations alone. On Wed, Apr 21, 2010 at 11:15, Ecaterina Valica <[email protected]> wrote:
On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea < [email protected]> wrote:
Hi Caleb,
Caleb James DeLisle wrote:
Another matter is what should it be named, I have been calling it "friendInviter" which is an awkward name but invitation manager is a name which will lead to confusion since it does not use the invitation manager plugin.
xwiki-invitation sounds good to me too, as Vincent suggested.
Vincent Massol wrote:
On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote:
I have a working prototype of the invitation mail sender and I would
like to put it in the sandbox.
I need to know how that should be done and should this be a separate top level project on jira? Some guidance here would be great. +1 for a top level app in platform/applications (which means a jira for it too).
As for the process, I'm proposing: 1) explain what this app would do (maybe you already did?) I described what I hoped to achieve here:
http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
and show a mockup of its UI so that we can agree about it and get help for our community designers There has been one here for a while, I rewrote the code but the UI is the same.
http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
I couldn't find a mockup for displaying the list of invitations (pending/accepted) sent by the user.
After all people accepted, do we still keep the list of invited people? Is this a token of user's popularity? :P Just like Gmail, you could have a limited number of people you could invite in the wiki and take care of your followers :) we shouldn't do that, but was just an idea.
I think this should appear somewhere on the user profile. Also, is it possible to cancel an invitation? I have two use cases in mind:
* the user sends the invitation to the wrong email address * the user wants to delete invitations that haven't been accepted in a specific amount of time (e.g. the invitee is asked to register before a given date)
If this step would be for the administrator, would be nice from the list of accepted users, that we can apply batch operations for giving rights and adding people in certain groups. Again, just an idea.
How is the invitation application going to work in a wiki where registration is disabled? i.e. you have to be invited to be able to register.
Regarding the send invitation form, I think it would be useful to add explanatory text below each label. For instance, it's not clear that the user has to enter an email address in the "Who you are inviting:" field (can I enter multiple email addresses?). Also on the same page we should describe what happens with the invitation (the fact than an email is sent to the specified email address) and ask the user to not abuse this feature because his right to send invitations can be removed if his invitations are reported as spam.
I don't understand why you have 2 interfaces that do the same thing. Why there is a version if you have edit right for the page? If you don't have edit rights you shouldn't see a form, but just the labels and content of the form elements, or nothing at all.
The first problem I see in the usability is, like Marius said, inviting multiple people in the same step. This step is essentially for the productivity and is working different in the view/pretendEdit right mode.
In the pretendEdit mode you have a textarea for entering lists of emails with separators. The view mode has validation for the email field. Do you plan to validate the multiple mails too? Also users are not very good at following directions like "*with a comma and a space*".
A solution for this would be just like the way we add Tags. Provide an overlay for entering emails one by one. This way you can validate them in the overlay and also take care of the separators. The emails could be deleted using the corner X.
The problem with this solution is if the user is experimented and he has a standard list of emails he wants to paste, without entering one by one. We should satisfy both use cases.
Caty
Hope this helps, Marius
2) send a vote mail to include the invitation manager in XE by default
(if not already done)
I'd like to have something concrete in the sandbox to vote on.
3) code it, you could start in the sandbox indeed or directly in platform/applications if 1) and 2) have been agreed on. I will commit to the sandbox later today. Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Ecaterina Valica wrote: > Also, when you hit the Preview, you actually see that Subject and Message > fields have standard content. This content should be displayed from the > start and the user should have control over it. I was thinking the mail should give some explanation of why the email was sent, suppose the user clears the default content and sets "buy cheap pharmaceuticals....." as the entire content. The mail recipient will have no way of knowing how the mail got to them or reporting it as spam. Anyway the default template is adjustable in the admin app so it's just a matter of what it is by default. > Most of the users will leave > the standard configurations alone. > > On Wed, Apr 21, 2010 at 11:15, Ecaterina Valica <[email protected]> wrote: > >> >> On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea < >> [email protected]> wrote: >> >>> Hi Caleb, >>> >>> Caleb James DeLisle wrote: >>>> Another matter is what should it be named, I have been calling it >>> "friendInviter" which is an awkward name >>>> but invitation manager is a name which will lead to confusion since it >>> does not use the invitation manager >>>> plugin. >>> xwiki-invitation sounds good to me too, as Vincent suggested. >>> >>>> Vincent Massol wrote: >>>>> On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote: >>>>> >>>>>> I have a working prototype of the invitation mail sender and I would >>> like to put it in the sandbox. >>>>>> I need to know how that should be done and should this be a separate >>> top level project on jira? >>>>>> Some guidance here would be great. >>>>> +1 for a top level app in platform/applications (which means a jira for >>> it too). >>>>> As for the process, I'm proposing: >>>>> 1) explain what this app would do (maybe you already did?) >>>> I described what I hoped to achieve here: >>>> >>> http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-send-mail-inviting-their-friends-to-join-a-wiki.html >>>> and show a mockup of its UI so that we can agree about it and get help >>> for our community designers >>>> There has been one here for a while, I rewrote the code but the UI is >>> the same. >>> http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter >>> >>> I couldn't find a mockup for displaying the list of invitations >>> (pending/accepted) sent by the user. Something I hadn't thought of, shouldn't be very hard to implement. >> >> After all people accepted, do we still keep the list of invited people? Is >> this a token of user's popularity? :P Just like Gmail, you could have a >> limited number of people you could invite in the wiki and take care of your >> followers :) we shouldn't do that, but was just an idea. There is nothing that advanced at the moment but it can be discussed. >> >> >>> I think this should appear >>> somewhere on the user profile. What exactly would it say in the profile. I'm somewhat resistant to the idea because it can't currently be done with modularity. >>> Also, is it possible to cancel an >>> invitation? Somehow stop the email en route? Send another one saying "just kidding"? When the user comes to sign up say: "Nobody really likes you we were just kidding." Anyway the join button currently only redirects to the registration page and does nothing special. >>> I have two use cases in mind: >>> >>> * the user sends the invitation to the wrong email address >>> * the user wants to delete invitations that haven't been accepted in a >>> specific amount of time (e.g. the invitee is asked to register before a >>> given date) >>> >> If this step would be for the administrator, would be nice from the list of >> accepted users, that we can apply batch operations for giving rights and >> adding people in certain groups. Again, just an idea. Have to change the nature of the registration process + no UI extensions = no modularity. It could be done though. >> >> >>> How is the invitation application going to work in a wiki where >>> registration is disabled? i.e. you have to be invited to be able to >>> register. Another use case I didn't think of. Might require API changes if registration is blocked by setting register permission to deny. Also will cause some kind of dependency. I try to resist dependencies lest every page depend on every other page and removal of one causes total destruction of the system. Still this sounds like a compelling use case. Maybe this should be implemented now or road mapped for later? Any thoughts? >>> >>> Regarding the send invitation form, I think it would be useful to add >>> explanatory text below each label. For instance, it's not clear that the >>> user has to enter an email address in the "Who you are inviting:" field >>> (can I enter multiple email addresses?). Only if you can edit the page (admin) but I see your point. Should the explaination be in line or in a separate help page? >>> Also on the same page we should >>> describe what happens with the invitation (the fact than an email is >>> sent to the specified email address) and ask the user to not abuse this >>> feature because his right to send invitations can be removed if his >>> invitations are reported as spam. >>> >> I don't understand why you have 2 interfaces that do the same thing. Those who have edit get special privileges (send to multiple addresses, configure the application etc.) >> Why >> there is a version if you have edit right for the page? If you don't have >> edit rights you shouldn't see a form, but just the labels and content of the >> form elements, or nothing at all. It is targeted toward those who don't have edit on the page. Otherwise why would we try to thwart spam when the user can simply edit the code and remove our measures. >> >> The first problem I see in the usability is, like Marius said, inviting >> multiple people in the same step. This step is essentially for the >> productivity and is working different in the view/pretendEdit right mode. It should not be working unless the user has edit. >> >> In the pretendEdit mode you have a textarea for entering lists of emails >> with separators. The view mode has validation for the email field. Do you >> plan to validate the multiple mails too? There is server side validation, LiveValidation would need a separate regular expression for multiple email addresses, it's an easy change to make but will lead to plenty of trouble if the admins waht to change the email validation regular expression. barring that I would have to change LiveValidation which is a third party library. >> Also users are not very good at >> following directions like "*with a comma and a space*". Yes, that's something I have changed (now it's just a space since it seems more intuitive) >> >> A solution for this would be just like the way we add Tags. Provide an >> overlay for entering emails one by one. This way you can validate them in >> the overlay and also take care of the separators. The emails could be >> deleted using the corner X. I imagined the main use case was for admins (those with edit) copy-pasting lists of addresses into the page keep in mind, non admins are unable to use this feature and I'd like to put most of the time into features which will be used often. Maybe we could wait and implement this type of thing later on if there is desire. How important do you think it is to have this now? >> >> The problem with this solution is if the user is experimented and he has a >> standard list of emails he wants to paste, without entering one by one. We >> should satisfy both use cases. Thank you for the responses, it's always hard for me writing the code to see all of the use cases. Caleb >> >> Caty >> >> >>> Hope this helps, >>> Marius >>> >>>>> 2) send a vote mail to include the invitation manager in XE by default >>> (if not already done) >>>> I'd like to have something concrete in the sandbox to vote on. >>>> >>>>> 3) code it, you could start in the sandbox indeed or directly in >>> platform/applications if 1) and 2) have been agreed on. >>>> I will commit to the sandbox later today. >>>>> Thanks >>>>> -Vincent >>>>> _______________________________________________ >>>>> devs mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
See below, Caleb James DeLisle wrote:
Ecaterina Valica wrote:
Also, when you hit the Preview, you actually see that Subject and Message fields have standard content. This content should be displayed from the start and the user should have control over it. I was thinking the mail should give some explanation of why the email was sent, suppose the user clears the default content and sets "buy cheap pharmaceuticals....." as the entire content. The mail recipient will have no way of knowing how the mail got to them or reporting it as spam. Anyway the default template is adjustable in the admin app so it's just a matter of what it is by default.
Most of the users will leave the standard configurations alone.
On Wed, Apr 21, 2010 at 11:15, Ecaterina Valica <[email protected]> wrote:
On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea < [email protected]> wrote:
Hi Caleb,
Caleb James DeLisle wrote:
Another matter is what should it be named, I have been calling it "friendInviter" which is an awkward name but invitation manager is a name which will lead to confusion since it does not use the invitation manager plugin. xwiki-invitation sounds good to me too, as Vincent suggested.
Vincent Massol wrote:
On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote:
> I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. > I need to know how that should be done and should this be a separate top level project on jira? > Some guidance here would be great. +1 for a top level app in platform/applications (which means a jira for it too). As for the process, I'm proposing: 1) explain what this app would do (maybe you already did?) I described what I hoped to achieve here:
http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
and show a mockup of its UI so that we can agree about it and get help for our community designers There has been one here for a while, I rewrote the code but the UI is the same. http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
I couldn't find a mockup for displaying the list of invitations (pending/accepted) sent by the user. Something I hadn't thought of, shouldn't be very hard to implement.
After all people accepted, do we still keep the list of invited people? Is this a token of user's popularity? :P Just like Gmail, you could have a limited number of people you could invite in the wiki and take care of your followers :) we shouldn't do that, but was just an idea. There is nothing that advanced at the moment but it can be discussed.
I think this should appear somewhere on the user profile.
What exactly would it say in the profile. I'm somewhat resistant to the idea because it can't currently be done with modularity.
Also, is it possible to cancel an invitation?
Somehow stop the email en route? Send another one saying "just kidding"? When the user comes to sign up say: "Nobody really likes you we were just kidding." Anyway the join button currently only redirects to the registration page and does nothing special.
In the case where registration is allowed only for invited people, you'll want for sure to cancel an invitation sent to a wrong email address. By cancel I mean just marking somehow the invitation object as "invalid". Sending a "sorry for the noise" mail is nut such a bad idea.
I have two use cases in mind:
* the user sends the invitation to the wrong email address * the user wants to delete invitations that haven't been accepted in a specific amount of time (e.g. the invitee is asked to register before a given date)
If this step would be for the administrator, would be nice from the list of accepted users, that we can apply batch operations for giving rights and adding people in certain groups. Again, just an idea. Have to change the nature of the registration process + no UI extensions = no modularity. It could be done though.
How is the invitation application going to work in a wiki where registration is disabled? i.e. you have to be invited to be able to register.
Another use case I didn't think of. Might require API changes if registration is blocked by setting register permission to deny. Also will cause some kind of dependency. I try to resist dependencies lest every page depend on every other page and removal of one causes total destruction of the system. Still this sounds like a compelling use case. Maybe this should be implemented now or road mapped for later? Any thoughts?
Regarding the send invitation form, I think it would be useful to add explanatory text below each label. For instance, it's not clear that the user has to enter an email address in the "Who you are inviting:" field (can I enter multiple email addresses?). Only if you can edit the page (admin) but I see your point. Should the explaination be in line or in a separate help page?
In line is best, IMO. Thanks, Marius
Also on the same page we should describe what happens with the invitation (the fact than an email is sent to the specified email address) and ask the user to not abuse this feature because his right to send invitations can be removed if his invitations are reported as spam.
I don't understand why you have 2 interfaces that do the same thing. Those who have edit get special privileges (send to multiple addresses, configure the application etc.)
Why there is a version if you have edit right for the page? If you don't have edit rights you shouldn't see a form, but just the labels and content of the form elements, or nothing at all. It is targeted toward those who don't have edit on the page. Otherwise why would we try to thwart spam when the user can simply edit the code and remove our measures.
The first problem I see in the usability is, like Marius said, inviting multiple people in the same step. This step is essentially for the productivity and is working different in the view/pretendEdit right mode. It should not be working unless the user has edit.
In the pretendEdit mode you have a textarea for entering lists of emails with separators. The view mode has validation for the email field. Do you plan to validate the multiple mails too? There is server side validation, LiveValidation would need a separate regular expression for multiple email addresses, it's an easy change to make but will lead to plenty of trouble if the admins waht to change the email validation regular expression. barring that I would have to change LiveValidation which is a third party library.
Also users are not very good at following directions like "*with a comma and a space*". Yes, that's something I have changed (now it's just a space since it seems more intuitive)
A solution for this would be just like the way we add Tags. Provide an overlay for entering emails one by one. This way you can validate them in the overlay and also take care of the separators. The emails could be deleted using the corner X. I imagined the main use case was for admins (those with edit) copy-pasting lists of addresses into the page keep in mind, non admins are unable to use this feature and I'd like to put most of the time into features which will be used often. Maybe we could wait and implement this type of thing later on if there is desire. How important do you think it is to have this now?
The problem with this solution is if the user is experimented and he has a standard list of emails he wants to paste, without entering one by one. We should satisfy both use cases.
Thank you for the responses, it's always hard for me writing the code to see all of the use cases.
Caleb
Caty
Hope this helps, Marius
2) send a vote mail to include the invitation manager in XE by default (if not already done) I'd like to have something concrete in the sandbox to vote on.
3) code it, you could start in the sandbox indeed or directly in platform/applications if 1) and 2) have been agreed on. I will commit to the sandbox later today. Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
"*evalica has invited you to join incubator.myxwiki.org*" this should be replaced with First Name and Last Name, instead of account name. These messages tend to be personal and the receiver should recognize the person without knowing it's nickname. In my vision this is a feature that could be used by everyone and not just admins. Caty On Wed, Apr 21, 2010 at 15:17, Marius Dumitru Florea < [email protected]> wrote:
See below,
Caleb James DeLisle wrote:
Ecaterina Valica wrote:
Also, when you hit the Preview, you actually see that Subject and
Message
fields have standard content. This content should be displayed from the start and the user should have control over it. I was thinking the mail should give some explanation of why the email was sent, suppose the user clears the default content and sets "buy cheap pharmaceuticals....." as the entire content. The mail recipient will have no way of knowing how the mail got to them or reporting it as spam. Anyway the default template is adjustable in the admin app so it's just a matter of what it is by default.
Most of the users will leave the standard configurations alone.
On Wed, Apr 21, 2010 at 11:15, Ecaterina Valica <[email protected]> wrote:
On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea < [email protected]> wrote:
Hi Caleb,
Caleb James DeLisle wrote:
Another matter is what should it be named, I have been calling it "friendInviter" which is an awkward name but invitation manager is a name which will lead to confusion since it does not use the invitation manager plugin. xwiki-invitation sounds good to me too, as Vincent suggested.
Vincent Massol wrote: > On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote: > >> I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. >> I need to know how that should be done and should this be a separate top level project on jira? >> Some guidance here would be great. > +1 for a top level app in platform/applications (which means a jira for it too). > As for the process, I'm proposing: > 1) explain what this app would do (maybe you already did?) I described what I hoped to achieve here:
http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
and show a mockup of its UI so that we can agree about it and get help for our community designers There has been one here for a while, I rewrote the code but the UI is the same.
http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
I couldn't find a mockup for displaying the list of invitations (pending/accepted) sent by the user.
Something I hadn't thought of, shouldn't be very hard to implement.
After all people accepted, do we still keep the list of invited people? Is this a token of user's popularity? :P Just like Gmail, you could have a limited number of people you could invite in the wiki and take care of your followers :) we shouldn't do that, but was just an idea. There is nothing that advanced at the moment but it can be discussed.
I think this should appear somewhere on the user profile.
What exactly would it say in the profile. I'm somewhat resistant to the idea because it can't currently be done with modularity.
Also, is it possible to cancel an invitation?
Somehow stop the email en route? Send another one saying "just kidding"? When the user comes to sign up say: "Nobody really likes you we were just kidding." Anyway the join button currently only redirects to the registration page and does nothing special.
In the case where registration is allowed only for invited people, you'll want for sure to cancel an invitation sent to a wrong email address. By cancel I mean just marking somehow the invitation object as "invalid". Sending a "sorry for the noise" mail is nut such a bad idea.
I have two use cases in mind:
* the user sends the invitation to the wrong email address * the user wants to delete invitations that haven't been accepted in a specific amount of time (e.g. the invitee is asked to register before
a
given date)
If this step would be for the administrator, would be nice from the list of accepted users, that we can apply batch operations for giving rights and adding people in certain groups. Again, just an idea. Have to change the nature of the registration process + no UI extensions = no modularity. It could be done though.
How is the invitation application going to work in a wiki where registration is disabled? i.e. you have to be invited to be able to register.
Another use case I didn't think of. Might require API changes if registration is blocked by setting register permission to deny. Also will cause some kind of dependency. I try to resist dependencies lest every page depend on every other page and removal of one causes total destruction of the system. Still this sounds like a compelling use case. Maybe this should be implemented now or road mapped for later? Any thoughts?
Regarding the send invitation form, I think it would be useful to add explanatory text below each label. For instance, it's not clear that the user has to enter an email address in the "Who you are inviting:" field (can I enter multiple email addresses?). Only if you can edit the page (admin) but I see your point. Should the explaination be in line or in a separate help page?
In line is best, IMO.
Thanks, Marius
Also on the same page we should describe what happens with the invitation (the fact than an email is sent to the specified email address) and ask the user to not abuse
this
feature because his right to send invitations can be removed if his invitations are reported as spam.
I don't understand why you have 2 interfaces that do the same thing. Those who have edit get special privileges (send to multiple addresses, configure the application etc.)
Why there is a version if you have edit right for the page? If you don't have edit rights you shouldn't see a form, but just the labels and content of the form elements, or nothing at all. It is targeted toward those who don't have edit on the page. Otherwise why would we try to thwart spam when the user can simply edit the code and remove our measures.
The first problem I see in the usability is, like Marius said, inviting multiple people in the same step. This step is essentially for the productivity and is working different in the view/pretendEdit right mode. It should not be working unless the user has edit.
In the pretendEdit mode you have a textarea for entering lists of emails with separators. The view mode has validation for the email field. Do you plan to validate the multiple mails too? There is server side validation, LiveValidation would need a separate regular expression for multiple email addresses, it's an easy change to make but will lead to plenty of trouble if the admins waht to change the email validation regular expression. barring that I would have to change LiveValidation which is a third party library.
Also users are not very good at following directions like "*with a comma and a space*". Yes, that's something I have changed (now it's just a space since it seems more intuitive)
A solution for this would be just like the way we add Tags. Provide an overlay for entering emails one by one. This way you can validate them in the overlay and also take care of the separators. The emails could be deleted using the corner X. I imagined the main use case was for admins (those with edit) copy-pasting lists of addresses into the page keep in mind, non admins are unable to use this feature and I'd like to put most of the time into features which will be used often. Maybe we could wait and implement this type of thing later on if there is desire. How important do you think it is to have this now?
The problem with this solution is if the user is experimented and he has a standard list of emails he wants to paste, without entering one by one. We should satisfy both use cases.
Thank you for the responses, it's always hard for me writing the code to see all of the use cases.
Caleb
Caty
Hope this helps, Marius
> 2) send a vote mail to include the invitation manager in XE by default (if not already done) I'd like to have something concrete in the sandbox to vote on.
> 3) code it, you could start in the sandbox indeed or directly in platform/applications if 1) and 2) have been agreed on. I will commit to the sandbox later today. > Thanks > -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Also I want to know if we are gonna integrate some CSS in the email content or is gonna be just simple text? Reference: Guide to CSS support in email clients http://www.campaignmonitor.com/css/ Caty On Wed, Apr 21, 2010 at 16:12, Ecaterina Valica <[email protected]> wrote:
"*evalica has invited you to join incubator.myxwiki.org*" this should be replaced with First Name and Last Name, instead of account name. These messages tend to be personal and the receiver should recognize the person without knowing it's nickname.
In my vision this is a feature that could be used by everyone and not just admins.
Caty
On Wed, Apr 21, 2010 at 15:17, Marius Dumitru Florea < [email protected]> wrote:
See below,
Caleb James DeLisle wrote:
Ecaterina Valica wrote:
Also, when you hit the Preview, you actually see that Subject and
Message
fields have standard content. This content should be displayed from the start and the user should have control over it. I was thinking the mail should give some explanation of why the email was sent, suppose the user clears the default content and sets "buy cheap pharmaceuticals....." as the entire content. The mail recipient will have no way of knowing how the mail got to them or reporting it as spam. Anyway the default template is adjustable in the admin app so it's just a matter of what it is by default.
Most of the users will leave the standard configurations alone.
On Wed, Apr 21, 2010 at 11:15, Ecaterina Valica <[email protected]> wrote:
On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea < [email protected]> wrote:
Hi Caleb,
Caleb James DeLisle wrote: > Another matter is what should it be named, I have been calling it "friendInviter" which is an awkward name > but invitation manager is a name which will lead to confusion since it does not use the invitation manager > plugin. xwiki-invitation sounds good to me too, as Vincent suggested.
> Vincent Massol wrote: >> On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote: >> >>> I have a working prototype of the invitation mail sender and I would like to put it in the sandbox. >>> I need to know how that should be done and should this be a separate top level project on jira? >>> Some guidance here would be great. >> +1 for a top level app in platform/applications (which means a jira for it too). >> As for the process, I'm proposing: >> 1) explain what this app would do (maybe you already did?) > I described what I hoped to achieve here: >
http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
> and show a mockup of its UI so that we can agree about it and get help for our community designers > There has been one here for a while, I rewrote the code but the UI is the same.
http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
I couldn't find a mockup for displaying the list of invitations (pending/accepted) sent by the user.
Something I hadn't thought of, shouldn't be very hard to implement.
After all people accepted, do we still keep the list of invited people? Is this a token of user's popularity? :P Just like Gmail, you could have a limited number of people you could invite in the wiki and take care of your followers :) we shouldn't do that, but was just an idea. There is nothing that advanced at the moment but it can be discussed.
I think this should appear somewhere on the user profile.
What exactly would it say in the profile. I'm somewhat resistant to the idea because it can't currently be done with modularity.
Also, is it possible to cancel an invitation?
Somehow stop the email en route? Send another one saying "just kidding"? When the user comes to sign up say: "Nobody really likes you we were just kidding." Anyway the join button currently only redirects to the registration page and does nothing special.
In the case where registration is allowed only for invited people, you'll want for sure to cancel an invitation sent to a wrong email address. By cancel I mean just marking somehow the invitation object as "invalid". Sending a "sorry for the noise" mail is nut such a bad idea.
I have two use cases in mind:
* the user sends the invitation to the wrong email address * the user wants to delete invitations that haven't been accepted in
a
specific amount of time (e.g. the invitee is asked to register before a given date)
If this step would be for the administrator, would be nice from the list of accepted users, that we can apply batch operations for giving rights and adding people in certain groups. Again, just an idea. Have to change the nature of the registration process + no UI extensions = no modularity. It could be done though.
How is the invitation application going to work in a wiki where registration is disabled? i.e. you have to be invited to be able to register.
Another use case I didn't think of. Might require API changes if registration is blocked by setting register permission to deny. Also will cause some kind of dependency. I try to resist dependencies lest every page depend on every other page and removal of one causes total destruction of the system. Still this sounds like a compelling use case. Maybe this should be implemented now or road mapped for later? Any thoughts?
Regarding the send invitation form, I think it would be useful to add explanatory text below each label. For instance, it's not clear that the user has to enter an email address in the "Who you are inviting:" field (can I enter multiple email addresses?). Only if you can edit the page (admin) but I see your point. Should the explaination be in line or in a separate help page?
In line is best, IMO.
Thanks, Marius
Also on the same page we should describe what happens with the invitation (the fact than an email is sent to the specified email address) and ask the user to not abuse
this
feature because his right to send invitations can be removed if his invitations are reported as spam.
I don't understand why you have 2 interfaces that do the same thing. Those who have edit get special privileges (send to multiple addresses, configure the application etc.)
Why there is a version if you have edit right for the page? If you don't have edit rights you shouldn't see a form, but just the labels and content of the form elements, or nothing at all. It is targeted toward those who don't have edit on the page. Otherwise why would we try to thwart spam when the user can simply edit the code and remove our measures.
The first problem I see in the usability is, like Marius said, inviting multiple people in the same step. This step is essentially for the productivity and is working different in the view/pretendEdit right mode. It should not be working unless the user has edit.
In the pretendEdit mode you have a textarea for entering lists of emails with separators. The view mode has validation for the email field. Do you plan to validate the multiple mails too? There is server side validation, LiveValidation would need a separate regular expression for multiple email addresses, it's an easy change to make but will lead to plenty of trouble if the admins waht to change the email validation regular expression. barring that I would have to change LiveValidation which is a third party library.
Also users are not very good at following directions like "*with a comma and a space*". Yes, that's something I have changed (now it's just a space since it seems more intuitive)
A solution for this would be just like the way we add Tags. Provide an overlay for entering emails one by one. This way you can validate them in the overlay and also take care of the separators. The emails could be deleted using the corner X. I imagined the main use case was for admins (those with edit) copy-pasting lists of addresses into the page keep in mind, non admins are unable to use this feature and I'd like to put most of the time into features which will be used often. Maybe we could wait and implement this type of thing later on if there is desire. How important do you think it is to have this now?
The problem with this solution is if the user is experimented and he has a standard list of emails he wants to paste, without entering one by one. We should satisfy both use cases.
Thank you for the responses, it's always hard for me writing the code to see all of the use cases.
Caleb
Caty
Hope this helps, Marius
>> 2) send a vote mail to include the invitation manager in XE by default (if not already done) > I'd like to have something concrete in the sandbox to vote on. > >> 3) code it, you could start in the sandbox indeed or directly in platform/applications if 1) and 2) have been agreed on. > I will commit to the sandbox later today. >> Thanks >> -Vincent >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Yes. This all sounds great and easy to do using the template (I think) Haven't investigated the CSS end but I imagine <style>blah</style> is what they're talking about which can easily be integrated in the template. Caleb Ecaterina Valica wrote:
Also I want to know if we are gonna integrate some CSS in the email content or is gonna be just simple text?
Reference: Guide to CSS support in email clients http://www.campaignmonitor.com/css/
Caty
On Wed, Apr 21, 2010 at 16:12, Ecaterina Valica <[email protected]> wrote:
"*evalica has invited you to join incubator.myxwiki.org*" this should be replaced with First Name and Last Name, instead of account name. These messages tend to be personal and the receiver should recognize the person without knowing it's nickname.
In my vision this is a feature that could be used by everyone and not just admins.
Caty
On Wed, Apr 21, 2010 at 15:17, Marius Dumitru Florea < [email protected]> wrote:
See below,
Caleb James DeLisle wrote:
Ecaterina Valica wrote:
Also, when you hit the Preview, you actually see that Subject and Message fields have standard content. This content should be displayed from the start and the user should have control over it. I was thinking the mail should give some explanation of why the email was sent, suppose the user clears the default content and sets "buy cheap pharmaceuticals....." as the entire content. The mail recipient will have no way of knowing how the mail got to them or reporting it as spam. Anyway the default template is adjustable in the admin app so it's just a matter of what it is by default.
Most of the users will leave the standard configurations alone.
On Wed, Apr 21, 2010 at 11:15, Ecaterina Valica <[email protected]> wrote:
On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea < [email protected]> wrote:
> Hi Caleb, > > Caleb James DeLisle wrote: >> Another matter is what should it be named, I have been calling it > "friendInviter" which is an awkward name >> but invitation manager is a name which will lead to confusion since it > does not use the invitation manager >> plugin. > xwiki-invitation sounds good to me too, as Vincent suggested. > >> Vincent Massol wrote: >>> On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote: >>> >>>> I have a working prototype of the invitation mail sender and I would > like to put it in the sandbox. >>>> I need to know how that should be done and should this be a separate > top level project on jira? >>>> Some guidance here would be great. >>> +1 for a top level app in platform/applications (which means a jira for > it too). >>> As for the process, I'm proposing: >>> 1) explain what this app would do (maybe you already did?) >> I described what I hoped to achieve here: >> http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s... >> and show a mockup of its UI so that we can agree about it and get help > for our community designers >> There has been one here for a while, I rewrote the code but the UI is > the same. > http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter > I couldn't find a mockup for displaying the list of invitations > (pending/accepted) sent by the user. Something I hadn't thought of, shouldn't be very hard to implement.
After all people accepted, do we still keep the list of invited people? Is this a token of user's popularity? :P Just like Gmail, you could have a limited number of people you could invite in the wiki and take care of your followers :) we shouldn't do that, but was just an idea. There is nothing that advanced at the moment but it can be discussed.
> I think this should appear > somewhere on the user profile. What exactly would it say in the profile. I'm somewhat resistant to the idea because it can't currently be done with modularity.
> Also, is it possible to cancel an > invitation? Somehow stop the email en route? Send another one saying "just kidding"? When the user comes to sign up say: "Nobody really likes you we were just kidding." Anyway the join button currently only redirects to the registration page and does nothing special. In the case where registration is allowed only for invited people, you'll want for sure to cancel an invitation sent to a wrong email address. By cancel I mean just marking somehow the invitation object as "invalid". Sending a "sorry for the noise" mail is nut such a bad idea.
> I have two use cases in mind: > > * the user sends the invitation to the wrong email address > * the user wants to delete invitations that haven't been accepted in a > specific amount of time (e.g. the invitee is asked to register before a > given date) > If this step would be for the administrator, would be nice from the list of accepted users, that we can apply batch operations for giving rights and adding people in certain groups. Again, just an idea. Have to change the nature of the registration process + no UI extensions = no modularity. It could be done though.
> How is the invitation application going to work in a wiki where > registration is disabled? i.e. you have to be invited to be able to > register. Another use case I didn't think of. Might require API changes if registration is blocked by setting register permission to deny. Also will cause some kind of dependency. I try to resist dependencies lest every page depend on every other page and removal of one causes total destruction of the system. Still this sounds like a compelling use case. Maybe this should be implemented now or road mapped for later? Any thoughts?
> Regarding the send invitation form, I think it would be useful to add > explanatory text below each label. For instance, it's not clear that the > user has to enter an email address in the "Who you are inviting:" field > (can I enter multiple email addresses?). Only if you can edit the page (admin) but I see your point. Should the explaination be in line or in a separate help page? In line is best, IMO.
Thanks, Marius
> Also on the same page we should > describe what happens with the invitation (the fact than an email is > sent to the specified email address) and ask the user to not abuse this > feature because his right to send invitations can be removed if his > invitations are reported as spam. > I don't understand why you have 2 interfaces that do the same thing. Those who have edit get special privileges (send to multiple addresses, configure the application etc.)
Why there is a version if you have edit right for the page? If you don't have edit rights you shouldn't see a form, but just the labels and content of the form elements, or nothing at all. It is targeted toward those who don't have edit on the page. Otherwise why would we try to thwart spam when the user can simply edit the code and remove our measures. The first problem I see in the usability is, like Marius said, inviting multiple people in the same step. This step is essentially for the productivity and is working different in the view/pretendEdit right mode. It should not be working unless the user has edit.
In the pretendEdit mode you have a textarea for entering lists of emails with separators. The view mode has validation for the email field. Do you plan to validate the multiple mails too? There is server side validation, LiveValidation would need a separate regular expression for multiple email addresses, it's an easy change to make but will lead to plenty of trouble if the admins waht to change the email validation regular expression. barring that I would have to change LiveValidation which is a third party library.
Also users are not very good at following directions like "*with a comma and a space*". Yes, that's something I have changed (now it's just a space since it seems more intuitive) A solution for this would be just like the way we add Tags. Provide an overlay for entering emails one by one. This way you can validate them in the overlay and also take care of the separators. The emails could be deleted using the corner X. I imagined the main use case was for admins (those with edit) copy-pasting lists of addresses into the page keep in mind, non admins are unable to use this feature and I'd like to put most of the time into features which will be used often. Maybe we could wait and implement this type of thing later on if there is desire. How important do you think it is to have this now? The problem with this solution is if the user is experimented and he has a standard list of emails he wants to paste, without entering one by one. We should satisfy both use cases. Thank you for the responses, it's always hard for me writing the code to see all of the use cases. Caleb
Caty
> Hope this helps, > Marius > >>> 2) send a vote mail to include the invitation manager in XE by default > (if not already done) >> I'd like to have something concrete in the sandbox to vote on. >> >>> 3) code it, you could start in the sandbox indeed or directly in > platform/applications if 1) and 2) have been agreed on. >> I will commit to the sandbox later today. >>> Thanks >>> -Vincent >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Proposal at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/InvitationProposal Thanks, Caty On Wed, Apr 21, 2010 at 16:49, Caleb James DeLisle <[email protected]
wrote:
Yes. This all sounds great and easy to do using the template (I think) Haven't investigated the CSS end but I imagine <style>blah</style> is what they're talking about which can easily be integrated in the template.
Caleb
Ecaterina Valica wrote:
Also I want to know if we are gonna integrate some CSS in the email content or is gonna be just simple text?
Reference: Guide to CSS support in email clients http://www.campaignmonitor.com/css/
Caty
On Wed, Apr 21, 2010 at 16:12, Ecaterina Valica <[email protected]> wrote:
"*evalica has invited you to join incubator.myxwiki.org*" this should be replaced with First Name and Last Name, instead of account name. These messages tend to be personal and the receiver should recognize the person without knowing it's nickname.
In my vision this is a feature that could be used by everyone and not just admins.
Caty
On Wed, Apr 21, 2010 at 15:17, Marius Dumitru Florea < [email protected]> wrote:
See below,
Caleb James DeLisle wrote:
Ecaterina Valica wrote:
Also, when you hit the Preview, you actually see that Subject and Message fields have standard content. This content should be displayed from the start and the user should have control over it. I was thinking the mail should give some explanation of why the email was sent, suppose the user clears the default content and sets "buy cheap pharmaceuticals....." as the entire content. The mail recipient will have no way of knowing how the mail got to them or reporting it as spam. Anyway the default template is adjustable in the admin app so it's just a matter of what it is by default.
Most of the users will leave the standard configurations alone.
On Wed, Apr 21, 2010 at 11:15, Ecaterina Valica <[email protected]> wrote: > On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea < > [email protected]> wrote: > >> Hi Caleb, >> >> Caleb James DeLisle wrote: >>> Another matter is what should it be named, I have been calling it >> "friendInviter" which is an awkward name >>> but invitation manager is a name which will lead to confusion since it >> does not use the invitation manager >>> plugin. >> xwiki-invitation sounds good to me too, as Vincent suggested. >> >>> Vincent Massol wrote: >>>> On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote: >>>> >>>>> I have a working prototype of the invitation mail sender and I would >> like to put it in the sandbox. >>>>> I need to know how that should be done and should this be a separate >> top level project on jira? >>>>> Some guidance here would be great. >>>> +1 for a top level app in platform/applications (which means a jira for >> it too). >>>> As for the process, I'm proposing: >>>> 1) explain what this app would do (maybe you already did?) >>> I described what I hoped to achieve here: >>>
http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
>>> and show a mockup of its UI so that we can agree about it and get help >> for our community designers >>> There has been one here for a while, I rewrote the code but the UI is >> the same. >>
http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
>> I couldn't find a mockup for displaying the list of invitations >> (pending/accepted) sent by the user. Something I hadn't thought of, shouldn't be very hard to implement.
> After all people accepted, do we still keep the list of invited people? Is > this a token of user's popularity? :P Just like Gmail, you could have a > limited number of people you could invite in the wiki and take care of your > followers :) we shouldn't do that, but was just an idea. There is nothing that advanced at the moment but it can be discussed.
>> I think this should appear >> somewhere on the user profile. What exactly would it say in the profile. I'm somewhat resistant to the idea because it can't currently be done with modularity.
>> Also, is it possible to cancel an >> invitation? Somehow stop the email en route? Send another one saying "just kidding"? When the user comes to sign up say: "Nobody really likes you we were just kidding." Anyway the join button currently only redirects to the registration page and does nothing special. In the case where registration is allowed only for invited people, you'll want for sure to cancel an invitation sent to a wrong email address. By cancel I mean just marking somehow the invitation object as "invalid". Sending a "sorry for the noise" mail is nut such a bad idea.
>> I have two use cases in mind: >> >> * the user sends the invitation to the wrong email address >> * the user wants to delete invitations that haven't been accepted in a >> specific amount of time (e.g. the invitee is asked to register before a >> given date) >> > If this step would be for the administrator, would be nice from the list of > accepted users, that we can apply batch operations for giving rights and > adding people in certain groups. Again, just an idea. Have to change the nature of the registration process + no UI extensions = no modularity. It could be done though.
>> How is the invitation application going to work in a wiki where >> registration is disabled? i.e. you have to be invited to be able to >> register. Another use case I didn't think of. Might require API changes if registration is blocked by setting register permission to deny. Also will cause some kind of dependency. I try to resist dependencies lest every page depend on every other page and removal of one causes total destruction of the system. Still this sounds like a compelling use case. Maybe this should be implemented now or road mapped for later? Any thoughts?
>> Regarding the send invitation form, I think it would be useful to add >> explanatory text below each label. For instance, it's not clear that the >> user has to enter an email address in the "Who you are inviting:" field >> (can I enter multiple email addresses?). Only if you can edit the page (admin) but I see your point. Should the explaination be in line or in a separate help page? In line is best, IMO.
Thanks, Marius
>> Also on the same page we should >> describe what happens with the invitation (the fact than an email is >> sent to the specified email address) and ask the user to not abuse this >> feature because his right to send invitations can be removed if his >> invitations are reported as spam. >> > I don't understand why you have 2 interfaces that do the same thing. Those who have edit get special privileges (send to multiple addresses, configure the application etc.)
> Why > there is a version if you have edit right for the page? If you don't have > edit rights you shouldn't see a form, but just the labels and content of the > form elements, or nothing at all. It is targeted toward those who don't have edit on the page. Otherwise why would we try to thwart spam when the user can simply edit the code and remove our measures. > The first problem I see in the usability is, like Marius said, inviting > multiple people in the same step. This step is essentially for the > productivity and is working different in the view/pretendEdit right mode. It should not be working unless the user has edit.
> In the pretendEdit mode you have a textarea for entering lists of emails > with separators. The view mode has validation for the email field. Do you > plan to validate the multiple mails too? There is server side validation, LiveValidation would need a separate regular expression for multiple email addresses, it's an easy change to make but will lead to plenty of trouble if the admins waht to change the email validation regular expression. barring that I would have to change LiveValidation which is a third party library.
> Also users are not very good at > following directions like "*with a comma and a space*". Yes, that's something I have changed (now it's just a space since it seems more intuitive) > A solution for this would be just like the way we add Tags. Provide an > overlay for entering emails one by one. This way you can validate them in > the overlay and also take care of the separators. The emails could be > deleted using the corner X. I imagined the main use case was for admins (those with edit) copy-pasting lists of addresses into the page keep in mind, non admins are unable to use this feature and I'd like to put most of the time into features which will be used often. Maybe we could wait and implement this type of thing later on if there is desire. How important do you think it is to have this now? > The problem with this solution is if the user is experimented and he has a > standard list of emails he wants to paste, without entering one by one. We > should satisfy both use cases. Thank you for the responses, it's always hard for me writing the code to see all of the use cases. Caleb
> Caty > > >> Hope this helps, >> Marius >> >>>> 2) send a vote mail to include the invitation manager in XE by default >> (if not already done) >>> I'd like to have something concrete in the sandbox to vote on. >>> >>>> 3) code it, you could start in the sandbox indeed or directly in >> platform/applications if 1) and 2) have been agreed on. >>> I will commit to the sandbox later today. >>>> Thanks >>>> -Vincent >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, A few comments in the invitation manager discussion. First, caty's proposal looks very nice and well integrated with the XWiki UI. It seems it's indeed missing the "send to mailing list" feature which exists in the current invitation manager. This is a very cool feature which is needed. It basically means that the invitation is not deleted after being used once. There are a few other features that are available in the current invitation manager which I believe are also important. I'm not sure if they are or not supported with Caleb's work: 1/ Support of joining a specific space after the invitation: This meant a lot in XWiki Workspace, but can also mean something in XWiki. It basically means getting the rights to a space or automatically joining a group after accepting the invitation. I think the best way is to implement it as joining a group. 2/ Support for invitation to non registered users as well as registered users: In the case of 1/, we invite by email, without know if the user is member or not. If he is already then he can just use the invitation code to join the group. 3/ Support for join requests: A user wants to join a wiki or a space/group. He can ask for it and the admin can accept/refuse him. This is part of the current invitation manager. 4/ Internationalization We need to make sure the invitation email templates can be internationalized 5/ Compatibility with the current invitation manager storage: We need to be as compatible as possible with how the current invitation manager stores it's configuration and state (current invitation and requests). I'm not sure how things have been currently coded in Caleb's work. I understand the current invitation manager is a plugin and a component would be better, but I hope we are not fully reinventing the wheel here. The invitation manager has been coded in Curriki (and not in XWiki Workspace as Vincent previously said) and it has received a lot of feedback and requirements from the Curriki Project Team. It's a well thought module from the UI perspective. You can go see it in action on http://www.curriki.org Ludovic Le 22/04/10 17:31, Ecaterina Valica a écrit :
Proposal at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/InvitationProposal
Thanks, Caty
On Wed, Apr 21, 2010 at 16:49, Caleb James DeLisle<[email protected]
wrote:
Yes. This all sounds great and easy to do using the template (I think) Haven't investigated the CSS end but I imagine<style>blah</style> is what they're talking about which can easily be integrated in the template.
Caleb
Ecaterina Valica wrote:
Also I want to know if we are gonna integrate some CSS in the email
content
or is gonna be just simple text?
Reference: Guide to CSS support in email clients http://www.campaignmonitor.com/css/
Caty
On Wed, Apr 21, 2010 at 16:12, Ecaterina Valica<[email protected]>
wrote:
"*evalica has invited you to join incubator.myxwiki.org*" this should
be
replaced with First Name and Last Name, instead of account name. These messages tend to be personal and the receiver should recognize the
person
without knowing it's nickname.
In my vision this is a feature that could be used by everyone and not
just
admins.
Caty
On Wed, Apr 21, 2010 at 15:17, Marius Dumitru Florea< [email protected]> wrote:
See below,
Caleb James DeLisle wrote:
Ecaterina Valica wrote:
> Also, when you hit the Preview, you actually see that Subject and > Message
> fields have standard content. This content should be displayed from > the
> start and the user should have control over it. > I was thinking the mail should give some explanation of why the email
was sent, suppose the
user clears the default content and sets "buy cheap
pharmaceuticals....." as the entire content.
The mail recipient will have no way of knowing how the mail got to
them
or reporting it as spam.
Anyway the default template is adjustable in the admin app so it's
just
a matter of what it is by
default.
> Most of the users will leave > the standard configurations alone. > > On Wed, Apr 21, 2010 at 11:15, Ecaterina Valica<[email protected]> > wrote:
>> On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea< >> [email protected]> wrote: >> >> >>> Hi Caleb, >>> >>> Caleb James DeLisle wrote: >>> >>>> Another matter is what should it be named, I have been calling it >>>> >>> "friendInviter" which is an awkward name >>> >>>> but invitation manager is a name which will lead to confusion >>>> since
it
>>> does not use the invitation manager >>> >>>> plugin. >>>> >>> xwiki-invitation sounds good to me too, as Vincent suggested. >>> >>> >>>> Vincent Massol wrote: >>>> >>>>> On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote: >>>>> >>>>> >>>>>> I have a working prototype of the invitation mail sender and I >>>>>> would
>>> like to put it in the sandbox. >>> >>>>>> I need to know how that should be done and should this be a >>>>>> separate
>>> top level project on jira? >>> >>>>>> Some guidance here would be great. >>>>>> >>>>> +1 for a top level app in platform/applications (which means a >>>>> jira
for
>>> it too). >>> >>>>> As for the process, I'm proposing: >>>>> 1) explain what this app would do (maybe you already did?) >>>>> >>>> I described what I hoped to achieve here: >>>> >>>>
http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
>>>> and show a mockup of its UI so that we can agree about it and get >>>> help
>>> for our community designers >>> >>>> There has been one here for a while, I rewrote the code but the UI >>>> is
>>> the same. >>> >>>
http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
>>> I couldn't find a mockup for displaying the list of invitations >>> (pending/accepted) sent by the user. >>> Something I hadn't thought of, shouldn't be very hard to implement.
>> After all people accepted, do we still keep the list of invited >> people? Is
>> this a token of user's popularity? :P Just like Gmail, you could >> have
a
>> limited number of people you could invite in the wiki and take care >> of
your
>> followers :) we shouldn't do that, but was just an idea. >> There is nothing that advanced at the moment but it can be discussed.
>>> I think this should appear >>> somewhere on the user profile. >>> What exactly would it say in the profile. I'm somewhat resistant to
the
idea because it can't currently
be done with modularity.
>>> Also, is it possible to cancel an >>> invitation? >>> Somehow stop the email en route? Send another one saying "just
kidding"?
When the user comes to sign up say: "Nobody really likes you we were
just kidding."
Anyway the join button currently only redirects to the registration
page
and does
nothing special.
In the case where registration is allowed only for invited people, you'll want for sure to cancel an invitation sent to a wrong email address. By cancel I mean just marking somehow the invitation object as "invalid". Sending a "sorry for the noise" mail is nut such a bad idea.
>>> I have two use cases in mind: >>> >>> * the user sends the invitation to the wrong email address >>> * the user wants to delete invitations that haven't been accepted >>> in
a
>>> specific amount of time (e.g. the invitee is asked to register >>> before
a
>>> given date) >>> >>> >> If this step would be for the administrator, would be nice from the >> list of
>> accepted users, that we can apply batch operations for giving rights >> and
>> adding people in certain groups. Again, just an idea. >> Have to change the nature of the registration process + no UI
extensions
= no modularity.
It could be done though.
>>> How is the invitation application going to work in a wiki where >>> registration is disabled? i.e. you have to be invited to be able to >>> register. >>> Another use case I didn't think of. Might require API changes if
registration is blocked
by setting register permission to deny. Also will cause some kind of
dependency. I try
to resist dependencies lest every page depend on every other page and
removal of one causes
total destruction of the system. Still this sounds like a compelling
use
case. Maybe this
should be implemented now or road mapped for later? Any thoughts?
>>> Regarding the send invitation form, I think it would be useful to >>> add
>>> explanatory text below each label. For instance, it's not clear >>> that
the
>>> user has to enter an email address in the "Who you are inviting:" >>> field
>>> (can I enter multiple email addresses?). >>> Only if you can edit the page (admin) but I see your point. Should the
explaination be in line
or in a separate help page?
In line is best, IMO.
Thanks, Marius
>>> Also on the same page we should >>> describe what happens with the invitation (the fact than an email >>> is
>>> sent to the specified email address) and ask the user to not abuse >>> this
>>> feature because his right to send invitations can be removed if his >>> invitations are reported as spam. >>> >>> >> I don't understand why you have 2 interfaces that do the same >> thing.
Those who have edit get special privileges (send to multiple
addresses,
configure the
application etc.)
>> Why >> there is a version if you have edit right for the page? If you don't >> have
>> edit rights you shouldn't see a form, but just the labels and >> content
of the
>> form elements, or nothing at all. >> It is targeted toward those who don't have edit on the page. Otherwise
why would we
try to thwart spam when the user can simply edit the code and remove
our
measures.
>> The first problem I see in the usability is, like Marius said, >> inviting
>> multiple people in the same step. This step is essentially for the >> productivity and is working different in the view/pretendEdit right >> mode.
It should not be working unless the user has edit.
>> In the pretendEdit mode you have a textarea for entering lists of >> emails
>> with separators. The view mode has validation for the email field. >> Do
you
>> plan to validate the multiple mails too? >> There is server side validation, LiveValidation would need a separate
regular expression
for multiple email addresses, it's an easy change to make but will
lead
to plenty of trouble
if the admins waht to change the email validation regular expression.
barring that I would have
to change LiveValidation which is a third party library.
>> Also users are not very good at >> following directions like "*with a comma and a space*". >> Yes, that's something I have changed (now it's just a space since it
seems more intuitive)
>> A solution for this would be just like the way we add Tags. Provide >> an
>> overlay for entering emails one by one. This way you can validate >> them
in
>> the overlay and also take care of the separators. The emails could >> be
>> deleted using the corner X. >> I imagined the main use case was for admins (those with edit)
copy-pasting lists of addresses
into the page keep in mind, non admins are unable to use this feature
and I'd like to put most
of the time into features which will be used often. Maybe we could
wait
and implement this type
of thing later on if there is desire. How important do you think it is
to have this now?
>> The problem with this solution is if the user is experimented and he >> has a
>> standard list of emails he wants to paste, without entering one by >> one. We
>> should satisfy both use cases. >> Thank you for the responses, it's always hard for me writing the code
to
see all of the use cases.
Caleb
>> Caty >> >> >> >>> Hope this helps, >>> Marius >>> >>> >>>>> 2) send a vote mail to include the invitation manager in XE by >>>>> default
>>> (if not already done) >>> >>>> I'd like to have something concrete in the sandbox to vote on. >>>> >>>> >>>>> 3) code it, you could start in the sandbox indeed or directly in >>>>> >>> platform/applications if 1) and 2) have been agreed on. >>> >>>> I will commit to the sandbox later today. >>>> >>>>> Thanks >>>>> -Vincent >>>>> _______________________________________________ >>>>> devs mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>>> >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >>> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Ludovic Dubost wrote:
Hi,
A few comments in the invitation manager discussion.
First, caty's proposal looks very nice and well integrated with the XWiki UI.
It seems it's indeed missing the "send to mailing list" feature which exists in the current invitation manager. This is a very cool feature which is needed. It basically means that the invitation is not deleted after being used once.
This is easy enough to implement.
There are a few other features that are available in the current invitation manager which I believe are also important. I'm not sure if they are or not supported with Caleb's work:
1/ Support of joining a specific space after the invitation:
This meant a lot in XWiki Workspace, but can also mean something in XWiki. It basically means getting the rights to a space or automatically joining a group after accepting the invitation. I think the best way is to implement it as joining a group.
I have been planning a second document to handle the registration of the user. Separated because it might need to have PR if registration is closed on the wiki and thus should be as short as possible to minimize security risk.
2/ Support for invitation to non registered users as well as registered users:
In the case of 1/, we invite by email, without know if the user is member or not. If he is already then he can just use the invitation code to join the group.
Invitation of registered users to join a group is a use case I had not foreseen I don't think it would be hard if the invitation is still sent by mail.
3/ Support for join requests:
A user wants to join a wiki or a space/group. He can ask for it and the admin can accept/refuse him. This is part of the current invitation manager.
This looks tricky because groups don't really have administrators so it's hard to know who should handle the invitation request. It could be set up so that anyone with write access on the group object is shown requests. Maybe this could be implemented later after the primary code is running.
4/ Internationalization
We need to make sure the invitation email templates can be internationalized
The templates were made configurable with the idea that admins would change them it is not too difficult to make a translation key for the templates but it will make them less readable when modifying them.
5/ Compatibility with the current invitation manager storage:
We need to be as compatible as possible with how the current invitation manager stores it's configuration and state (current invitation and requests).
I haven't taken this approach so far and changing now will take some work and there will be some parameters which are not used. I'm not sure what the use case is, is it so that users of the invitation manager can upgrade seamlessly? I had not foreseen that use case.
I'm not sure how things have been currently coded in Caleb's work. The invitation manager (plugin) is closely connected to the space manager plugin neither of which are currently included in Enterprise by default. Since the concept of space membership seems no longer used, I opted to write invitation over and have been working on it as a velocity application because all of the functionality is within the script API and applications can run without PR making them much less of a security risk, also because invitation seems to me as something which belongs on the application side with blog and administration rather than in the core with rendering and cache.
I understand the current invitation manager is a plugin and a component would be better, but I hope we are not fully reinventing the wheel here. Unfortunately I think reinventing the wheel is needed because as a plugin the invitation manager is dependent on the core which is not allowed for components, also since I have been writing it as an application it has to be rewritten anyway.
The invitation manager has been coded in Curriki (and not in XWiki Workspace as Vincent previously said) and it has received a lot of feedback and requirements from the Curriki Project Team. It's a well thought module from the UI perspective. You can go see it in action on http://www.curriki.org
I approached this project with the philosophy that it should only include basic functionality which will be used on a large percentage of installations. My thinking was that users who needed the most functionality or current users of the invitation manager plugin would be the big installations (like curriki) who have the time to integrate the invitation manager plugin into new versions or even to write their own custom code. I propose going ahead with a simple piece for inviting non members to a wiki. Then adding /1 and /2 which shouldn't be difficult then we can look into adding /3 with input from the community who will by now have had some time to test the invitation application. /4 is relatively easy using $msg.get and can be implemented early. I'm not sure what the end goal is for /5 so I will need some more information but my immediate thought is I don't like it because it will mean storage and configuration would fit code which is no longer used and would be less of a fit for the code they are working with. WDYT? Caleb I'm sure once it's out and being used we will hear great ideas for additional functionality which nobody had thought of.
Ludovic
Le 22/04/10 17:31, Ecaterina Valica a écrit :
Proposal at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/InvitationProposal
Thanks, Caty
On Wed, Apr 21, 2010 at 16:49, Caleb James DeLisle<[email protected]
wrote:
Yes. This all sounds great and easy to do using the template (I think) Haven't investigated the CSS end but I imagine<style>blah</style> is what they're talking about which can easily be integrated in the template.
Caleb
Ecaterina Valica wrote:
Also I want to know if we are gonna integrate some CSS in the email
content
or is gonna be just simple text?
Reference: Guide to CSS support in email clients http://www.campaignmonitor.com/css/
Caty
On Wed, Apr 21, 2010 at 16:12, Ecaterina Valica<[email protected]>
wrote:
"*evalica has invited you to join incubator.myxwiki.org*" this should
be
replaced with First Name and Last Name, instead of account name. These messages tend to be personal and the receiver should recognize the
person
without knowing it's nickname.
In my vision this is a feature that could be used by everyone and not
just
admins.
Caty
On Wed, Apr 21, 2010 at 15:17, Marius Dumitru Florea< [email protected]> wrote:
See below,
Caleb James DeLisle wrote:
> Ecaterina Valica wrote: > >> Also, when you hit the Preview, you actually see that Subject and >> Message
>> fields have standard content. This content should be displayed from >> the
>> start and the user should have control over it. >> > I was thinking the mail should give some explanation of why the > email > was sent, suppose the
> user clears the default content and sets "buy cheap > pharmaceuticals....." as the entire content.
> The mail recipient will have no way of knowing how the mail got to > them
or reporting it as spam.
> Anyway the default template is adjustable in the admin app so it's > just
a matter of what it is by
> default. > > >> Most of the users will leave >> the standard configurations alone. >> >> On Wed, Apr 21, 2010 at 11:15, Ecaterina Valica<[email protected]> >> wrote:
>>> On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea< >>> [email protected]> wrote: >>> >>> >>>> Hi Caleb, >>>> >>>> Caleb James DeLisle wrote: >>>> >>>>> Another matter is what should it be named, I have been >>>>> calling it >>>>> >>>> "friendInviter" which is an awkward name >>>> >>>>> but invitation manager is a name which will lead to confusion >>>>> since
it
>>>> does not use the invitation manager >>>> >>>>> plugin. >>>>> >>>> xwiki-invitation sounds good to me too, as Vincent suggested. >>>> >>>> >>>>> Vincent Massol wrote: >>>>> >>>>>> On Apr 20, 2010, at 12:42 PM, Caleb James DeLisle wrote: >>>>>> >>>>>> >>>>>>> I have a working prototype of the invitation mail sender and I >>>>>>> would
>>>> like to put it in the sandbox. >>>> >>>>>>> I need to know how that should be done and should this be a >>>>>>> separate
>>>> top level project on jira? >>>> >>>>>>> Some guidance here would be great. >>>>>>> >>>>>> +1 for a top level app in platform/applications (which means a >>>>>> jira
for
>>>> it too). >>>> >>>>>> As for the process, I'm proposing: >>>>>> 1) explain what this app would do (maybe you already did?) >>>>>> >>>>> I described what I hoped to achieve here: >>>>> >>>>>
http://www.pubbs.net/201001/xwiki/60333-xwiki-devs-proposal-allow-users-to-s...
>>>>> and show a mockup of its UI so that we can agree about it >>>>> and get >>>>> help
>>>> for our community designers >>>> >>>>> There has been one here for a while, I rewrote the code but >>>>> the UI >>>>> is
>>>> the same. >>>> >>>>
http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviter
>>>> I couldn't find a mockup for displaying the list of invitations >>>> (pending/accepted) sent by the user. >>>> > Something I hadn't thought of, shouldn't be very hard to implement. > > >>> After all people accepted, do we still keep the list of invited >>> people? Is
>>> this a token of user's popularity? :P Just like Gmail, you could >>> have
a
>>> limited number of people you could invite in the wiki and take >>> care >>> of
your
>>> followers :) we shouldn't do that, but was just an idea. >>> > There is nothing that advanced at the moment but it can be > discussed. > > >>>> I think this should appear >>>> somewhere on the user profile. >>>> > What exactly would it say in the profile. I'm somewhat resistant to > the
idea because it can't currently
> be done with modularity. > > >>>> Also, is it possible to cancel an >>>> invitation? >>>> > Somehow stop the email en route? Send another one saying "just > kidding"?
> When the user comes to sign up say: "Nobody really likes you we were > just kidding."
> Anyway the join button currently only redirects to the registration > page
and does
> nothing special. > In the case where registration is allowed only for invited people, you'll want for sure to cancel an invitation sent to a wrong email address. By cancel I mean just marking somehow the invitation object as "invalid". Sending a "sorry for the noise" mail is nut such a bad idea.
>>>> I have two use cases in mind: >>>> >>>> * the user sends the invitation to the wrong email address >>>> * the user wants to delete invitations that haven't been accepted >>>> in
a
>>>> specific amount of time (e.g. the invitee is asked to register >>>> before
a
>>>> given date) >>>> >>>> >>> If this step would be for the administrator, would be nice from >>> the >>> list of
>>> accepted users, that we can apply batch operations for giving >>> rights >>> and
>>> adding people in certain groups. Again, just an idea. >>> > Have to change the nature of the registration process + no UI > extensions
= no modularity.
> It could be done though. > > >>>> How is the invitation application going to work in a wiki where >>>> registration is disabled? i.e. you have to be invited to be >>>> able to >>>> register. >>>> > Another use case I didn't think of. Might require API changes if > registration is blocked
> by setting register permission to deny. Also will cause some kind of > dependency. I try
> to resist dependencies lest every page depend on every other page > and > removal of one causes
> total destruction of the system. Still this sounds like a compelling > use
case. Maybe this
> should be implemented now or road mapped for later? Any thoughts? > > >>>> Regarding the send invitation form, I think it would be useful to >>>> add
>>>> explanatory text below each label. For instance, it's not clear >>>> that
the
>>>> user has to enter an email address in the "Who you are inviting:" >>>> field
>>>> (can I enter multiple email addresses?). >>>> > Only if you can edit the page (admin) but I see your point. > Should the > explaination be in line
> or in a separate help page? > In line is best, IMO.
Thanks, Marius
>>>> Also on the same page we should >>>> describe what happens with the invitation (the fact than an email >>>> is
>>>> sent to the specified email address) and ask the user to not >>>> abuse >>>> this
>>>> feature because his right to send invitations can be removed >>>> if his >>>> invitations are reported as spam. >>>> >>>> >>> I don't understand why you have 2 interfaces that do the same >>> thing.
> Those who have edit get special privileges (send to multiple > addresses,
configure the
> application etc.) > > >>> Why >>> there is a version if you have edit right for the page? If you >>> don't >>> have
>>> edit rights you shouldn't see a form, but just the labels and >>> content
of the
>>> form elements, or nothing at all. >>> > It is targeted toward those who don't have edit on the page. > Otherwise > why would we
> try to thwart spam when the user can simply edit the code and remove > our
measures.
>>> The first problem I see in the usability is, like Marius said, >>> inviting
>>> multiple people in the same step. This step is essentially for the >>> productivity and is working different in the view/pretendEdit >>> right >>> mode.
> It should not be working unless the user has edit. > > >>> In the pretendEdit mode you have a textarea for entering lists of >>> emails
>>> with separators. The view mode has validation for the email field. >>> Do
you
>>> plan to validate the multiple mails too? >>> > There is server side validation, LiveValidation would need a > separate > regular expression
> for multiple email addresses, it's an easy change to make but will > lead
to plenty of trouble
> if the admins waht to change the email validation regular > expression. > barring that I would have
> to change LiveValidation which is a third party library. > > >>> Also users are not very good at >>> following directions like "*with a comma and a space*". >>> > Yes, that's something I have changed (now it's just a space since it > seems more intuitive)
>>> A solution for this would be just like the way we add Tags. >>> Provide >>> an
>>> overlay for entering emails one by one. This way you can validate >>> them
in
>>> the overlay and also take care of the separators. The emails could >>> be
>>> deleted using the corner X. >>> > I imagined the main use case was for admins (those with edit) > copy-pasting lists of addresses
> into the page keep in mind, non admins are unable to use this > feature > and I'd like to put most
> of the time into features which will be used often. Maybe we could > wait
and implement this type
> of thing later on if there is desire. How important do you think > it is > to have this now?
>>> The problem with this solution is if the user is experimented >>> and he >>> has a
>>> standard list of emails he wants to paste, without entering one by >>> one. We
>>> should satisfy both use cases. >>> > Thank you for the responses, it's always hard for me writing the > code > to
see all of the use cases.
> Caleb > > > >>> Caty >>> >>> >>> >>>> Hope this helps, >>>> Marius >>>> >>>> >>>>>> 2) send a vote mail to include the invitation manager in XE by >>>>>> default
>>>> (if not already done) >>>> >>>>> I'd like to have something concrete in the sandbox to vote on. >>>>> >>>>> >>>>>> 3) code it, you could start in the sandbox indeed or >>>>>> directly in >>>>>> >>>> platform/applications if 1) and 2) have been agreed on. >>>> >>>>> I will commit to the sandbox later today. >>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> _______________________________________________ >>>>>> devs mailing list >>>>>> [email protected] >>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> devs mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
------------------------------------------------------------------------
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 04/21/2010 11:37 AM, Caleb James DeLisle wrote:
Ecaterina Valica wrote:
Also, when you hit the Preview, you actually see that Subject and Message fields have standard content. This content should be displayed from the start and the user should have control over it. I was thinking the mail should give some explanation of why the email was sent, suppose the user clears the default content and sets "buy cheap pharmaceuticals....." as the entire content. The mail recipient will have no way of knowing how the mail got to them or reporting it as spam. Anyway the default template is adjustable in the admin app so it's just a matter of what it is by default.
-0 on letting users change the Subject.
Also, is it possible to cancel an invitation? Somehow stop the email en route? Send another one saying "just kidding"? When the user comes to sign up say: "Nobody really likes you we were just kidding." Anyway the join button currently only redirects to the registration page and does nothing special.
This makes sense in the "allow registration only for invited people" usecase, and the goal would be to correct wrongly sent invitations. After all, if you want such a tight control over who has the right to become a member, you wouldn't want a user to be allowed to register just because some bozo couldn't type the right email address... This could work by having an invitation ID, and if the invitation ID is wrong or canceled, display a little warning about the fact that the invitation is wrong, and the usual bla-bla: try copy-pasting, request another invitation, or (if the registration is public) just proceed to normal registration.
How is the invitation application going to work in a wiki where registration is disabled? i.e. you have to be invited to be able to register. Another use case I didn't think of. Might require API changes if registration is blocked by setting register permission to deny. Also will cause some kind of dependency. I try to resist dependencies lest every page depend on every other page and removal of one causes total destruction of the system. Still this sounds like a compelling use case. Maybe this should be implemented now or road mapped for later? Any thoughts?
It could be done easily if we refactor the rights system to be more modular. If we do this, then it would be easy to add another check for registration which looks at the invitationID and checks if it is valid. But right now it's almost impossible. -- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (7)
-
Caleb James DeLisle -
Ecaterina Valica -
Guillaume Lerouge -
Ludovic Dubost -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol