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 emailcontentor 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 shouldbereplaced with First Name and Last Name, instead of account name. These messages tend to be personal and the receiver should recognize thepersonwithout knowing it's nickname. In my vision this is a feature that could be used by everyone and notjustadmins. 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 andMessagefields have standard content. This content should be displayed fromthestart and the user should have control over it.I was thinking the mail should give some explanation of why the emailwas sent, suppose theuser clears the default content and sets "buy cheappharmaceuticals....." as the entire content.The mail recipient will have no way of knowing how the mail got tothemor reporting it as spam.Anyway the default template is adjustable in the admin app so it'sjusta matter of what it is bydefault.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 namebut invitation manager is a name which will lead to confusionsinceitdoes not use the invitation managerplugin.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 Iwouldlike to put it in the sandbox.I need to know how that should be done and should this be aseparatetop level project on jira?Some guidance here would be great.+1 for a top level app in platform/applications (which means ajiraforit 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.htmland show a mockup of its UI so that we can agree about it and gethelpfor our community designersThere has been one here for a while, I rewrote the code but the UIisthe same.http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/FriendInviterI 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 invitedpeople? Isthis a token of user's popularity? :P Just like Gmail, you couldhavealimited number of people you could invite in the wiki and take careofyourfollowers :) 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 totheidea because it can't currentlybe done with modularity.Also, is it possible to cancel an invitation?Somehow stop the email en route? Send another one saying "justkidding"?When the user comes to sign up say: "Nobody really likes you we werejust kidding."Anyway the join button currently only redirects to the registrationpageand doesnothing 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 acceptedinaspecific amount of time (e.g. the invitee is asked to registerbeforeagiven date)If this step would be for the administrator, would be nice from thelist ofaccepted users, that we can apply batch operations for giving rightsandadding people in certain groups. Again, just an idea.Have to change the nature of the registration process + no UIextensions= 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 ifregistration is blockedby setting register permission to deny. Also will cause some kind ofdependency. I tryto resist dependencies lest every page depend on every other page andremoval of one causestotal destruction of the system. Still this sounds like a compellingusecase. Maybe thisshould be implemented now or road mapped for later? Any thoughts?Regarding the send invitation form, I think it would be useful toaddexplanatory text below each label. For instance, it's not clearthattheuser 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 theexplaination be in lineor in a separate help page?In line is best, IMO. Thanks, MariusAlso on the same page we should describe what happens with the invitation (the fact than an emailissent to the specified email address) and ask the user to not abusethisfeature 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 samething.Those who have edit get special privileges (send to multipleaddresses,configure theapplication etc.)Why there is a version if you have edit right for the page? If you don'thaveedit rights you shouldn't see a form, but just the labels andcontentof theform elements, or nothing at all.It is targeted toward those who don't have edit on the page. Otherwisewhy would wetry to thwart spam when the user can simply edit the code and removeourmeasures.The first problem I see in the usability is, like Marius said,invitingmultiple people in the same step. This step is essentially for the productivity and is working different in the view/pretendEdit rightmode.It should not be working unless the user has edit.In the pretendEdit mode you have a textarea for entering lists ofemailswith separators. The view mode has validation for the email field.Doyouplan to validate the multiple mails too?There is server side validation, LiveValidation would need a separateregular expressionfor multiple email addresses, it's an easy change to make but willleadto plenty of troubleif the admins waht to change the email validation regular expression.barring that I would haveto 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 itseems more intuitive)A solution for this would be just like the way we add Tags. Provideanoverlay for entering emails one by one. This way you can validatetheminthe overlay and also take care of the separators. The emails couldbedeleted using the corner X.I imagined the main use case was for admins (those with edit)copy-pasting lists of addressesinto the page keep in mind, non admins are unable to use this featureand I'd like to put mostof the time into features which will be used often. Maybe we couldwaitand implement this typeof thing later on if there is desire. How important do you think it isto have this now?The problem with this solution is if the user is experimented and hehas astandard list of emails he wants to paste, without entering one byone. Weshould satisfy both use cases.Thank you for the responses, it's always hard for me writing the codetosee all of the use cases.CalebCatyHope this helps, Marius2) send a vote mail to include the invitation manager in XE bydefault(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 inplatform/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
<<attachment: ludovic.vcf>>
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
