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
