modified from cc flickr photo by JTony

I want a law named after me 😉 Call this CogDog’s Law of Web Tools:

The “best” tool is the one I am currently using the most.

This played out earlier this week during Howard Rheingold’s session for the CCK08 session. While he was talking about his new social media tool, in a back channel, people were talking about wikis.

“Question- what is the best free wiki site?”

“I like wikispaces- it has great tools for embedding media.”

“PBWiki has the best editing features.”

“WetPaint is very cool.”

It is a bit of a silly pursuit that there is an absolute “best” internet tool– ou might as well go to Home Depot and hear the same conversations in the power tool aisle:

“I only by Dewault- they have the best power supplies and have been most durable on my drilling sites. Besides, it was all my Dad ever had in his shop.”

“No way, Makita is known industry-wide in home construction for the strongest motors and horsepower- I have never had one let me down.”

It happens with wikis, blogging platforms, web programming languages, mobile phones, beer, operating systems… it just seems human nature.

I get the question all the time when I do my 50+ Web 2.0 Ways to Tell a Story workshops — they want to know which of the 50+ is the “best”.

And I never provide an answer. Such a blanket opinion is meaningless, and depends on so many factors of specific use. And there never will be a “best”. I can share ones I like or ones that have some unique features, but it is not like a quantitative measure of “best-ness”.

So back to wikis, I have observed (and I engage in this myself I admit), then when the question comes up, I am highly favoring of the one I use the most. It makes obvious sense, since I would not use one I did not think was best. And I know all about the one I use the most because I have likely explored many of its features, and can use them almost without thinking about them, like a reflex. The “other” tool, that I don’t use or not very much, is more unfamiliar, and I may not even know all it can do.

So I submit it is a pointless exercise to say whether my Wikispace can “beat up” your PBWiki — if I am savvy, I am going to listen to the ways you use your wiki, and what it can do, and file that information away, because some day I am going to find that “my” wiki does not do something I think it should.

And in the higher altitude view– they both accomplish the same thing; providing a free platform for people to openly collaborate on content creation via a wiki constructor set.

But again (!) this was not exactly what I wanted to focus on… I have been using Wikispaces a lot the last few years, and it was really good for my 50 Ways site for demonstrating how embedded media content works, since the widget tool in Wikispaces allows you to insert almost any cut and paste embed code (FWIW in PBWiki you can insert the same directly into the HTML source when you are editing).

The thing I did want to share is I was recently looking at the help docs in Wikispaces and found a whole raft of cool codes you can use that I did not know about (as one who usually plunges in without looking, I content it sometimes it pays to read the help docs).

There are all kinds of codes you can toss in that dynamically insert information – see the Wikitext Variables section

  • {$page} inserts the name of a page
  • {$revisiondate} inserts the date of the last change to the page
  • {$creator} inserts the name of the person that created the page

Another one I forget helps when you have a brainstorming page where you ask people to annotate their changes with their name, so you can tell you write what– if you insert 4 squiggles: “~~~~” Wikispaces automatically inserts your user name.

There is a long list of more of these. But the thing I got excited about was it has includes- or what I use in MediaWiki as Templates. These are separate pieces of content you can set up, and then have inserted to any page you add an include code.

Tghese are most useful for creating page footers, or navigation links, or just any repeated content that you want on multiple pages. The benefit of this is when you change the originating source content; all the pages that include that chunk are automatically updated. This saves huge amounts of editing time.

From the Help section on Includes what I just described is a simple page include, but you can also insert code that inserts a list of all pages on your wiki, or just ones with a give tag or a tag cloud for your site…

So before finding this, I had cut and paste footers on the bottom of every page of our Web 2.0 Storytelling site – if I needed to change them, I’d have to manually update every page on the site.

But armed with this new knowledge of variables and includes, I have a much better method. I created a page called Footer that has this code:

This wiki is and open space for discussion of the 
EDUCAUSE Review article Web 2.0 Storytelling: Emergence of a 
New Genre by Bryan Alexander and Alan Levine. This page was 
created on {$creationdate} by {$creator} and has been edited 
{$pagerevisions} times. The last change was made by 
[[user:{$revisioneditor}]] on {$revisiondate}

All of the items in {xxx} are dynamic and will be replaced by relevant information on the pages they appear on. All I need to do to have this inserted into may pages, is to put (where I want it to appear):

[[include page="Footer"]]

(You can also use the Widget tool to insert a Wikipage). Which means, now I get a dynamic footer on all pages that use this, e.g. here are two different ones:

Now footers are pretty pedestrian– and you can also think about perhaps headers you might want on all your pages, or perhaps a logo you want on different pages– if there is any content you find yourself repeatedly copy/pasting to wikipages, templates/includes are invaluable, especially to update quickly.

And it gets really interesting when you have includes which include includes!

So I am looking at the PBWiki manual, and not yet finding all of these features, but seeing other things I like- some of the different widgets available (any Google Gadget can be embedded); the new PBWiki 2.0 feature to toggle from edit to view is great, and for some, a more featured WYSIWYG editor.

For me, one is not “better” than another, and there are compelling features of either.

Of course, I do recognize that it does come down for people new to the scene to ask, “which one should I use?”, and just be prepared that the answer depends…. on who you ask.

And lastly– none of this matters int terms of building a “good” wiki site; the buttons, widgets, magic code are just the framework for what really counts– your idea and strategy for using the wiki. The “best” wikis are ones that come from good ideas, great execution, and lots of TLC and wiki gardening.

Coming never– announcing the “best” beer….

If this kind of stuff has value, please support me by tossing a one time PayPal kibble or monthly on Patreon
Become a patron at Patreon!
Profile Picture for CogDog The Blog
An early 90s builder of web stuff and blogging Alan Levine barks at CogDogBlog.com on web storytelling (#ds106 #4life), photography, bending WordPress, and serendipity in the infinite internet river. He thinks it's weird to write about himself in the third person. And he is 100% into the Fediverse (or tells himself so) Tooting as @cogdog@cosocial.ca

Comments

  1. As an ed tech trainer who likes to promote wikis I get the same questions: “Why did you choose PBwiki?” “Which wiki service is the best?” “My freinds told me about Wet Paint, why aren’t you teaching us that one?” etc.

    Though I try to provide a solid “professional” answer, the truth is, the answer is really “just because”. I started using PBwiki because several other people whose work I like were using PBwiki. I can’t tell you which is the best because I haven’t used the others as much. I can only say why I like the one I use–for example the ability to add students to my wikis even if they don’t have email accounts, which is often the case with my student population (Adult Basic Education, GED, & adult ESL). And the embedding of widgets is slick, as is their new Document Management system. I’ve thought about building wikis on other services just to learn more about them, but I’d rather spend my time making my existing wikis better.

    I’m happy to hear that I’m not the only one who gets these questions and doesn’t have a rock-hard answer!

  2. Those codes will be handy… I might have to read up on that “documentation” thing I keep hearing about.

    I’m with you– what matters is the content. After that, the best wiki engine is the one that you are using (which implies you know enough about it to make it useful and it does the things you need it to do)!

    It’s the same with pretty much every technology isn’t it? Sometimes tech smackdowns are fun, but most of the time the people worrying over it are those who haven’t put anything into any of them, like the scrawny kid in the gym who has yet to lift a weight arguing about which lifting program is going to pump him up…

Leave a Reply

Your email address will not be published. Required fields are marked *