Re: [xwiki-devs] Should email invitation app be a top level application? How should I add it to the sandbox?

Proposal at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/InvitationProposal Thanks, Caty On Wed, Apr 21, 2010 at 16:49, Caleb James DeLisle&lt;calebdelisle(a)lavabit.com > 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&lt;valicac(a)gmail.com&gt; >> >> >>> "*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< >>> mariusdumitru.florea(a)xwiki.com&gt; 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&lt;valicac(a)gmail.com&gt; >>>>>> >>>> wrote: >>>> >>>>>>> On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea< >>>>>>> mariusdumitru.florea(a)xwiki.com&gt; 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-… > >>>>>>>>> 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 >>>>>>>>>> devs(a)xwiki.org >>>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> devs mailing list >>>>>>>>> devs(a)xwiki.org >>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> devs mailing list >>>>>>>> devs(a)xwiki.org >>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>> devs mailing list >>>>>> devs(a)xwiki.org >>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> devs mailing list >>>>> devs(a)xwiki.org >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>> _______________________________________________ >>>> devs mailing list >>>> devs(a)xwiki.org >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>>> >>> >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> >> > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs