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