21 Apr
2010
21 Apr
'10
3:49 p.m.
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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