A few minutes ago, dennyhalim asked: "where should we post feature request? Is anything here ever considered…"
Here is the short answer: post anywhere on the Community site, the Pro site, the www.wikidot.org site or this blog, and we'll read your post, try to respond to it, and if it makes sense, log it and work on it.
Here is the longer answer. For several years, we've been bad at answering bug reports and feature requests. The top rated wishes on the Community site are:
- Page View/Edit Permissions (rating: 85 , comments: 43 )
- 1 Step Wikidot Registration (rating: 60 , comments: 27 )
- Custom New Page module (forms) (rating: 27 , comments: 26 )
- Backup with Forum, Tags and Parents (rating: 26 , comments: 14 )
They're also some of the oldest wishes, which is unfortunate evidence that we have not been listening. Well, part of the "New Wikidot" that brought you the toolbars is also a Wikidot that listens and acts. If you're a member of the Community site, you'll have seen over the last weeks that we're there. (If you're not a member of that site, why not? It is by far the best place to meet Wikidot experts.)
Secondly, we have built, and are using, a new internal issue tracker, based on Wikidot. We've logged about 200 issues in that, though we've not yet done a full sweep of all the content of the Pro and Community sites. From now on, Wikidot's design is driven by users, rather than developers.
Next, we've logged a whole lot of usability bugs: too many clicks to delete a page, no private categories, too hard to register, too hard to invite users, too hard to rename a page, too hard to manage large wikis, and so on. I'm not going to list them all here but perhaps later I will. Point is, these are a priority for us. It's not sufficient for me, as a designer and user, that something works, it has to work in the simplest and most effective manner.
Lastly, while the whole Wikidot team has their opinion and input on what and how we work, the user interface is going to be more systematically designed by those of us (mainly Lukasz and myself) who are users of Wikidot and who talk to users, rather than the developers (who are extraordinarily good, as you'll appreciate when you realize how stable wikidot.com is). This means you'll see more consistency, simpler design that does more, and I hope an overall better Wikidot experience.
I've built and operated something like 100 sites, and each time I find myself thinking, "here's a design bug", or "here's a missing function". You will have the same experience as you use Wikidot, and I encourage you to express yourself on the Community site.
Official wikidot activity on the community site has dramatically increased in recent weeks, and that's always a welcome sign for any user. One of the best things about smaller software developers is that they pay more attention to users than bigger ones do and have fewer layers between them and the user. I'm not sure wikidot qualifies as small anymore, but this is definitely the best model in my opinion.
I'm stingy, but I'm a lot less stingy with this kind of interaction in place. One of my most used Palm OS program/packages was around $100, which was about what I payed for the first Palm device I used it on (which I spent months bargain-hunting for). I didn't balk at the cost because, in addition to the unparalleled feature set, the primary developer was also the primary point of contact and was extremely accessible and responded well to user input. His methods didn't just help with immediate problems, they made the software and the database options better and more valuable over time. The methods also worked wonders with customer loyalty. It won't be long before I make additional database purchases there, probably doubling how much I've invested in his product.
Anyway, kudos on this gameplan.
Thanks for this perspective. I wrote about this closeness between users and developers in the dancing unicorns thread. It used to be one of Wikidot's charms: one pinged Michal, and a short while later, magic happened. That model broke down around a year ago, maybe even longer, because each such ping would completely muck up focus and planning.
You will find that Michal is now pretty much invisible, and this my deliberate decision. Speak to me, don't bother my devs. But we're still a small, tight team, with Michal and Piotr (the two main devs) at the heart of it, and we're intensely focussed on making Wikidot work (not just giving people what they ask for but also giving people what they don't ask for, but really need).
This is classic, in any professional software process: the clients must speak to someone who cares about the product, but is not a developer. Hopefully, that 'front-end' can respond sensibly and rapidly, leaving the back-end, the developers, to work in peace, and with focus.
We'll see, over the next six to twelve months, how well this works. If it does not work, and if we're still unable to improve the product properly, it'll be my fault.
Portfolio
One difference between wikidot and my palm developer example is the scale of the projects. The Palm project was a premium niche development and they could (and had to) manage customer relations without a wall of separation between developers and customers. I don't so much care that I'm speaking with a developer or not, but with large corporate entities, customer concerns go through the lowest paid, least powerful and often least competent people first, meaning the concerns get ignored unless you bypass normal customer service or make such a big fuss you get passed up through 30 official channels.
Wikidot has powerful people on their front line listening to and even interacting with users (not to mention using themselves — believing in your own product is important to responsiveness) right now, and that's what matters to me. Not whether the front line are developers or not, just whether the product ends up being truly responsive without customers having to become Rambo to get past a useless front line.
Does this mean that these wishes will be fulfiled at last?
If slaughterhouses had glass walls, everyone would be vegan. - Paul McCartney
Yes, it means that they will.
Portfolio
When? As a matter of fact, I am most interested in the first one… View permissions…
If slaughterhouses had glass walls, everyone would be vegan. - Paul McCartney
This isn't exactly a feature request, although if the Wikidot team can come up with any new features that assist with what I'm suggesting below, that would be fantastic.
There has been a fair bit of discussion on this forum recently about free accounts.
What I'd like to see is more discussion about making knowledge free.
I suspect that a lot of wiki owners and the Wikidot team itself are proponents of the view that knowledge should be free and that many Wikidot sites and Wikidot itself have been set up with this as a basic premise.
I'd like to see the owners of this type of site network with each other a bit more to come up with ways of; encouraging more people to contribute content to their sites, making it easier to find information on their sites, and letting people who would benefit from visiting a site know about its existence.
I think making knowledge free and reducing duplication of effort using web 2.0 technologies will eventually lead to more and more people making good decisions and that this will ultimately make the world a better place.
Regards, Wayne.
Wayne Eddy
Melbourne, Australia
LGAM Knowledge Base
Contact via Google+
Wayne, for this purpose, there's Wikipedia…. ;)
If slaughterhouses had glass walls, everyone would be vegan. - Paul McCartney
Hi, Brunhilda, you make a good point about Wikipedia, but I think there are some sorts of information of interest to only a relatively small audience that may not be suitable for wikipedia, especially if the information hasn't been published anywhere. My main site (http://lgam.wikidot.com) is a sort of Encyclopedia of Australian Local Government. Perhaps some of the info on the site could be added to Wikipedia, but I think most of it - things like which Councils use which corporate software, might struggle to live up to Wikipedia's notability rules.
Perhaps this sort of site is actually a rarity on Wikidot, but I think there must be others out there, and I suspect the site owners probably struggle with the same sort of issues that I do.
Wayne Eddy
Melbourne, Australia
LGAM Knowledge Base
Contact via Google+
Thanks for mentioning your website, this is a topic that certainly interests me :)
I can understand the points you are making here as well, and agree with them.
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server
Wayne,
Yes, I think it's fair to say that our reason for making Wikidot is to help people work together better.
There is a lot of art in how to create a living community, but not a lot of science. If you look at my site http://www.wikiturfing.com, you'll see one theoretical approach that came out of activist campaigns. It may help build successful communities.
For organizing and promoting content, there are many experts on the community forums.
Cheers
Pieter
Portfolio
Hi Wayne. I've read wikidot personnel mention social networking as a wikidot application type—which I took at the time to mean wikidot modules and structure would support social networking right here rather than having to import everything from facebook and whatever. Should they accomplish that, interwiki cooperation could become much easier as a consequence, whether it is intended or not. There should be ways of voluntarily (and flexibily) grouping wikis together for better cooperation and sharing (where modules can be used to display directly from the other site, without need of RSS for instance).