If I owned Wikidot

If I owned Wikidot

Sunday morning dreaming had me thinking of ways to improve Wikidot.

The other morning I was thinking about what I would do if I could buy Wikidot. I would like to whittle down that big list of user-requested features waiting to be added, but the only way to achieve that is to hire more developers. Developers, for some reason, are expensive. The obvious solution is to increase the user-base, with a proportional increase in income. More users in general, and consequently more sites, would increase revenue from advertising, and would also increase the number of paying (pro) users. Therefore, we need more mainstream appeal. How? Here's what I came up with.

New design

It's time Wikidot got a new look. The current design has been around for years (from at least since I started using Wikidot1) and is starting to look dated. I'd implement a new theme to be used across the Wikidot brand of sites (www, blog, feedback, community), and give the interface elements (page editor, site manager, etc) a refresh.

Better theming system

For a large proportion of people, looks are everything. Themes need to be easy to use and great to look at. Currently that's not the case. Not only are the default themes available in the site manager hideous, the whole theming system is clunky and too complicated to use. It's time for a change.

The default themes need to be scrapped and new, better-looking ones put in their place. Themes on the themes site should be available directly from the site manager. Furthermore, the themes themselves need more flexibility - rather than a single CSS file, you should be able to define the HTML as well, with placeholders for where the content goes. Security wise, any script tags would be removed before the theme was available for use. Additionally, you should be able to define separate page templates that can be selected on a page-by-page basis in the page editor.


Having to iframe every bit of external content is annoying. Iframes suck. Not all external javajcript has a find-and-destroy evil intention. I would implement a new plugins system that allows the use of external content. For example, take my tweet button snippet. Rather than having to iframe the button, I could define its content on the plugins site, and then use the following code to include it on a page.

[[plugin TweetButton url="%%link%%" via="brycecammo" align="right"]]

That would inject the appropriate HTML/JS directly into the page with no slow-loading iframes in sight. Plugins could be reviewed before being publicly available to allay any security threats, and they could be enabled/disabled on a per-site basis as an additional security measure.

New forum, better comments

Currently, the only way to get a decent, flexible commenting system on your Wikidot site is to use some copyrighted-Kung Fu-ninja coding that uses iframes (see above). Not cool. It's time the forum got an overhaul and took the best bits of leigerleiger's NoComment forum and integrated them 'natively'. Build your own website with a fully integrated forum is a fantastic selling point that should be trumpeted further.

Scrap the old sites, streamline the rest

There's a whole bunch of old Wikidot-made sites out there that used to be something, but are now defunct. There's a whole lot more that do much the same thing. Not only is this unprofessional, it's confusing for new users. It's time for a cleanup.

IronGiant. Iron what?

The IronGiant site of user-contributed templates is a great place for new users to start, but the name is way too cryptic. I'd change it for a more descriptive title, and make the templates available at the site-creation stage.

Prioritise the wishes, build a new roadmap

Now that half the world is using Wikidot for their collaborative websites, and we've got a steady stream of income, it's time to prioritise the current wishes and build a roadmap for where we go from here.

Wikidot is a truly fantastic platform. These changes might help make the rest of the world realise that.

Enjoy the article? Tweet it!

tags — dreaming wikidot

Discussion - 10 comments

tsangk avatar

Anonymoustsangk 09 Apr 2012 09:04

Agreed. I'm still mixed on the issue of placing user-definable raw HTML into pages. The way Wikidot works at the moment (with its AJAX interface) makes it vulnerable whenever it comes to raw HTML in the *.wikidot.com and any custom domains. It puts Wikidot in a hard position, to judge if the code is a security threat.
I could easily create a service… let's say a JS powered plugin for a "like" function. An embed code could be <script type="text/javascript" src="http://wdlike.com/embedjs?site=www&page=start"></script> (this is all fictional, btw). Wikidot could go to the site to see if it's legit at that present moment. Once the plugin gets approved, I could easily change it into some rouge code which changes the user's email address and passwords and make it post dozens of spam posts on any forum on any Wikidot site.
I do think that Twitter, Google and Facebook can be trusted. But it does put Wikidot in a tough position when "approving" plugins.


bcammo avatar

Anonymousbcammo 09 Apr 2012 11:07

It puts Wikidot in a hard position, to judge if the code is a security threat.

I totally agree. One solution I thought of was that for user-created scripts, or scripts from a dubious source, you could stipulate that the script had to be included in the plugin source. Consequently the script couldn't be updated without having to go through the review process again.


tsangk avatar

Anonymoustsangk 09 Apr 2012 11:11

Ah, yes, but that would basically prevent dynamically changing scripts.


EricT avatar

