On 1/14/08, Erik Moeller <erik(a)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.