On 1/14/08, Erik Moeller erik@wikimedia.org wrote:
if we need 80%+ of support for everything, how can we ever hope to make changes to the fundamentals, like getting rid of wiki syntax in favor of rich text editing, or implementing a better discussion system?
Interesting thought. People talk a lot about a "rich text editing" interface, one that would permit a page to be edited by manipulating shapes on the screen or whatever. I assumed that the interface would then produce matching wiki-text, and then save it as if it had been created "the normal way".
I wasn't aware that anybody envisioned this to be a departure from the existing wiki syntax, which in most situations is much more concise than the rendered html (that which gets sent to the browser when reading the page).
If "getting rid of wiki syntax" means that users/browsers/clients who are unable to use (or do not wish to use) the rich text editor must edit the raw html, it sounds like a bad idea. Granted, maybe you had some other intermediate "proto-markup" in mind, but until I see it I shall have to assume it would only create a needless learning curve with little actual benefit.
One (tangentially related and obviously optional) feature I think would be cool, regardless of whether "rich text editing" is enabled, is a browser plug-in for parsing wiki-text on the client side[1], just as it would for html, except with significantly faster page-loads for users who connect through dial-up or... well... nevermind... ;)
As for the discussion system problem, yes it does seem silly to commit to the database several hundred Kb of wikitext when a user edits WP:AN/I to add a one-line comment (or even just to fix their own typo in a previous edit).
So maybe some forum-like software could be added, but then the garden-variety user might lose the ability to remove blatant trolling from an otherwise sober discussion, and have to wait for assistance from above. So maybe we solve that by designating moderators... more access-level creep... which as we have recently been reminded by the rollback fiasco, would require additional RFA-style voting creep... and maybe we'll want to solve that by handling all "votings" like the board of trustees elections (secret ballots tabulated in some smoky room toward the back)... thereby adding more feature creep to make the voting creep less visible, and to help reduce discussion creep[2]!
Maybe we don't want all that. Maybe it's comforting that discussion and collaborative editing can occur in the same place at the same time.[3]
If user convenience is the primary concern, perhaps a decent compromise would be a less intrusive feature, one which adds a "reply" link next to each signed comment. User submits comment via an initially blank form. Software decides where to insert it and how deeply to indent it. Simple as that[4]. And if it somehow ends up in the wrong place, there will (thankfully) still be an "edit" button up at the top! :)
It is a wiki, after all.
Anybody who's ever had to sift through eleventy-three dozen flavors of stationery in search of a blank sheet would probably agree that general-purpose software has its advantages.
So, Erik, to make a long reply short, extra features like the ones you're talking about need not require 80% support or even 1%, as long as they are optional and fairly self-contained. Of course then people will be at each other's throats debating whether or not something should be "enabled" or "disabled" by default.
—C.W.
[1] "content-type: x-mediawiki" or whatever. [2] And whole-lotta-mostly-redundant-revisions-in-the-database creep, of course ;) [3] The implications of this might not be obvious on the first read. I would try to explain but i'm not sure it's needed. To anticipate every possible type of confused reply is logorrheaic and futile, nevermind that I'll probably be lucky to get any reply at all. [4] Though I'm not aware of one, may be a javascript hack that does this. To take credit for the ideas of others is not my intention.