AnonymousEricT 22 May 2012 16:02

You've pretty much listed all my thoughts.


etnolinguistica avatar

Anonymousetnolinguistica 25 May 2012 04:08

Great ideas, Bryce!


EricT avatar

AnonymousEricT 25 May 2012 14:28

I actually would add one thing. A big turn off to peers that have approached me about whether I would recommend that they start a site with wikidot, is the way membership is handled.

Discussing this with them, I've had to explain how I have to spend a lot of time on building a SEPARATE newsletter, in the hopes of having a list of interested subscribers that I can get in touch with and remind them about site goings-on, etc. So, I get asked, why don't you just use your membership list as a newsletter list, like most other sites, and have them opt in or out of getting email updates, etc.?

Well, I can't do that because MY members are not really my members, they are wikidot's. I don't have access to their emails nor can I send them anything besides a private message, which, I can tell you, does not take the place of being able to email your members.

If I could change one other thing, it would be this big pet peeve of mine. Most all of the people who join my site are joining my site, period. They are not joining wikidot, per se. Yet wikidot takes "ownership" of my members, so to speak. This bothers me. I don't mind sharing the spoils with wikidot and I would hope that a lot of those users who join my site go on to start their own sites, etc. But I am the one that attracted them. I am the one who worked hard to get them, yet so many of them are inactive. I become active again on sites all the time because they drop me an email to remind me. Having access to your own membership list is a big part of having a successful site, and I should not have to ask people to sign up three different ways, i.e. site, newsletter, and/or facebook.


bcammo avatar

Anonymousbcammo 26 May 2012 12:26

It's a good point that you raise, Eric. I guess not having direct access to our member's is another trade off we make for all of Wikidot's benefits. I would love the ability to actually email all of my members from time to time - sending a Wikidot PM 'newsletter' just doesn't seem right.


RobElliott avatar

AnonymousRobElliott 26 May 2012 13:04

I have some sympathy with Eric here. Due to the lack of access to a member's email address, what we do for company intranets and have done for a couple of public sites, strathpeffervillage.org.uk for example, is to make sure that all prospective members contact us and we set up an email account for them on the domain we are using for the site (which is always a custom domain) and we use that email account for all site-related communications. They use that email account to create their account on Wikidot, or we create the account for them if they prefer.

So for example we have ku.gro.egallivreffephtarts|ravgiarc#ku.gro.egallivreffephtarts|ravgiarc, ku.gro.egallivreffephtarts|slloccm#ku.gro.egallivreffephtarts|slloccm, ku.gro.egallivreffephtarts|letoh.dnalhgih#ku.gro.egallivreffephtarts|letoh.dnalhgih and so on - there are about 60 of them on that site. We help members to add these accounts to their Outlook or Outlook Express, and there is a page on the site with a login directly to the webmail account on 1&1 (our host) if they prefer to use webmail.

This is not an ideal solution and would not work for all site admins. Also, some people do not like having 2 email accounts, although for some people (smaller businesses in the village usually) it gives them an email account for the first time. Perhaps surprisingly there are still people without even a basic business email!

But this method gets over the problem of not having access to members' email addresses and allows us to then issue newsletters, attach documents and notify members of important site update info without resorting to PMs.


EricT avatar

AnonymousEricT 26 May 2012 17:59

Bryce, I think that the trade-off is there yes, but you know, I pay for a "service" and as a customer, I am not looking for trade-offs, but for my needs to be met. Heck, I'd pay more if I could get what I needed, rather than to have to make trade-offs based on advantageous that, while they do exist, don't really make me feel any better when I am having to juggle so many things at once.

At the same time, many of those benefits are lost on the average person with little technical ability but the wish to start a site in his or her niche. In other words the tradeoff is between "advanced" abilities and basic function, like the ability to communicate with your members.

Rob, I don't think that would work but for a very few people..honestly, I didn't even understand any of it and my typical user certainly would not do any of that. I mean, it sound brilliant but hopelessly complicated for sites like mine. These are people who are being asked to sign up for a strength training forum and they have hundreds of other choices. Meanwhile, some of those other forums are sending them emails while they are forgetting all about having signed up for my site once upon a time on the spur of the moment!

The thing is, I would settle for the ability to email my members but not actually having physical access to their email addresses. In other words, if the existing newsletter sent out emails, instead of just PM's to members who "opted in" I would be happy.

By the way, Bryce, your comment counts aren't updating correctly on your main page.


Anonymous avatar

AnonymousAnonymous 16 Oct 2014 06:57


Add a new comment

Site design © BMC WebDesign, 2011. All rights reserved. All tutorials on this site are free for commerical use, subject to conditions outlined in the disclaimer.