10 reasons educators love us

Our friend and top educator Kathleen Ferenz sends us a report from a workshop she recently lead on PBwiki:

“Here are some winning quotes from this week’s workshop evaluations,” she writes:

  • “I love the ability of the wikis to easily create webpages for students and classroom use. The students can easily add information and student work for all to see through the use of the wiki.”
  • “Learned about the power and usefulness of Wiki.”
  • “Useful tools for sharing information with students, parents and other teachers.”
  • “The introduction to wikis and google docs.”
  • “PBwiki and Google resources are very useful skills that I aquired during this workshop!”
  • “Good ideas to use in my classroom and in my professtion life.”
  • “I can see the benefit of using wiki wiki with students and pass on the skills to fellow teachers at school.”
  • “Wiki web pages for collaboration for teachers and students.”
  • “Using Wiki is a fantastic opportunity for collaboration!”
  • “Vast potential, fun, practical. Will immediately implement at my school.”
  • “Setting up a pb wiki is invaluable.”

Coming up tomorrow: An answer to the question, “How would you use PBwiki in education?”

Super-handy new premium feature: Access via email

Here’s a great new feature especially handy for our businesses, education, and government users: Access-via-email lets you set an email domain, and anyone with an email under that domain can grant themselves Contributor access to your wiki. An example will make this a lot more obvious – here at PBwiki we run a bunch of internal wikis and this feature makes it easy to set up self-service — no more “hey, what’s the password for that wiki?” with new employees and new wikis. I set ‘@pbworks.com’ in the ‘Access via email’ section of the wiki settings and now anyone on the PBwiki team can let themselves in using their name@pbworks.com address. Easy!

access-via-email.png

The “Access via email” feature is available for all Silver, Gold, and Platinum wikis (it depends on the wiki being configured with a Contributor user level).

We're going to make logins and access controls much better

pbwiki_logo_250.gifToday we had a team meeting about improving PBwiki logins and access controls. This is something that is a top priority for us, and we’ll be working on it in phases starting immediately.

What to expect in the coming months
Better control over access on your wiki. You’ll be able to send certain pages to certain people, including groups of people (“Send this page to the engineering team”). For example, if you edited an agenda but only want marketing to get notified of the change (or the VP of marketing), you’ll be able to do that. You’ll be able to seamlessly add and remove access from your wiki using a simple interface.

Better visibility of who’s doing what. Our new system will let you easily see who changed what on your wiki. For example, if you add 20 people to your wiki, you’ll be able to see who’s confirmed their invitation and who’s edited a page.

Better handling of multiple wikis. Not much more to say about this except that it will be awesome.

Two examples
Let’s take two examples: Mr. Businessman and Mrs. Teacher.

Mr. Businessman is in charge of the wiki for his small company. He needs high security for his wiki — including an auditable trail of who changed what on the wiki, and IP locking so only people from his company can access the wiki (IP whitelisting is already available for business wikis). With these new features, he can say that Michelle changed the Meeting page on 8/10/07. He can have a full, printable record of changes. He is working on a draft and doesn’t want his manager to see it yet, so he hides it from everyone except his colleagues in marketing. He needs the marketing team’s input, so he gives them access.

Later, after it’s finished, Mr. Businessman will change the permissions so the CEO can see everything, the VP of Marketing can see all marketing materials, and his project manager can see relevant projects.

Mrs. Teacher has a classroom with 35 students and she uses PBwiki as a collaborative space for writing essays together, posting her syllabus, and letting the students collaborate. Using the new system, she’ll be able to import all of her students from an Excel/CSV file into her wiki and give them immediate access. She’ll also be able to see exactly who changed what on any page, including revoking access (or undoing a change). This is hardly ever a problem, but we know educators want to be sure about who’s changing what.

These changes will be slowly rolled in over the next few months, so keep your eyes peeled. We’ll keep you updated every step of the way. If you have feedback, leave a comment here!

-Ramit
Part of your PBwiki team

Brief Power Outage Aug 10, PBwiki Back Up & Happy

Folks,

This morning at 8:03am PDT, our San Francisco center had a power issue, causing about half of our servers there to go down. Due to the large amount of data we now safeguard, as our servers came back up, some of them took a while to verify the correctness of PBwiki’s data, and one of our database servers was fried. Thankfully, we’re quite rigorous about making sure data is in multiple places, so your data was not at risk.

