Mmm, dogfood. Here at PBwiki, we make use of our own product pretty extensively. And having used an internal PBwiki for some three years, we’ve accumulated a pretty large collection of material! This makes it ever more important that we be able to search it and find what we’re looking for. So we’ve dramatically overhauled (and improved) search.
You may have noticed when PBwiki search improved a few weeks ago, getting phrase search, boolean inclusion/exclusion, and filename matching. Well hold onto your pants, because you ain’t seen nothin’ yet.
Search has been dramatically restyled again:
- Information about who last edited a page and when
- Suggesting page names similar to your search query
- An adding helpful icons to the result list to let you quickly distinguish wiki pages from PDFs
- Giving up to 200 characters of “snippet” context (vs 80 previously)
- Ranking search results and interleaving results from wiki pages, discussions, and filenames
- Letting you drill down to only search pages with a given tag or in a certain folder
Coming very soon? The ability to search inside PDFs, Word DOCs, Excel files, PowerPoint, and more.
If you have feedback about this new feature, what you like and don’t, please chip in here and I’ll read every comment! 🙂
Feeling adventurous? We’re building a team of PBwiki users to help us test out new features before they go live for everyone. We need about 100 testers who know their way around a wiki and aren’t afraid of the cutting edge.
If you’re interested in trying out new things ahead of time, don’t mind the occasional glitch, and are interested in giving us feedback, you can apply here. We can’t wait to hear from you.
When PBwiki 2.0 launched, it included lots of great new features, but one thing stayed exactly the same: the notification emails you got when somebody changed a page on your wiki.
We fixed that today — here is a sneak preview of the new version of notifications.
The new notifications…
- Let you see all changes made to your wiki
- Have shorter change logs, and are easier to read
- Respect your notification settings
- Won’t be marked as spam!
To get a sneak preview of these new notifications, go to your wiki settings and check the box that says “Sneak preview new version of notifications”
Keep in mind that they’re not quite done yet, so if you have any problems, just turn off the sneak preview (and be sure to send us feedback). Enjoy!
That’s geek code for “PBwiki loves South by Southwest!” One of the advantages of a tool that’s simple to get set up and running with like PBwiki is that you can use it to make quick, ad-hoc workgroups at conferences like South by Southwest. If you’re looking to post your own itinerary or put together a spontaneous birds-of-a-feather session, come set up a new wiki with us and email firstname.lastname@example.org with the address and I’ll add it to the official PBwiki SXSW page.
Founder & CEO
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.
I’ve been running some internal stats on the various activity levels across the PBwiki landscape. This set of numbers breaks categories down by volume of activity rather than unique users.
How much activity on private versus public wikis?
Around 2/3 of our activity is on private wikis. Takeaway: Our users have found lots of uses for PBwiki that we don’t know about, and we’d love to hear your stories.
How much activity on free versus premium wikis?
More than 16% of user activity is on premium wikis. Takeaway: Lots of people are taking advantage of our great premium features and enhanced security. Yay!
How much activity among major browser families?
Around 56% IE, 39% Firefox, 5% Safari, <1% everybody else.
How much activity over SSL versus unencrypted?
5.5% of our activity is over end-to-end SSL, which is available for our Platinum and custom SMB and business packages. Lots of companies trust PBwiki with their most sensitive documents.