Edits to the Perl 5 wiki have fallen off recently. Taking a page from a well run Wiki, the Wookiepedia, I've started a semi-weekly wiki topic improvement drive. Each week or so a topic will be chosen (you should suggest some) and folks will focus effort improving the pages on that topic on the wiki.
This week its POD!
Re:Announments...
schwern on 2007-09-05T06:34:47
Its on the wiki news page and perlbuzz picked it up.
Got ideas for more places I should announce it?
I haven’t been there much lately, mostly because the feed doesn’t contain one distinct item per page edit, it just contains one item for each page with the page’s full content, which gets updated when someone edits the wiki. But updates don’t get flagged in many feed readers, and mine is one of them. What this means is that except when someone creates a new page, I never get notified of anything going on.
And so I never stop by.
The insufficiently useful feed also makes it a large hassle to see what people changed, because I have to actually go to the page and use the on-wiki navigation. And the on-wiki page history feature is a bucket of suck because you can neither open many diff-to-next-version pages in tabs nor are there “show next diff” links like on Mediawiki. You have to manually select each page version and the version next to it, click the diff button, check out the changes, then hit the back button and do it all over again. For every. Single. Version. Of the page. The most basic motions of gnoming are so much tedious work on SocialText that my motivation tapers off very quickly.
And so I never stop by.
I’ve put my complaints in the feature request page and periodically peek in. So far none of them have been addressed, and thus no Improvement Drive or other social measures are going to make me more active. Sorry. I would in fact like to help more, but it’s too unfun before the software gets smoother to use.
Generally I think SocialText focuses too much on making things shiny and Javascripty, leaving ease of use as collateral damage. The hard-to-use page history feature is not the only symptom of this; the edit page input box, even when it’s not in WYSIWYG mode, is invisible to the external editor extension I use to integrate Vim with Firefox. I have quite a few more complaints along those lines, but they would all be bearable; whereas the useless feed and painful page history are not.
Re:Social measures do not fix technical problems
schwern on 2007-09-05T07:11:27
Let's take this one at a time, keeping in mind that Socialtext is now an open source project and has a plugin system and you can fix this just as well as I can. I don't actually have any access to the server, I do everything through the Kirsten Jones API.
A few things to keep in mind... Socialtext does have a REST API. You can potentially make your own interface for it. In fact, I've just been informed of miki which is a stripped down version of the Socialtext interface intended for mobile phones. I'll see if I can get it turned on.
Additionally, from talking to folks on #socialtext, it seems the designers at Socialtext have an audience in mind rather different from what we want. This can, of course, be a self-fulfilling prophesy. One way to reverse this is to start funneling Perl 5 Wiki complaints into their inbox. I'm looking about how best to do this.
On to the specifics!
I haven’t been there much lately, mostly because the feed doesn’t contain one distinct item per page edit, it just contains one item for each page with the page’s full content, which gets updated when someone edits the wiki. But updates don’t get flagged in many feed readers, and mine is one of them. What this means is that except when someone creates a new page, I never get notified of anything going on.
I've noticed this, too, using Google Reader, the per-page feed never gets updated. However, NetNewsWire does see updates. So either there's something wrong with Google Reader or something wrong with the feed that NNW is compensating for. I'm not very familiar with RSS or Atom. What feed reader do you use and what change to the feed would be necessary to fix this?
And yes, it would be nice if there was a "show me the diffs" recent changes feed. This can be done as a plugin... somehow. NetNewsWire does this on its end.
The insufficiently useful feed also makes it a large hassle to see what people changed, because I have to actually go to the page and use the on-wiki navigation. And the on-wiki page history feature is a bucket of suck because you can neither open many diff-to-next-version pages in tabs nor are there “show next diff” links like on Mediawiki. You have to manually select each page version and the version next to it, click the diff button, check out the changes, then hit the back button and do it all over again. For every. Single. Version. Of the page. The most basic motions of gnoming are so much tedious work on SocialText that my motivation tapers off very quickly.
I see what you mean. I've been told on #socialtext that this is a "feature" because it would be too confusing. Yeah, the mind boggles.
the edit page input box, even when it’s not in WYSIWYG mode, is invisible to the external editor extension I use to integrate Vim with Firefox.
That's odd. "It's All Text" picks it up fine. What add-on are you using? Its probable it doesn't have the necessary smarts to rescan the page for DOM changes (read, it don't speak the Ajax).
Re:Social measures do not fix technical problems
Aristotle on 2007-09-05T08:57:14
Socialtext is now an open source project and has a plugin system and you can fix this just as well as I can […] You can potentially make your own interface for it.
Is that what passes for “low barrier to contributions” now?
:-) Even if it is easy for me to fix these problems, I would have to learn my way around the codebase first, which also means installing it first. That adds up to an incalculable amount of up-front effort that is orders of magnitude greater than what occasional wiki gnoming takes.
And (sorry, but it’s true) I’m just not that invested. All I care to do is meddle with the stuff in the wiki, not the wiki itself. I have no plans to use Socialtext for myself, much less customise it for my own uses, so I have no incentive to hack on it.
(Note that I didn’t demand you should fix it – I was just stating why Socialtext captures less of my limited attention span and motivation than, say, Mediawiki would, based on experience with Wikipedia and other instances.)
NetNewsWire does see updates.
Well, I “see” the updates in my reader also – but I don’t get notified about them because it’s “just” a change to the same entry that I’ve already marked as read. Normally people don’t care to re-read entries just because the author has fixed a typo, so feed readers don’t highlight those changes.
So either there’s something wrong with Google Reader or something wrong with the feed that NNW is compensating for.
There’s not something technically wrong with the feed per se – NNW just offers perks that few readers implement. It saves every version of each item in the feed and diffs the versions locally. And I guess it highlights a change if it was sufficiently big. So it has so much smarts that the server can just dump a zero-effort feed in its lap and NNW makes something palatable out of it.
I’m not very familiar with RSS or Atom.
There’s not much to be familiar with. If you’ve seen the frontpage of a weblog, that’s all a newsfeed is – the markup has literally the same structure as a weblog frontpage, you just use some special tags to enclose each post and use special tags to denote which part is the title of the post and which is the permalink. So the available content is completely controlled by the server. Readers then simply poll this “page” periodically. A feed reader is just a giant collection of auto-refreshing weblog bookmarks. Any functionality beyond that is client-side tooling.
The whole feed concept barely exists. (That is, of course, the magic; the value is in just how little “stuff” there is.)
What feed reader do you use and what change to the feed would be necessary to fix this?
It doesn’t really matter what reader I use (it’s Liferea, for the record), because just about any other reader would work the same way. What would be necessary to fix this is:
- Diff the page versions on the server and put the diffs in the feed.
- Use a link to that diff as the permalink, rather than a link to the page itself.
- Use a different item ID for each version of the page so the feed reader sees them as new items, not changing known items.
Which is exactly what Mediawiki does.
Imagine generating an HTML page for the Recent Changes that doesn’t just list the edits but also includes the diff for each change. Generating the feed would take exactly the same work, except you use RSS tags instead of HTML to mark up the list.
Re:Social measures do not fix technical problems
schwern on 2007-09-06T08:37:27
I would have to learn my way around the codebase first, which also means installing it first.... I was just stating why Socialtext captures less of my limited attention span and motivation than, say, Mediawiki would
Yeah yeah. And if it was Mediawiki folks would be complaining that they'd have to touch PHP. From my experiences with Wikipedia vs a stock Mediawiki, Wikipedia does quite a bit of customization themselves. Hell, the "help" links in Mediawiki don't even work out of the box!
General whinging about contributing to a new project aside, here's what's happening. I put up our list of bugs and feature requests on the socialtext-users mailing list as well as their Great Weird Ideas page. As a result Luke Closs has put some work into a recent diffs RSS feed.Today for Wiki Wednesday, I wrote a REST client that produces a rss feed using Text::Diff. I'll set it up on cron, and test it tomorrow. If it's good, then I'll put it on CPAN, and we can start using it for the perl5 wiki. If it's really good, I'll see about integrating it with the core codebase.
So there ya go, a diff feed is on the way.Re:Social measures do not fix technical problems
Aristotle on 2007-09-06T12:18:38
Great! Thanks to Luke, and to you for making enough noise to get it to happen.
I’m not saying Mediawiki is that great either, btw.
:-) It just gets this particular thing right, whereas Socialtext doesn’t yet.