But PBwiki was slow/unavailable for about an hour. We sincerely apologize; we’re putting in place mechanisms to keep the service from being as affected by a single outage and able to recover more quickly and gracefully. We take great pride in making sure that you have smooth, snappy, secure access to your data at all times.

Sincerely,
David Weekly, CEO

New feature for premium wikis: Accelerated access and search

The PBwiki team is on our annual office offsite, and we’ve been spending lots of quality time together brainstorming about new product possibilities, ways to make PBwiki more useful to our users, and how to make PBwiki the obvious answer for your online collaborative needs. In addition to the longer-term strategic planning and such, we’ve also been doing some late-night hacking of ‘hey, you know what would be cool…’ features and enhancements — ideas we’ve had in our heads for a while but weren’t fleshed-out enough for prime-time or didn’t fit into the development schedule.

Tonight we’ve deployed the results of some kung-fu from last night, a new feature for premium wikis. All of your wiki’s pages are stored in memory, ready for display to you and to search through. While we’ve got a super-efficient distributed file storage for every page revision and attachment (millions!), it’s still on disks on remote machines. We’re restricting this to paying customers because it consumes by far the most expensive resource on our servers, RAM. There’s no downside for non-premium wikis and we’re not making them any slower. As we build out our server hardware we’ll make sure we have enough RAM to accommodate all of the premium wikis this way in addition to our normal caching mechanisms.

The result: Pages on premium wikis load 10-40% faster depending on size, and searches are up to 10 times faster. We’re pretty happy with the new speed boost, and think you will be too.

PBwiki versus the speed of light

Here’s some timing data for a simple request to one of our development servers.

  1 ms - server A (San Francisco) -> server A (San Francisco)
  7 ms - server B (San Jose) -> server A (San Francisco)
 55 ms - PBwiki office (DSL + Ethernet, San Bruno) -> server A (San Francisco)
137 ms - PBwiki office (DSL + WiFi, San Bruno) -> server A (San Francisco)

Here’s something I hadn’t really put my head around before: The convenience of using WiFi comes at a huge cost — it adds 80 ms to an otherwise identical request.

Hmm. What this data says is that no matter how fast we make our servers, and no matter how efficiently we tune our code, the speed of light and other things we don’t really have control over (like that 48ms of ‘DSL stinks’ penalty) are major factors for your perception of PBwiki’s speed and overall ‘snappiness’. Let’s say wiki pages take 80ms to generate instead of the trivial test above that took 1ms. Let’s say we optimize our in-memory caching, then tune some other things and end up shaving 10% off of that, down to 72ms. An end user with DSL and WiFi would see their 220ms round trip time go down to 212ms — less than 4% improvement, and that’s assuming they’re right here in the Bay Area, which most of you aren’t.

That 80ms WiFi penalty is coincidentally about the same lag you get for being on the East Coast when accessing anybody’s servers in San Francisco. That’s one of a number of reasons we’re drawing up plans for an additional data center, likely in Virginia. We have a lot of users in New York and Washington DC in particular. That east coast presence will go a long way to improve the browsing experience for our European users as well, and as demand grows and revenues permit we’ll be bringing on a Continental data center, too. We’re working hard behind the scenes to make your wiki experience better.

New "What is PBwiki doing" page with realtime updates

[Edit: We removed this after trying it out for a few weeks!]

Now you can follow the daily activities of the PBwiki crew – realtime! PBwiki makes fairly heavy use of IM already, so we built an IM bot that forwards certain messages to our newest wiki page. This means the page will receive tons of fresh insight into our inner minds. (Note: This may frighten small children!) But we think it is important to find new and useful ways to keep the PBwiki community updated on what we are up to. Enjoy!

Unicode support in PDF output

It’s been on our to-do list for a long time but now it’s good enough for general use — our PDF export feature now supports more interesting characters such as what you’d find, oh, anywhere in the world other than the US. We’ve also thrown in image embedding and some basic support for tables and hyperlinks. It turns out the PDF standard is pretty hard to do well, and we’ve been gnawing away at this matter for months. (Aside: guess what an ‘Acrobat error 135 is’ — we had to, it’s not documented) In order to fully support the kinds of html you can (and have) put in your wikis we’d have to basically rewrite the layout and printing engines of a web browser, and we’re not really equipped to do that right now. What we’ve come up with is a good balance between utility and scope — making it incrementally more capable would require a pretty substantial rework.