Educators - weigh in on login systems!

One of the early suggestions made by educators was that they needed to have a better idea of who was logging in to their wikis and making what edits, particularly in a classroom setting where students might be graded based on their contributions. That was part of the initial impetus for the PBwiki Account system (which was the PBwiki Identity system at the time).

So, this, along with the case illustrated by Carolyn, represent two somewhat conflicting use-cases, and I'm hard-pressed to, off the top of my head, think of some resolution. Anyone else have an idea?

Here's my thought. When a teacher signs up for an educational wiki, they can assign user names to their students. The students can then log into a PBwiki Account with their user name and a password assigned by the teacher. This both protects the student's privacy and gives access without an e-mail address.

Students would then be able to merge multiple user names in the PBwiki Account, just like e-mail addresses.

then, from an engineering standpoint, are those usernames only specific to that wiki or are they unique, PBwiki-wide usernames? And on the login page, would there be three login forms? Or would a teacher choose to have only one way to login to a given wiki?

The problem with the teacher assigning user names to each student in the class is the time involved in doing so.

Why can't we go back to making this an option at set up? When an educator signs up for an educator wiki, could they be given the option of simply using an invite key or making users get an account?

Hey Vu,
I'm thinking that the users names would work just like an e-mail address. Students given multiple user names from multiple wikis could merge them into their PBwiki account. Then perhaps, edu wikis would only have the option to log in with PBwiki Accounts, which would work with both e-mail addresses and user names.

Hey Carolyn- what if the usernames were auto-generated? Say for example, a teacher creates a wiki and says that she has 27 students. PBwiki then creates usernames for 27 students, and the teacher can hand these out. The students would then register for PBwiki Account as normal, just using the user name instead of an e-mail address.

What if the students just use their real names, like firstname.lastname, for a username. PBwiki could automatically create Identities of the form "Firstname.Lastname@WIKINAME" which they could use to log in. As long as they are logging in to WIKINAME, they needn't even enter the WIKINAME part, just their own names.

That might be a hassle for a teacher - what if new students need to be "enrolled" into the wiki? The instructor would have to contact PBwiki each time that occurs. I think the admin privileges, in this case, would have to remain the instructor's responsibility. Especially in my circumstance where I roll over my wiki each 3 week session. Having the option to just give out a password is exponentially easier.

Give us the option! Please?

Guy- that's a great idea. The one issue I would have with this is just security based- a lot of schools would not want this information on the web (whether its private or not, this seems to be a concern). The other concern I might have is that there's no guarantee they'll use their true first and last name. We might have a whole bunch of seymour.butts@wikiname :)

I wonder if we could do the pre-assigned username@wikiname... some combination of our two methods might just be the ticket.

Hi Carolyn,
New students are definitely a concern. I'm betting we could make it an admin privilege to have and "add user name" tool.

I would figure using a name for login is a non-issue, seeing as how we force people to put in a Name entry on the 1.0 login page.

My son has a 6-digit ID number that was assigned to him in kindergarten, and the school district has used that as an identifier ever since; for that reason, he knows it by heart. For any school that uses such an identifier, that might make a good username.

As for seymour.butts, if credit for work is given to students by name, then seymour would be at the head of the class, while the student gets a zero.

TouchéGuy Fawkes, touché:-D

Perhaps teachers could upload a class list with a custom-made tool from PBWiki. Then, those accounts could preliminarily be given PBWiki accounts -- until the student visits a special landing page to "claim" their account and optionally add an e-mail address to their account. And, if they never claim it, it expires within a set amount of time. Or something like that.

This is getting complicated, but i think we're on to something. Can we take care of this hassle at start-up? That's really the only question I'd like answered. I think the problem starts there, and there are 2 levels to it.

1. When I sign up for a wiki, one of the first options/questions should be if I want to make my site available to anyone with the invite key or just PBwiki account users.

2. If a teacher wants the security of only using PBwiki accounts, but doesn't have email accounts for students, there should be an option in their admin area to assign user names (which you just suggested) if they choose to take on that responsibility.

