New Join module!By Over on the Wikidot Projects forums, The official documentation for this module can be found here: http://www.wikidot.com/doc:join-module And, while you're at it, why not try out this new module? :) If you are a member of this site, you will first have to log out before you see it.
MembershipByPassword and MembershipApplyThese modules are now deprecated by the Join module. That means that you should go to your wiki or Wikidot website, and delete those modules. Put [[module Join button="Join this site!"]] on the page instead! :) Advanced use - modify the button using CSS!If you would like to add your own custom look to the button, you can define a class for it and instead, it will just be rendered as a normal link (as you can see below this paragraph when you log out of your account). That means that you can custom-style it using CSS to look however you want it to!
Tags: join members membership membershipapply membershipbypassword module Related Community Blog PostsThe following posts have similar tags and may be related to this post. Rate it up ?DiscussShare
|
Community Blog
|
New Join module!
Thanks! This is very nice. Much more elegant than the old way.
Glad you like it.
Designed by Wikidot Users.[tm]
Portfolio
I'll probably learn that when I find some time to learn enough CSS to produce a class for the buttons, but I'm just wondering: is it possible to use an image for a join button?
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
yes
Great! Thanks, Rhombus!
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
@Rhombus, thanks for the tip, I added that to the Join module doc.
Portfolio
Is that again the default? I honestly hope it isn't, but some of my site's new members report receiving lots of messages every time a page is edited. If that's the case, I'll have to make membership closed again.
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
I don't think it was ever changed :( It's just planned to cancel auto-watching.
Shane Smith ★ Website: Wikidot Development & Programming.
STE Wikidot Editor: Windows & Mac OS X. ★ Try it for free!.
I'm also on Twitter, follow me there! ;-)
Jesus H. Christ, I've been unknowingly inviting my colleagues to a spam trap! That's embarassing, and rather annoying. Automatic watching is a bad, BAD idea.
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
They can cancel at any time by opening the site and changing their watching settings on one of the pages, as I'm sure you know.
But yes, I agree with you. Auto-watching for the site creator, perhaps, but not needed for anyone else unless they explicitly ask for it.
Shane Smith ★ Website: Wikidot Development & Programming.
STE Wikidot Editor: Windows & Mac OS X. ★ Try it for free!.
I'm also on Twitter, follow me there! ;-)
I haven't read the TOS lately, as I believe Wikidot is not one of those places where important things are hidden somewhere in small print. So I don't know if anywhere in the sign-up process is mentioned that you'll become automatically a watcher of the site, being notified of every single comma or dot that's typed. So, although I do understand that people can sign off from watcher status, their first impression of my site (and of Wikidot as a whole) will be one of disorganization at best
Imagine yourself innocently clicking the "Join" button and joining a site seamlessly (thanks to our wonderful new join module) and, upon opening your mailbox the next morning, finding a bunch of irrelevant messages. That would be disappointing, irritating, and a good reason to not ever trust the site again. People just don't have time to waste like that.
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
Notifications are not spam, they are essential to any kind of collaborative work. Automatic watching is what works best for most people. We have a design proposal for more refined watching, but until that is built, it's about managing the notifications we have today.
1. Every notification has a link to a page where the recipient can cancel further notifications. This is instant and easy and I use it often to stop watching sites I don't want to.
2. Put a Watchers module on the main page so people can stop/start watching with one click.
3. Add some explanation on the main page above the watcher module if you still think that's needed.
Could you take a second to review http://blog.wikidot.com/design:2 and make sure it gives you what you need? Thanks.
Portfolio
Thanks, Pieter, for your response. I don't know what the "technical" definition of spam is, but I believe that any mass mailing for which you didn't explicitly sign up is junk mail, and thus something to be avoided. And I do understand the importance of notifications for a collaborative work — I just don't think they should be automatic. They should be customizable on a per-group basis. Of course I want admins (maybe moderators too) to be always aware of what's going on in the site, but not every single site member needs (or wants) to be told about every single housekeeping activity. And admins should be able to choose what counts as a notifiable event — fixing a typo, maybe not; a major content edit, certainly.
I'll study the new design carefully when I get some time, but based on what I've seen in past discussions, I'm sure it will work perfectly well for me. Meanwhile, I'll try your suggestions to minimize the undesirable effects of automatic watching.
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
Just another related thought: it would help if we could have a customizable automated message for new members (Pieter already made a design for this, I think)where things such as automatic watching could be explained.
It would also be great to be able to contact all the site members at once, to increase the community "feel" of the site. I think I've heard such requests before, and I do understand implementing them takes time. But I'm just mentioning — and hoping ;)
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
I agree. All it takes is to have a couple people hit that spam button to get blacklisted on a lot of email providers and that's not good for anybody, not just peoples individual wikidot sites, but the whole network.
Thanks, morningbird, for mentioning that risk. I'm afraid one reason why I haven't been getting complaints from all site members is probably that: with some of them, the notification emails may have been filtered as spam.
Following Pieter's suggestions, I created a page explaining the situation with the watchers module. I also removed the "join" button from my front page and added instead a note inviting people to join while referring them to the explanatory page. For those of you with similar concerns, the page is http://www.etnolinguistica.org/membros, so you can have an idea of what I did.
(By the way, morningbird: the domain "Witchipedia.Com" is a brilliant idea!)
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
Thank you Kawina!
I put a little blurb above my "join" button that looks like this:
I realize updates are useful for collaborative sites, but not all the sites produced here are collaborative. If you want to be a truly flexible resource you need to think from different angles. Some people are only going to join because they want to participate in the forums not because they are part of the project itself in which case they might be interested in forum updates but not necessarily page updates.
Some ideas:
Most sites when you join have an option in the sign up form that is checked by default and you have to uncheck if you don't want to get updates.
Digest updates- if all the updates are bundled into a daily or weekly digest instead of sent individually, it will seem more like an update and less like unbelievable amounts of spam.
Updates can be good for the site because they encourage return visitors but you have to strike a balance to avoid getting a reputation as a spammer.
Now that I have been acquainted with the piles of email editing my site content generates for my members, I am more careful about editing, creating & proofreading drafts before posting, fewer "safety" saves halfway through, and my next site I will make sure I have as complete as possible before inviting members.
I too think that automatic watching for site members (as compared to admins and mods) is a bad idea. It should be on an opt-in rather than an opt-out basis for the reasons given above.
One of my sites is about to be made private while development starts seriously (it's the Lord Lieutenant one I've talked about before). But I want the people I am doing it for to be members and see progress when they want to. What I don't what them to know about are the hundreds of minor CSS tests and changes I will make on the css:theme page during the design phase. They don't need to know about that and they certainly don't want hundreds of emails flooding their inbox telling them that I've just changed the login-status to a slightly different shade of pink! (not that the notification would say that but yu know what I mean).
A way round it that I will use until http://blog.wikidot.com/weneed:12 is released is to set up a new account for each of them myself with a spare email account and turn the watching off. I just then need to give them their username and the password. The email account can be changed later. But of course this only works if you know who your members are going to be so it's certainly not a universal solution or even for most people a particularly useful one, but it does for me get round this issue of automatic watching for new members.
Rob
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Strathview ~ Wikidot-based wikis, websites & intranets and online database development. For community groups, villages, charities, business and government.
I reviewed it, and I see little improvement in terms of giving admins more control over their content (but I could have missed something). The design gives users more refined options as to how they want to watch stuff, but does nothing in terms of giving site creators more control over what should be watchable. An ideal solution would be something in the permissions switchboard, where you can chose which group (moderators, members etc.) can do what (edit, delete, watch etc.) to what category.
And I still see no reason why members would become automatic watchers of newly created pages. With a few exceptions, we are all grown-ups here who should be able to decide explicitly and voluntarily whether we want to watch something or not. Watching should be strictly and opt-in thing.
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
The main reason is that for me (this is an opinion, not a decision) a site represents a workgroup and by joining, members are effectively subscribing to the workflow.
I don't see the reason of joining a site except to get notifications of at least new pages. Making it opt-in would create an additional barrier and most members would forget to do this (or choose not to), making notifications work less well.
To some extent it is forcing members to participate. If you Join the forum.wikidot.com, it is precisely to get the messages. It is like joining an email list.
For me this seems the 80% case, and thus should be default.
The fine tuning that I see is, for example, the ability to control the flow of messages (see http://blog.wikidot.com/design:3).
What role do you see for members in a site that allows them to participate without listening to the workflow, and why should this be the default scenario?
Can we distinguish, for example, between different access policies?
Portfolio
FWIW, the original idea of notifications was to allow wiki sites to replace email lists, because we found that projects systematically needed both wikis and email lists, which was painful extra work for admins.
The notification traffic on a wiki is roughly the same type and volume as an email list, which tells me that it's healthy in most cases.
But again, this is a certain collaboration scenario and does not necessarily apply everywhere.
Portfolio
Sorry for the duplicate postings. I clicked the "post" button and nothing seemed to happen; then I clicked it again. Moderators, would you please delete one of them? Thanks!
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
Last night I felt foolish. This, you must understand, is not an uncommon event. Normally it's as a result of my 9 year old daughter looking at me with pity on the grounds that I don't know the names of the actors in Hanna Montana and have no idea what to do with a Nintendo DS.
But this particular bout of foolishness was different. A person I am designing a community group site for asked me how to setup a mailing list so that people could receive updates about the site. I immediately thought that the best way was to join the site then they would receive automatic notifications of updates to the site by email - and then the hammer struck! I suddenly realised I had argued against this very thing earlier in the day. Oops.
So although I would still prefer it to be an opt-in as part of the process of joining a site (you tick a box, you get the emails), I concede that until that happens there are collaboration benefits to it the way it is in that it replaces email lists.
Rob
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Strathview ~ Wikidot-based wikis, websites & intranets and online database development. For community groups, villages, charities, business and government.
A weekly or even daily digest would be fine, but my test dummy had 10 emails in the course of an hour because I made a few navigation changes. That's pretty out of line. Even if I post something interesting, if I post it and then realize that I didn't like the title and go back and change that and then save it and then realize that I messed up some formatting somewhere and go in and fix that, now someone's got 3 emails about one post. No matter how interesting the post is, each new notification makes it less interesting and more annoying.
If you really want watching to be default (and I think that may violate the US's anti-spam laws) then you should make it a daily digest by default and allow the admins the option to change it between by-post notifications and weekly digests. And you could also allow the guests the option as well. Putting a check box authorizing notifications in the signup form won't hurt anything, especially if it's checked by default. Most people don't uncheck those things. Most people don't read the bold print let alone the fine print.
Hey, how about if you could choose whether to send a notification or not while editing? If you add totally new content, you just could put a tick in the box that could be next to "save" -button for example and a notification would be sent. If you do just minor changes like Morningbird's navigation adjustments, no tick, no notification.
___TTT___/ http://www.trumpetexercises.net
(_|||_) \ - Janne
Thanks, guys, for your thoughts (which actually help me clarify what I have in mind). As I see it, Pieter seems to see notifications as a member's obligation, while I tend to see them as — to a certain extent — a privilege, like editing or creating pages.
It can be both, and it should be up to admins to decide the right combination. I want to assign different categories to different moderators, and they should obviously watch their assigned category. As for regular members, I don't want them to have the ability of watching at all (except for forum discussions in which they take part and changes to their own profile pages in our directory).
If important changes are made, we, mods and admins, will announce that, not only to members, but to pretty much everyone interested (say, through a "site news" category in the forum). Currently that is done through RSS feeds (consequently, through Twitter and Friendfeed) and through our mailing list at Yahoo. Eventually I want to be able to replace the list with a Wikidot solution. The list is also rich in content, and that should be unified with the content in the site.
"So," you ask, "what's the point in being a member?" Only members can add per-page comments, and, in the future, when I replace our mailing list with a Wikidot solution, only members will be able to post messages. Also, members get to have a mail form added to their profiles in our directory (for instance, here).
Our site provides various resources to a specific academic community (scholars of South American indigenous languages): thesis and dissertations, out-of-print books, journal articles, etc. In the future, when we can have more refined permissions (pages that can only be seen by members, in an otherwise public site), then we can introduce "premium" content (say, preprints of books and articles, etc.).
Maybe that is not your typical wiki situation — but then again, Wikidot is much more than a wiki host. I can think of several academic, professional, or community-based initiatives that could make use of similar settings.
If you want to keep automatic notifications as a default (something potentially problematic, as morningstar says), at least allow admins to decide which (if any) categories should be watchable.
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
That would be a great solution Eduardo.
Rob
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Strathview ~ Wikidot-based wikis, websites & intranets and online database development. For community groups, villages, charities, business and government.
Thanks, Rob. And here is another good idea:
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
That's a great idea. Then the world need not know that it generally takes me three tries to get my modules right!! :(
For one site I am doing for a local community action group it would allow members to receive important updates without a blizzard of emails about back-end changes which they just don't need to know about. Hopefully we'll either get the ability to make specific categories watchable or we'll get weneed:61 (facility to email all members). I still don't like automatic watching being switched on by default as even sites with a lot of members are not necessarily collaborative.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Strathview ~ Wikidot-based wikis, websites & intranets and online database development. For community groups, villages, charities, business and government.
The following code CSS code should change all join modules from:
Join this Site
to this:
Join this Site
~ Kenneth Tsang （曾勁驊）, 15 years and counting…
kTsang.tk - view my blog, watch my videos, see my pictures :D
Wikidot Mobile Editor | @tsangk Twitter | EziWebs - Wikidot… but not really
Very nice. So I can define a join-text-link class like that, and then use it with the class= argument.
Portfolio
Because this CSS is being added to a custom CSS sheet, you only need to change the values that need changing (so you can simplify your code a bit). Also, you can rid all background elements with background: none; instead of 3 different attributes:
λ James Kanjo
Blog | Wikidot Expert | λ and Proud
Web Developer | HTML | CSS | JavaScript
Ah! Yes. Something like this:
together with this:
[[module Join button="Please join our site!" class="join-text"]]
~ Kenneth Tsang （曾勁驊）, 15 years and counting…
kTsang.tk - view my blog, watch my videos, see my pictures :D
Wikidot Mobile Editor | @tsangk Twitter | EziWebs - Wikidot… but not really
Exactly. I'm putting that into the rainbow and minimalist theme sets.
Portfolio
I have just been setting up a site with a password to join. I noticed that in the screen where the user enters the password it says:
This is potentially confusing as the user might already have a wikidot account. Could the text be amended very slightly to say the following?
This avoids a situation where a user might try to register again, particularly as the login link on the registration page is not very prominent.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Strathview ~ Wikidot-based wikis, websites & intranets and online database development. For community groups, villages, charities, business and government.
Good suggestion, Rob: noted.
Portfolio