As a Wikidot.com site builder you have snippets, themes, packages, and pre-built applications. A lot of choice, perhaps too much. Are you confused? Then allow me to explain a vision for making this simpler and more consistent.
Take a look at the new Wikidot Calendar application, built by a bunch of Wikidot black belt users with way too much imagination. As James Kanjo reports: "We've made some AMAZING progress with the calendar, again!".
The Calendar app is amazing and suggests that Wikidot needs something like an AppStore (more on that another time). It also proves that advanced Wikidot users are working really hard to make applications for other less experienced users.
But it raises two clear and severe problems. One, how do people install such an app, and two: how do they get updates? Currently, installing this app requires manual copying of pages and site reconfiguration. I've tried that, and it is enough of a barrier to put me off. Kenneth Tsang wrote a neat package installer that automates this for the packages wiki but it is still complex to use.
So the scenario is this1:
- We have an application that consists of one or more pages written by some expert. Let's simplify and say that we have either a single page, or a single category and everything it contains.
- We want to be able to install that app into a site with one click. That includes copying pages and configuring permissions, auto-numbering, and so on.
- We want to automatically get updates to the app when the expert releases a new version.
Sounds perfect, right? But how can we do this?
OK, so part of my job is to answer difficult questions like this. My approach is to cheat and ask you (the user) to help. If you followed the work we did on ListPages, you will have seen that we designed this mostly in 'user space', i.e. in the design section of this blog (with 159 comments). Last week I presented that new ListPages design to our dev team, and we literally sat down and coded most of it in an evening.2
So I've written a design proposal for an expanded Clone module that does the "install" part, and a system of cross-site includes that does the "automatic update" part.
How would this work for the Calendar app? The simplest way is to use the new Clone module to re-copy the calendar: category into a site, overwriting any existing pages in that category. A better structured Calendar app would instead use cross-site includes for all content, leaving only a framework of 'include' statements to be cloned into the target site. These would never change (hopefully!) but if any of the included pages change, all sites that include them get updated automatically by Wikidot.
We've started a site for cross-site includes and the first app on that site is the scrollbar.
So over time we'll need just two mechanisms for reusing building blocks: cloning, and CSIs.
What do you think of this vision? Are we missing something?
As a user, It would be nice to have apps (or whatever they are to be called) with post-installation settings that I can configure. Like if I want to change the color of a calendar element or the number of blog items per page. Something like
[[include outsideSiteName settings=mySettings]]
where mySettings is a page in my own site that has, you know, a list of some settings, which I could reuse wherever I included this building block… If that makes sense.
Also, putting all these building blocks in one place would be cool. It's kind of confusing. When did templates become apps?
Yes, the idea is to allow configuring of cross-site includes by passing arguments.
"Application" is a bit overloaded too and we'll see if it works. I admit to abusing that term already, using it for includes and for site templates.
If you have suggestions for clearer terminology, they'll be welcome. Perhaps we should kill the packages wiki and reuse 'packages' for cross-site includes.
Portfolio
I think cross-site includes will be a fantastic feature in its own right.
How will it work?
[[include http://blog.wikidot.com/blog:building-blocks]] ?
Wayne Eddy
Melbourne, Australia
LGAM Knowledge Base
Contact via Google+
The design for it can be seen here.
@ Pieter, the only thing would be that cloning a category doesn't clone CSS for that category. But as you suggested, a CSS module would resolve that issue entirely.
Yes. It solves the problem of how to package custom CSS together with custom code, without any admin changes to a site. For example the scrollbar now requires custom CSS and won't work with pre-existing themes. The CSS module fixes that.
Portfolio
This is not just progress for progress' sake, it's progress that cement's Wikidot's position as a powerful tool that computer-illiterate people can use and understand.
It's already at that point, but CSIs, cloning, and CSS modules will completely change that and make it so much better.
I don't remember signing up for Wikidot, it was so long ago, but I'm glad I did.
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
Glad you like this stuff. :-) I want Wikidot to be the … shudder… Visual Basic of Wikis: a tool that lets us build apps for others, on a huge scale and very cheaply, and without programming skills. This seems the best way to get a Billion Happy Users.
Obviously that means making things most people cannot every understand or use, but this is fine so long as there can be clean separation between levels of difficulty.
Portfolio