This is not a bad idea, as long as this tool is super easy to use. But I still think this should be taken care of after the second level (see my reply above), after the teacher has decided to use a "secure" wiki. Didn't we used to have that option in an older version of 1.0?

Under COPPA, wouldn't that count as "gathering personal information?" All the kids in my building are under 13.

When the kids added comments, I wouldn't want usernames that showed last names; that's against our district policy. I imagine it's the same for lots of school districts. Usernames show when people add comments, don't they?

Though it would work if little kids used, say, their teacher's last name or some other word (like megan.apple@WIKINAME or nathan.book@WIKINAME.)

Though having to type all that in would probably take my youngest students about 10 minutes!

Go Seymour!

But seriously (or butt seriously...) that's a great idea. No system is perfect; kids could still log-in under somebody else's name--but that could happen with e-mail log-ins, too. I'd love to be able to assign usernames, because I could make them as simple as I needed, or even make them something they already know, like ID number or library card number or whatever.

The owner of the wiki could to add a batch group of students - using a false email or school ID number. I do this for another wiki as well as for a Moodle site that I manage. The issue comes when they must "validate" their email.
Sharon B

OK- the confusion aspect makes sense. Could that confusion be cleared up with a short 5 second video on the different log in screens, showing users how to log in? People click to watch videos before they even know what they are doing and it wouldn't take up too much space. I guess I'm just used to finding work arounds in my training course because most of my students have never seen a wiki before.

I'm not sure what you mean about "switching between the two models." Other than the fact that once a wiki is private it cannot be switched to a public wiki. However, the reverse is possible in the settings (making a public wiki private). Am I on the right track with this problem or way off base?

The confusion is not within a given wiki, but when people switch from one PBwiki wiki to another, they will expect to have the same experience, but within such a split model, that will not be the case. The alternative (to allow both logins on a single screen), has been shown to be counter-intuitive and we have had numerous complaints.

It's an interesting problem (one that I would like to see solved, of course...)

Right, but when a person is switching from a public wiki to a protected wiki, they would need an account, anyway. So they would be able to merge their public wiki onto their account and only have one log in after that initial set up.

Forgive me if I'm wrong... I don't think the people who are switching from wiki to wiki are the people to be worried about. It's really easy to figure out how to merge separate wikis into one account.

The ones to worry about are people who have never used a wiki. Odds are these people will not have another wiki right away, so there will be nothing to switch to. I realize this is kind of a bold generalization, but it's true in my situation.

What problems are created by using a single free e-mail account that every fifth grader enters when they sign in to contribute content? (They are not moderators, just contributors.) I seem to get the notifications of edits just as expected, although those come to different accounts (that's the subject of a different question...) none of which is the free account that they type into the log-in. (This is a public v1 education pbwiki.) I realize that at this stage I depend on the students to say honestly who they are.

I would like to find the time to create a set of pb Identity entries for everyone. There is never enough time to tackle that... or at least I haven't had a serious problem yet with this single e-mail entry method.

Jonathan

You are turning this into a nightmare for teachers. I teach over 400 students per year and will not ever have the time to add users, etc.

I need it to be simple. I need a radio button that says, "anyone can edit this wiki" that I simply can turn off and on.

That way, when I go to the computer lab, or for a determined period of time, I can allow anonymous edits (perhaps with the ability to add the name as an option) and then I can turn that back off again to require an invite key.

The options discussed work in ideal situations, and yes, my students have ID numbers but I don't have the time to upload all of them. Nor do I have time to look up the kid who always forgets theirs. Or the kid who gets home and forgets how to login to the wiki.

I need turnkey and easy. Students are tech savvy but mine are young, and I can't be 24/7 on call with tech support.

Please, I implore you, make it simple. If other teachers want to use this with students year-round and have the time for a more complex, name-based setup that's good for them. I don't.

I agree with Carolyn's suggestion: allow the teacher to make the choice when the account is set up. Personally, I sometimes have a project that would be better handled with an invitation key; othertimes I'd like more control over who enters.

Guy, we have an incredibly transient population. About half of the students move in and out of our district every year. There is no point having anyone memorize a student account number, here.

However, it's a point well taken that any student not putting his/her name on work gets zero points!

I agree with crafty184, that simplicity is going to be critical. Our classes are immense, and there is no time for detailed instruction just to get into the wiki in the first place (much less deal wtih students enrolling into the program for the first time, each and every day).

I REALLY REALLY liked the idea of an invite key, because it was easy enough to point the kids towards the wiki addy, and then just say "type in your name, and then type in the easy-to-remember key." This worked like magic. The probability of a non-class member knowing (or remembering, or caring) about the wiki addy or invite key was remote. Frankly:

a) Most other people don't care that much about an academic wiki (certainly not enough to vandalize it);

