22 Apr
2010
22 Apr
'10
5:31 p.m.
Proposal at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/InvitationProposal
Thanks,
Caty
On Wed, Apr 21, 2010 at 16:49, Caleb James DeLisle <calebdelisle(a)lavabit.com
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 <valicac(a)gmail.com>
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 <
> >> mariusdumitru.florea(a)xwiki.com
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
<valicac(a)gmail.com>
> >> wrote:
>
>>>>>> On Wed, Apr 21, 2010 at 08:51, Marius Dumitru Florea <
> >>>>>> mariusdumitru.florea(a)xwiki.com
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
>