Guillaume Blanchard wrote:

• Look at the source [3] and give me a list of needed

security/performance fix.

I fixed a couple of the most obvious security problems:

* The Special:Newthread edit form provided a very nice cross-site scripting injection point. Once a user is tricked into visiting a certain URL (can be via a redirection or frame) their authentication cookies can be stolen, or nearly any authenticated action on the wiki can be performed as that user via JavaScript manipulation from the hacked form.

* The Special:Newthread form submission didn't use the edit token, allowing for cross-site request forgery to submit new threads under a victim's user account if they visit an offsite page containing a form and a little JavaScript.

Before anyone should consider deploying this in the field, there are other very significant problems with how it accepts edits:

* It doesn't check for read-only mode

* It doesn't check if the user is blocked

* It doesn't check whitelist-edit mode

* It doesn't check content against the spam blacklist or filter callback

And some general functional issues:

* The localized text doesn't fit with MediaWiki as a whole; the user's selected language is ignored, and the messages aren't customizable through the MediaWiki: interface.

* Edit comments aren't formatted in the Special:Forum list the way they are elsewhere

* Edit comments are cut off manually at a byte offset, which could break UTF-8 characters. Instead, use $wgContLang->truncate() or show the complete comment.

* The code that outputs the table on Special:Forum is very fragile. Many pieces are done with wikitext which can break when some characters are used (try for instance making a thread titled "''Spiffy''"; the link becomes broken in the list).

* The use of the unlabeled magnification icon to show/hide a chunk of in-place text is very nonintuitive. Consider using the arrows from the enhanced recent changes display.

* Obviously these don't work at all if the client has JavaScript disabled; consider not displaying the unmanipulable bits in this case.

* Whatever it looks like, a tiny icon is a tough target to click on; I constantly have the urge to click on the _title_ and assume it will expand the text, but this links to the separate page.

More generally it seems a bit confusing; at the demo site at http://test-wikipedia.saewyc.net/index.php/Special:Forum there are two entire tables of threads one after the other without an obvious reason or explanation. One has expando-bits, the other doesn't.

-- brion vibber (brion @ pobox.com)

Hi Aoineko,

let me be clear: I share your goal of improving Wikimedia's discussion systems. I think there are a number of serious usability issues with Wikiforum as it is right now, though:

1) The current two-table setup is very confusing. It is not intuitively clear why some threads have preview and some do not, nor is the preview function itself obvious from the icon. The function of the top box is not visually distinguished from the function of the bottom box in any way. I suggest combining the two boxes into one, and making the preview function clearer (an eye may be a better visual representation, additional text might also help).

2) One of the key features of forums is the ability to sort threads by their publication date. Wikiforum uses "Oldest First", and it does not appear to be possible to change that. The page is titled "50 latest threads", which creates an intuitive expectation of "Newest First". I think "Newest First" should be the default, as it is in most forums, but it would be nice to be able to sort the table by whatever criteria desirable. (The default sorting order could also be voted on after the system has been in use for a while.)

3) Being able to chronologically go beyond the 50 threads displayed on the index page ("Next 50") seems like a fairly critical feature to me.

4) The "Post a comment" ("+" in Monobook) link is missing. This is quite a serious issue, as it makes Thread: pages *more* cumbersome than talk pages, which have that link. Besides easy appending, it also encourages users to add a section title, which increases the editability of long pages.

5) There is no reason for a Thread: page to have a separate Thread talk: page - that just adds confusion.

Design-wise, Wikiforum should be ready to handle subforums on different topics, rather than just having one big forum on Special:Forum, but that feature doesn't need to exist immediately.

I do agree with the idea of trialling the system on one wiki before putting it into use on all wikis. The key question is: How will Wikiforum affect our discussion workflow? Will threads just disappear into nowhere, where previously people at least made a token effort to move threads to relevant talk pages or build structured archives? Will the Thread: namespace become a huge mess that nobody can wade through? Category: tags could potentially prevent that, and collaborative thread categorization is an interesting approach to handling discussions.

I'm therefore not saying Wikiforum will fail, but I do believe that we need to collect data about its use, and that the above usability issues should be addressed before taking it live anywhere.

Regards,

Erik