b) Most people can't remember the wiki addy AND invite key well enough to go back and vandalize, either;

c) To be perfectly honest, my a lot of my secondary students won't remember their homework, their hygiene, their lunch money. They are not devoting ANY extra intellectual bandwidth to wiki addies and pass keys. As a result, the work is safe. From my students. Also from anyone they might share with.

I'm saying that the complexity of the wiki addy, and having to know the password, makes the wiki very safe. I'm really unsure about why this formerly useful program no longer works for pbwiki oh two.

Sounds like the divide is between elementary/secondary educators and the rest of us. Most elementary students don't have email addresses, and although many jr/sr high school students may not have them, there is an argument for introducing them to it and requiring their use. Either way requiring users to log in using an email address poses possible problems for these educators.

Some of the proposed solutions offered above seem a bit confusing to me, and I'd have to admit the current state of logging in is confusing to current users. With that said, I still agree with the move to email log-ins. I am a college teacher though, and students having email is not a current issue for us. We just send them to Yahoo! or Google. When it was an issue, I did this: http://tinyurl.com/3ccqmk

The social features available in a wiki where users create an identity help to create a better collaborative space where students are not just contributing content, but they are also participating in a community. They have names and icons that represent them. They can easily be held accountable for their activity on the wiki, as well as easily be credited for their contributions. It's amazing how many names students can come up with to represent them when given the option. It gets confusing.

I suggest that if an option be given, that it's given at start-up. We could have a choice between an education wiki, higher-ed wiki or other. If you choose education you get 1 thing - key, and if you choose higher-ed - email log-ins. The likelihood of users crossing is small thereby eliminating further confusion. PBwiki is supposed to be as easy as making a peanut butter sandwich. The more choices the less easy it becomes.

I love the idea from soul4real. We need an option. I searched for every possible solution last night and came to the conclusion that PBwiki needs to allow a key to log in. We do not allow student e-mail in our building. We do want to encourage the integration of let's say monitored technology. Also, If I recall, there is a legal issue with accounts under age 13.

My question is when can we expect this to be resolved? I'm helping with a tech camp this summer (apporx 100 educators) and wanted to teach teachers how to set up an account, make a wiki, and discuss uses in all disciplines. I was all ready to go until this happened. Should we go to wikispaces????????

I thought Wikispaces also required an email login....that's why I've always used PB over Wikispaces or Seedwiki. Now I'm not sure what I will use with my teachers, especially elementary.

They have admitted that "Our e-mail based 2.0 login system will not work for students with no e-mail addresses", so there's a chance that they will fix this in the near future. Given the fact that 2.0, while "officially" released, is still quite new, and will doubtless be changing for some time to come, I would recommend using a 1.0 wiki until such time as they make 2.0 useable for everyone.

My wife has been using PBWiki 1.0 very successfuly in her classroom for some time now. Her students' success convinced me to use it with my students as well. When I registered last week I signed up for version 2.0 not realizing that my students would need an e-mail address to login to the wiki.

I've spent quite a bit of my Spring Break making a wiki for my classroom, and I was looking forward to sharing it with my students, and watching them begin to use it as a learning tool, when they return to school on Monday.

Now, it looks like I'll be unable to share.

I wish 2.0 had an invite key like 1.0....would make things a lot easier for me.

