Wikidot.com status: Blue
Forecast: Fast & smooth
24h avg: 9.5Mbps, 53% load
Top needs (More...)
45 of us say "private categories in our public wikis!!"
33 of us say "customizable user groups (between member and mod)!!"
27 of us say "to set page dates to past dates or future dates!!"
24 of us say "to manage all pages (rename, delete, tag) from one place!!"
22 of us say "long forum topics split into pages!!"
18 of us say "page meta-data (parent, tags, author, etc.) in edit and backup!!"
17 of us say "an autosave option on the NewPage module!!"
Recent comments (More...)
Posts by date (More...)
Watchers
pieterh
zoobab
gerdami
Phil Chett
David Marseilles
leiger
James Kanjo
Ed Johnson
Steven Heynderickx
appliquetion
RobElliott
anjel
greentree
Colin Webster
Swordslam46
maturski radovi
yehielcater
Laurent Julien
rd123456
bravo69... and more
Just a question: because I don't need it, I'd like to know why 22 people did.
Maybe after I could change my mind and my vote. :)
To expand on why people might want to post date a blog entry, some blogs have an audience that is attuned to receiving information in certain spurts — it varies blog to blog, but some people want to/are accustomed to see(ing) fresh content every afternoon, every morning, every friday, etc, depending on how that blog functions. A blog creator wants to meet these expectations to ensure that their regulars feel well served and keep coming back, while at the same time, they don't want to be tied to posting at exactly these times.
Bloggers need flexibility for all kinds of reasons (vacations, day jobs etc), and postdating allows them to create content in advance, but release it on a schedule that meets the needs of their audience.
It lets you post-date blog entries so that they appear only at a certain date; it also lets you create older blog posts, e.g. if you are moving stuff from another site.
The Wikidot Blog | My other works
Posdating would allow confortable drafting by setting a date in the near future:
with 2 versions of ListPages
- one for drafting, i.e. not taking into account the to be published date
- one for publishing (public view)
Why double the work with two versions of ListPages? This should be able to be done with a parameter… showFuturePages="false" by default
— Shane | Blog | CycloDS Revolution | Compatibility List | Want me to manage your next wiki? | XBL: leiger40
Automatic code replacement — Rate it up!
Please, noMoreCamelCase :-)
Yes, one version of ListPages with future="yes|no" as an argument.
The Wikidot Blog | My other works
Hey fools,
please try to read between lines:
I did not mean two versions of the module, of course (I have the black belt, haven't I ?).
Sorry… Java/C++ developer here.. :)
So do I… I'll fight you — see who the real karate champion is! ;-)
— Shane | Blog | CycloDS Revolution | Compatibility List | Want me to manage your next wiki? | XBL: leiger40
Automatic code replacement — Rate it up!
The vast majority of comments I've seen on this topic, here and elsewhere, focus on setting future dates — with the exception of pieterh's above, I did read it! — so I'm going to add my two cents regarding why setting past dates is also useful:
Say you're transferring something to Wikidot, or otherwise making an archive. While you can create pages in order, assuming you have the complete set of information to begin with, created_at won't match the original date of the information, and it's fairly difficult to store the date in a way that can be accessed in a ListPages module — unless you use a live template and %%content{n}%%, which isn't actually always the most appropriate approach in all contexts, at least in my experience. And if you should happen to upload one out of order… especially if you don't notice until much later, when you'd have to delete many pages in order to fix the created_at sequence… you're out of luck.
You can't order by tags in ListPages, so the info can't be dated and organized through them, and while you can use page name/URL for dating that starts to get cumbersome if you have multiple entries for a single day. Linking back to that page later also requires looking up the URL (because what you probably remember is the descriptive phrase in the page title, or a synopsis of the page content, not the timestamp in its URL).
If you have a collaborative project, with multiple people adding information that gets spliced in together, then any one person doesn't have all of the information to begin with, so they can't just upload all the pages in correct sequence. The more abstracted and higher-resolution the page-naming system is (e.g. 'requiring year-month-day-hour' instead of 'just type the page title in the newpage box'), the less transparent it is to a group, especially if a good percentage of them are typical end-users (who can be incredibly stubborn about not learning even Wikidot syntax!) rather than technically-minded people.
I freely admit that my personal application for this feature is a 'niche' — using it for collaborative archives of roleplay logs, which are often 'creatively dated' (i.e. to yesterday or tomorrow, or even years in the past, or in rare cases in the future) and uploaded out of actual order-of-effect. It would also be useful for me in creating a code archive and setting the created_at of each program's page to the date it was first finished (which in many cases predate the wiki site, because I have several years' worth of code that would go up).
But… I could see being able to set to a past date also being very useful for organizing anything by time — if your site is about the history of some product (games, software versions and releases, postcards, etc.), or a record of events for a place or community, or anything else of that nature — and just like roleplaying, there are at least a fair minority of Wikidot sites that focus on such subjects — you can date each page with the day it happened, and then easily organize them in chronological succession; it's definitely the most intuitive and elegant way to combine that with ListPages.
That was a lovely essay!
λ James Kanjo | blog | photos | contact
Hah, thanks. ;)
Agreed. Great post!!
— Shane | Blog | CycloDS Revolution | Compatibility List | Want me to manage your next wiki? | XBL: leiger40
Automatic code replacement — Rate it up!
What is setting a past date ?
Each page of a wiki is record of a database1, with fields such as pagename, which are editable and other fields such as creation date or modified date, which are not (yet).
My weneed covered the "past" date set by the user at creation of the page (instead of being set automatically) and of course, the ability to modifiy at wish this past date, as any other meta data, which is weneed:6.
Is this idea scheduled or already being worked on, or is it still only another item on the wishlist/weneed lists? Knowing this would help me to decide how to structure a category of pages on a project of mine.
Thanks.
Sue
The idea is to create your sites for the features that currently exist, and not to rely on those that are planned or being designed.
— Shane | Blog | CycloDS Revolution | Compatibility List | Want me to manage your next wiki? | XBL: leiger40
Automatic code replacement — Rate it up!
Yes, this is always the best plan. If you wait for specific features you'll just lose opportunity.
The Wikidot Blog | My other works
weneed:11 The third most voted for weneed.
It's a fair question that I'm asking. A straight yes or no would suffice, in keeping with your usual no-bullshit style, Pieter. :-)
yes = scheduled or already being worked on
no = only another item on the wishlist/weneed lists
Please allow me to be the judge of how I act upon that information.
Sue
I understand where you're coming from Sue… I feel the same way.
λ James Kanjo | blog | photos | contact
Sue, I too think it is a fair question. And it is one I have raised before here where I suggested a simple traffic light system to give a quick status:
green: assessment and/or development is underway
amber: no assessment or development has started yet
red: assessment or development had started but has stopped for technical or other reasons.
I do think it is important, not least on the roadmap items where people are committing hard cash and should therefore be given some degree of feedback (without that the roadmap risks being just another wishlist). It does not commit Wikidot to any specific timeframe but gives the users a quick idea of what is being assessed or developed. As the weneeds and roadmap issues get longer it would also keep people like me off Pieter's back to an extent which I'm sure he would welcome.
Rats, I told myself I would have a quiet week working on my own sites and not raising contentious issues or annoying anyone, Pieter in particular. I have failed and it's only Monday lunchtime!
Yes in an ideal world that would be true. My world however seems very flawed and I have several projects underway which, if we are to use Wikidot, need private categories implemented in order for the whole site to be accepted. I am developing them v-e-r-y v-e-r-y s-l-o-w-l-y so I don't have to use TWIki instead of Wikidot.
Let me put it like this: the Wikidot development team is still too small to let me make promises I can keep. We have conflicting demands and keeping the service running fast always beats new features. And bug fixes beat new features. And support beats new features.
So what we are doing is to slowly but surely grow the team, work better, and ramp up the production of useful new code. We are about… 50% of the way there, IMO. You will see a big improvement over 6 months ago but still much to be desired.
Today, any promise or planning on new features would be a lie and I'm not going to do that. Our top priorities for major new features for now (after service and bug fixes) are:
And then more tools along the lines of ListPages.
Page metadata is something I personally really want but it is not scheduled yet. It has more or less been designed, which is already important.
I'd recommend anyone really needing a feature to spend some time looking, or demanding, designs for the feature. We've found that a well-matured design sketch lets us implement very rapidly.
The Wikidot Blog | My other works
On behalf of Pieter, I would say it's a “no, but you may get this feature done by Christmas next year” ;-)
λ James Kanjo | blog | photos | contact