On Tue, Dec 28, 2010 at 11:11 PM, David Gerard <dgerard(a)gmail.com> wrote:
Please discuss there ...
I'm not on Foundation-L, so I'll discuss here:
So, specification of the problem:
* We need good WYSIWYG. The government example suggests
that a simple
word-processor-like interface would be enough to give tremendous
results.
Yes.
* It needs two-way fidelity with almost all existing
wikitext.
No. As Magnus has suggested, it needs, with a high degree of
reliability, to split Wikitext into chunks that it can edit, and
chunks that it can't. And the former category should be much larger
than the latter. Even something that can't edit tables, template
transclusions, or references would still be very valuable.
* We can't throw away existing wikitext, much as
we'd love to.
Of course.
* It's going to cost money in programming the
WYSIWYG.
Probably.
* It's going to cost money in rationalising
existing wikitext so that
the most unfeasible formations can be shunted off to legacy for
chewing on.
Only if you make the assumption I questioned above.
* It's going to cost money in usability testing
and so on.
Maybe. Once we can trust it not to break existing pages, then I think
we can turn it on and will have no trouble collecting reams of
feedback. Usability testing would be useful for optimising it, but
isn't needed at the start.
I think we would get a long way with Magnus's kind of approach. Maybe
even with some server side support: the server splits the wikitext up
into pieces that it knows the client can deal with.
Steve