Educators want simple, companies want protection, and some people just enjoy the free web space.
Here is my suggestion: make only minor changes to what you already have. I apologize if this sounds a little harsh but this is only my two cents.

At start up you choose if you would like an invite key wiki or a group wiki.

Invite key wiki:
----------------

In this type of wiki you only make the user enter the invite key and a name no e-mail address. I mean the thing doesn’t even validate the e-mail now as long as there is an @ and a (dot)something your good. So this leaves us with the issue of WIKI VANDALISM. This is what I came up with. Deal with it! I am sorry but If you want simple your going to have to give up something. If the user types in their name as someone else your just going to have to deal with that too. So if Timmy signs in as Greg and posts dirty words you will just need to handle it. Sorry but that is just what I see. You tell the student the invite-key and to type in their name but past that your just scratching in the dark. There isn’t a way to make people responsible for their actions if you are not making them an actual identity for the wiki. And even if you do make them identities if someone figures out someone else’s identity information your back to square one. Dishonest people will always find a way to be dishonest. “If crime doesn’t pay why are there so many criminals?” (quote: I just don’t know by whom). As far as giving credit it goes back to the Seymour butts post. If Seymour is the only one posting he is the only one getting credit.

Group-wiki:
-----------

For this I suggest that instead of creating pbwiki accounts you allow the admin of the wiki to set up personal accounts for just that wiki. They input a user name and password for each user as well as the level of rights that they get. If the wiki involves a lot of people or is really large 9 times out of 10 there will be a team or group that has admin rights and the burden will not just fall on a single individual.

Now as far as the login screen is concerned. On a programming level that needs to be dynamic. If the wiki it will re-direct to is an invite-key wiki then you only need two input boxes and some explanation. If it is a group-wiki then you can have them sign in with the user name and password that has been created for them by the admin or you can have a drop down box with all of the names and they just choose theirs and enter their password. No offense but I don’t see a reason for wiki users (not owners) to have identities with pbwiki. Of course to set the wiki up you need to cough up a valid e-mail and all of that good stuff and a pbwiki account for maintaining multiple wikis is a great idea but just for users I think that the two systems above are the easiest.

As a company that falls inbetween simple and protection I would like to point out what we want - as it may represent a point of view for educators as well.
We have content that we want to provide as education. We want to give a URL that takes you directly to the content in read only form, but it is still considered a private wiki. No log in, we handled that before we gave them the URL.
A second URL would be for those we trust to make comments (this is your student issue).
The key here is ease of use for both the wiki administrator and the user.

I agree that there is a divide between teachers of elementary and older kids. Some of my middle school kids will absolutely cause problems if they are not required to log in w/and email address. It may be easiest to give the choice mentioned earlier...only need the invite key or must log in with email.

I just got off the phone with a coworker telling her I would set up the wiki with an invite key. Then I searched and found that option missing. It is easier for us to use the invite key than to invite by email address.

I hope that option will be returned. Is it still available on the non Web 2.0 wikis or the paid version?

Passwords still work on 1.0 wikis, paid or not. They do not work on 2.0 wikis, paid or not.

We've been using PBv1 for a while now and have had no issues with the invite keys k-12. We don't have student email and I don't want to admin 80K student ids for pbaccounts. During a preview of v2 logins, I liked the idea of multiple login strategies, but after dropping the pretty penny for v2site and not having the invite key (or something similar), I'm having a hard time facilitating wiki development in our large district.

I would agree with some in this discussion that the multi-wiki user will probably have no problem creating an account and logging into their account and combining wiki id's into one pb id. But the large majority of teachers/students I work with only have 1 wiki they use. Keeping up with login accounts, lost passwords, etc throws a barrier for many of the teachers who are barely stepping into this technology in the first place.

The invite key in v1 was nice because I could attach it as a link at the bottom of the page on the wiki. Students (and parents) at home could login to the wiki to edit without having to have an email on file with the teacher. I know it's not totally secure, but you also have 20+ (parent/student) contributors who will catch most inappropriate materials and remove it quickly.

