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