Miserlou57 writes, "I would really love a page that can at least give us some kind of idea of what things are being worked on (a simple sentence or two) and if/when we can expect any of the new features to roll out. For example, the Rating module is apparently impending redesign… but when can I count on it being around?"
In July I wrote about our plans for the coming weeks and months. What you can see, looking at every announcement we've ever made is that they are predictions and not promises. This is the reality of a large living service.
I'm building around the current rating module and redesigning my entire site with a new (better) module would be a lot of work. Will it be released this month or next year? Information on upcoming features (new page variables, anyone?) and updates like these would be extraordinarily helpful.
The only safe rule is build your site using today's features. If you wait for feature X, you will be disappointed and delayed. The good news is that it is easy to work new features into your sites when they arrive.
What are our priorities over the next weeks and months? Here is what is certain:
- Rolling out the Iron Giant templates so that anyone can grab a clone.
- Getting data forms working (for structured wiki pages).
- Making it simpler to login and join a site (top weneed).
- Fixing numerous smaller bugs with the user interface.
- Making the architecture changes we discussed last week.
More broadly and generally:
- We want a powerful, confident community. Wikidot Inc. is not your typical web company. We inherit our philosophy from open source, where success means contributors, not clients. It is very hard to accept code contributions, because the code is complex. So, we build up the user space above the product and service with themes, packages, snippets, Iron Giant, and so on. We'll continue to create spaces for contributions. It will be messy, but fun and over time, more organized.
- We want to keep making Wikidot simpler, more consistent, easier to use. Nested modules, more consistent use of arguments, fewer more powerful tools that support a rich user space. For this, we need an open design process where everyone can provide their input. Thus, the design and wiki sections on this blog, our collective think tank.
- We want to keep making Wikidot more powerful. Data forms, meta data, API, and on and on. Wikidot will become a Wiki 2.0 programming platform where anyone with a good idea for a shared application can turn it into a living site in hours. Look at HeresMyCV.com for a brilliant example. Wikidot should do for the web what Visual Basic did for Windows 3.1.
- We want to offer paying customers more value. Clusters of wikis, managed wikidot instances, and so on. We've tried using the crippleware approach but I do not like that. The only places we will not offer functionality to free and cheap accounts is when the feature is expensive for us (like web stats, which use a lot of CPU), or dangerous (like file space on private sites, too tempting for illicit use), or takes the site out of the community.1
Conclusion: use what we have now, help us organize it better, and expect things to improve slowly but accurately. If you want to contribute, start watching the sites that interest you. You'll soon see what others are working on.
Thanks, Pieter, for explaining what are the priorities you've been working on. I understand you'd rather avoid promising things, but I have a question which may save me tons of work. I'm planning to merge two of my sites by manually incorporating one (http://tr.im/nimuendaju) into another (http://tr.im/brasil), page by page, file by file. That would make for a more powerful site; both sites are about the same subject, have essencially the same tags, etc. I'll soon launch a membership campaign and I think a unified site will be more appealing (if only I knew about categories and live templates back then…). You get my point.
So, my question is: how soon do you estimate clusters will be available? If it is soon enough (a couple of months, tops?), I could just wait and avoid all the work of migrating one site into another…
Eduardo R. Ribeiro
http://www.etnolinguistica.org
Seriously, build your site using today's features. You will get more bang for your buck.
The question of "one site or two" is easy to answer: make one site per domain, per community or workgroup. Clusters will help those who need to manage many domains, or many workgroups. In your case, you have the same target community and two sites will only confuse people1.
I know it's a real pain to merge sites. Actually, you might be lucky and catch the improved Clone module which will basically do this (clone that site into this one). But then again, it might take three months to arrive.
Probably in your case you want to review the content as you re-import it. How many pages are you going to be re-creating? Another thing that might help faster is the meta-data proposal.
Portfolio
Thanks, Pieter, for clarifying this issue for me. See, the two sites offer different services, even though they both target the same field (South American anthopological linguistics). One is a general repository of information on indigenous South American languages (http://www.etnolinguistica.org), including dissertations, journal articles, news articles, a professional directory, etc. The other (http://biblio.etnolinguistica.org) is a digital library of hard-to-find books and articles on South American languages. I created them first with Geocities, then moved to Googlepages, and then Wikidot (of course, by far the best solution, which unfortunately wasn't available when I first created the sites).
Now that I'm more familiar with Wikidot I realize that I should have unified both sites back then, so that users wouldn't have to join twice, tags and search would be unified, etc. I could keep the sites' separate look and feel with categories, etc. And that's what I want to do now, before the sites get even bigger and before I launch a campaign to have all the members of our Yahoo mailing list (numbering around 550) join the site and slowly phase out the Yahoo Group. The library site has around two hundred pages, which I'll have to migrate one by one (the most painful part, I guess, are the pdf files, which I'll have to download to my computer and then upload again). But it has to be done, and the result will be a more powerful and efficient tool for our community.
One thing that would make everyting much easier would be the possibility of mapping the subdomain biblio.etnolinguistica.org into a category of the main site, in such a way that, say, a book located at biblio.etnolinguistica.org/book1 could be automatically found at etnolinguistica.org/biblio:book1. It would work with folders (etnolinguistica.org/biblio/book1), but it doesn't seem to work with categories. Any ideas, Wikidotters?
Eduardo R. Ribeiro
http://www.etnolinguistica.org