I understand the problem for pbw is largely that one solution will be a hard fit for all k-12 and business wikis. At one time, there was a mock-up of a three sectioned login screen: Public Invite Key / PBWiki accounts / Email login .

I like the 'fake email' option we once had as well. Much like a WordPress blog, teachers could authenticate one fake email for login, but editors of a page could still sign their edits with their student alias/name/id whatever.

Rachel, thanks for the opportunity to weigh in.

I think the "invite" key is KEY. I do lots of training with educators in staff development sessions and in classes and an invite key allows them to start working in the wiki and contributing right away. Add the e-mail/registration step and I have to look for another option that is quicker.

Please bring back the invite key ASAP

Thanks,

Dan

I teach 8th grade in a middle school. It is really important to me to know EXACTLY who is doing what. Logins and passwords limit students using the space to destroy another's work or use the space for cyberbullying or other inappropriate activities. The first day my students logged into a blog that I had created, there were inappropriate entries. Maybe the rest of the world has students that would not do this, but I don't. When I created my wiki it used a gmail account. Each student was assigned an email address that was mine+their name (science+tim@gmail.com). I then responded to each of these by entering a password for each student. This was terribly time consuming!

How about an update from the pbwiki tech people and staff about where internal pbwiki discussions have led? Have you developed anything to resolve this issue yet?

In my case, I lean toward the invite key solution because I work with adult immigrant English language learners and I just want them to be able to work on the collaborative pages I've set up for them without having to jump through too many hoops. I don't really have to worry about malicious postings with my population but I do occasionally have to deal with students erasing things inadvertantly and being able to revert to a prior version has solved that issue for me. Many of out students don't have email addresses (nor computers for that matter) so an email-based system is not viable for them.

Seems to me that the proposed solution allowing the wiki creator to choose between an email log in and an invite key at the time of wiki creation is really the best direction to take if technically doable. As for the issue of users being confused when visiting wikis with different systems, the log-page could just state "The creator of this wiki chose an email-based log-in system" or "The creator of this wiki chose an "invite-key" based system" as appropriate. This wording would imply that there are other systems in use so that when new users visit a wiki with the other type of system, they would be a bit more prepared for that eventuality.

While I was considering moving to version 2 of pbwiki, I don't think I will be able to do so until this issue is resolved. I also train and introduce wikis to other teachers in my division who have similar student populations so I think I'll have to recommend to them to stay with 1.0 as well.

I would like to see individual user names and passwords. This allows me to track what each and every student does on the wiki.

I agree with bringing back the invite key. I do workshops and don't have the participant names ahead of time.

In another role, I work with elementary and secondary classroom teachers. Their students don't have email addresses so they need a way to login with an invite key and their name. As far as abuse, we're looking for good/appropriate content and if a person's name does not have such content connected to his/her name, they don't get the grade. If inappropriate content is placed in there, it is removed and students are reminded of the rules. Then we move on to focusing on the content that will be assessed. We don't focus on who did it as that isn't an exercise worth class time, IMO. If the behavior were to get out of hand we would put an end to the use of the wiki. Students enjoy the opportunity to work in a wiki enough that this hasn't happened yet but they know it is out there as a possibility.

The other set of people I have are the non-editors, the community such as parents and school administrators. For them the wiki needs to be private so student material isn't viewable by the world without some sort of permission or login. But I do want them to have access to seeing what students know and are able to do. This is their opportunity to get involved even those who are working and don't have a chance to spend time in the classroom and know what the kids are learning.

I think an invite key works for this as well. If it isn't resolved soon I would like to know how to transfer my content to 1.0. Meanwhile, I may be looking for a new wiki solution.

This discussion started a month ago. PBWiki, where are you in making a change?

I think that one of the best solutions is to have invite key with a name. A teacher will give out invite key then a student can login using his first name + teacher name

I think having an optional blanket key of some sort that can be distributed and will work for multiple people would be very helpful. Most of the wikis that I've been asked to participate in are group based. We send out the link to it to a mailing list. For very small wikis there is less worry about vandalism than larger ones; in fact we've posted the 1.0 password to the wiki on the front page of the wiki and haven't had any problems.

(I'm not an educator, but I wanted to answer the question too)

Login and passwords need to reflect ease, security, and anonymity. My students do not have email accounts they can use for school projects. I can't use their names. I have 70 students in grades 5-8 for which the wiki is a fantastic forum.

However, I need to know who is on and who is editing what.

I need to restrict certain pages (locked is nice).

I see a "page-level" access in 2.0, but I don't know what that means.

I'm thinking it would be nice for students to be able to create their individual pages which are locked except for their password. Some pages would be locked, others are for collaboration.

I just created a whole site in 2.0 (silver), not realizing that each person had to login (and they don't have emails) and that I can't control the level of use.

I thought at first that I could have editors, moderators, writers, and page-level only passwords. Oops, I blew that one. Copy and paste to 1.0, I guess, although the new folders and page security is great !

A way I've heard other wikis use, is the teacher sends in student names and passwords which are set up for the site by the wiki admins.

I see why 2.0 went to PB Identities, but I need more control over the students' use, instead of giving them PB access like adults have -- the PB identity page invites them to create their own, add other wikis, etc. I wish the world were a nice place, so open and free. But I've must provide a more in-house solution. The techy kids will still go off on their own -- but not on my watch.

I noticed one discussion mentioned something like adding student names to their emails? like teacher+student@gmail.com Is that possible? I wouldn't use the students' names, but I could use their class code. I would not suggest using any "official" student number.

So: easy to set-up student usernames (not real) and passwords; still need differing access levels; would like page level access code for certain pages to prevent others from editing their final work.

Thanks. Sheri

I would love to see pbwiki go back to invite keys/passwords. That has offered the protection my students need without putting limits on who is accessing the wiki. For example- I may send home a wiki address for parents to add comments or edit within a table. It would take huge amounts of time for me to enter every parent email address. My hope is that you will move back to a password/invite key before my summer training sessions. I will not be able to use pbwikis in my teacher training workshops unless this issue is resolved and I love pbwikis!
Judy

Is there any update on this issue?

I agree with Anne-Marie. Where are we on the invite key/password issue? I am conducting 2 workshops for teachers in July and August. I was planning on using pbwiki since I am a big fan- BUT if the password/invite key format is not resolved I will use a different wiki. pbwiki worked great for teachers and students when we used a password. PLEASE bring this format back.

Five days ago they said they are working on the "request access" feature that we've "been asking for", in response to this situation. When I pointed out that making users "request access" was just as bad as the current setup, they replied that they "have other solutions that will be implemented as this develops that should meet the needs as described above". Given the current progress on this issue (none), I would begin researching alternatives if you have pressing needs for open wikis in the near future.

The invite key was part of 1.0. The code exists. I'm failing to see why it is so hard to just put it back in 2.0 or to come up with something that will let us revert our 2.0 PBwikis to 1.0.

I just got an announcement for other new features for educational PBwiki 2.0. While I can now annotate and keep track of references, that is all very nice but if my students can't get in to use the system b/c there is no invite key to give them, how on earth does this update help?

I'd much rather see you fix the missing features from the move between 1.0 to 2.0 then to spend time on new features I've never used before and have therefore successfully lived without.

Hi! A couple of people have asked why we didn't just put invite keys into 2.0. After all "the code exists", right?

The issue is that 1.0 had a lot of very different ways to get into a wiki. The login page itself became very confusing (are you logging in with an invite key? Or a user account?) and we couldn't make guarantees about exactly who had done exactly what on the wiki. This generated a lot of support requests and it just wasn't a good, simple, "peanut buttery" solution. We tried several different iterations of login screen to see if we could message the dual systems more clearly, but this generally didn't pan out.

When designing 2.0 the team therefore made a decision to first have a unified and simplified login system that just asks for a username and a password. We recognized that this wouldn't solve the needs of everyone in 1.0 and that therefore we'd need to put some time into thinking about ways we could have our cake and eat it too to get to a place where we had a system effective for educators.

I appreciate the intensity on this thread. It's quite clear from the volume and passion that you want the 2.0 features and a mechanism to get students in that's as straightforward as an invite key. Some very specific and very helpful suggestions have been put forth on this thread that we'll be taking into account.

Just so you guys know, this is one of the very top issues at the company - all of the company managers got together for over an hour today (with this GS thread on the projector) to discuss how we were going to resolve this. We are determined to get you a timely solution that meets your needs.

Our apologies for the bumps along the way as we grow and work to provide you with the best wiki solution ever. Thank you for your patience.

David, wow, a whole hour? I participated in one of the online conf calls in early March. (Also about an hour.) We were told that some exciting things were being developed and were to be released 'soon'. I convinced people here to pay for the nice PB license based on the many 1.0 wikis that we had and now I'm feeling the pressure since the easiest part of group teacher training is gone (invite key).

I don't assume that it's an easy thing to fix, but there has been months of feedback and PB needs to make any change they are going to make or stick with the decisions already made so we can choke on our money and find the other alternatives we need.

While we're working on this, I'd be nice if account login could set different notifications for different wikis. I'd rather hear from some once a day and others immediately. It's a pain, but not a deal-breaker.

I use my PB's and enjoy the simplicity of use. I have 4th graders tearing through pages and adding media content easily. There are so many good things about PB. But if it's a pain to get teachers trained in large groups, I will have to go elsewhere. There are so many other alternatives.

If you create custom userspaces for wikis or general no-password logins or magic URLS that create unique logins (or whatever the solution) do you think that you'll make this support available for any wiki that wants it, or do you think that easy no-signup-required access will just be for educators?

Hi, this is Janet Yu, Senior Product Manager at PBwiki. I'd love to talk through our proposed design for supporting classroom wikis in 2.0. Please email me this week at janet[dot]yu[at]pbwiki[dot]com if you're interested.

So this still hasn't been decided on yet. I did not make it to the presentations is there a way to view them now?

Sorry end of school year and family issues kept me from responding.
Are we still discussing this? Is there a link to a page to review the new ideas? I'm still hoping for the invite key/ one password. I included pbwiki in my fourth quarter writing class. Being able to change the wiki password daily made it so easy to manage. I don't think I could have done managed without it because I have four classes and 70 students to manage. Until the kids understand and follow their responsibility and the ethics involved in internet use, I like the security of the password. Just checking; I'm sure a good solution will arise that will serve everyone's needs in some way. Thanks.

We know our primary school teachers are really left out of PBwiki 2.0 since many of their students don't have email accounts. We're working on a feature that addresses this by allowing teachers to easily generate "classroom accounts" that don't require email accounts. We hope this will allow more of you to try out the great new features in PBwiki 2.0!

We also understand that teachers need to make their plans before the school year starts, so we're aiming to roll this feature out well in advance of the coming school year.

Thanks -- looking forward to the solution.

I am looking forward to the solution. I have used PBwiki for a couple of years with high school students. Even High School kids do not have emails, so 1.0 with password was great. They also needed to give their name at login so we know who did work.

BTW I was looking into an online CMS that would have wiki as part of it but cannot use it because it would require students to create an account. We are just not ready to require students to create an online presence that is accessible to the public. Telling them they have to have an email to do some of their work is very similar. Though most already have email, facebook, myspace, we CANNOT require it.

So what is the answer?

You might look into gaggle.net as an email provider that is accessible from schools since no accounts are "secret." Everything is viewable by administrators and teachers and filtered in both directions (in-going and out-going mail) with key words diverting inbound and outbound messages into the teacher's mailbox so they can be reviewed before arriving at their destinations. There's a free version (with school appropriate advertisers) as well as pay versions without the advertising. Account management isn't very burdensome and it's fairly easy to sign up students individually or in batches (even faster). You're not telling your students they "have to have an email to do some work," you're providing them with one that is suitable for school use.

I think the new option of creating student accounts for students without emails is great. Before you introduced this, I had to let students all share one account, and I couldn't tell which one made a change. It's also great having the flexibility to add people three different ways in one wiki. The one additional enhancement I would like would be the option to change a password once the user is entered.