[pmwiki-users] FCKeditor?

[Joachim Durchholz]

Patrick R. Michaud schrieb:
> On Mon, Nov 21, 2005 at 10:12:18PM +0100, Joachim Durchholz wrote:
> 
>>Patrick R. Michaud schrieb:
>>
>>>On Mon, Nov 21, 2005 at 06:57:15PM +0100, Joachim Durchholz wrote:
>>>
>>>>Since things like FCKEditor have paved the way, I think it's entirely 
>>>>sensible to set up a Wiki like this:
>>>>* use HTML as markup
>>>>* do some fairly rigorous filtering
>>>>to prevent the Bad Boys from inserting malware
>>>>* use a WYSIWYG editor so end users don't have to bother
>>>>with HTML syntax.
>>>
>>>If the above list were sufficient, then FrontPage (or
>>>something like it) would've become a widespread and standard
>>>editing tool long ago.  Since that hasn't happened, and lots
>>>of people have claimed for many years that this is what
>>>should happen, I'm guessing there are some inherent issues
>>>with this approach that have yet to be solved.
>>
>>Um, sure.
>>Frontpage isn't installed on every system. Plus it isn't collaborative 
>>(at least not in a useful way).
> 
> Right, but part of my thinking is that collaboration
> implies cross-platform compatibility,

Agreed.

 > and this is where
> we run into real problems with WYSIWYG.

OK, I see where the misunderstanding arose.
With WYSIWYG, I don't mean pixel-for-pixel compatibility - that's indeed 
impossible, and not even desirable.
I was thinking more along the lines of "click-and-drag over a text area, 
then mark it as link, get asked about the link parameters". Or 
"right-click a link, get a context menu where you can set parameters". 
And (here's the actualy WYSIWYG part) see any changes immediately, 
without another browser-server interaction (and never mind if it looks 
slightly differently on a Mac, it's enough to show how it looks on *my* 
browser).

 >  Add "customizable"
> to the list and it's almost impossible.

Probably. It seems that the current JS editors aren't built for this 
kind of flexibility.
OTOH it's just a matter of time until somebody picks up that ball. I had 
been thinking that it's entirely impossible to write a JS-based editor 
in the first place; now that JS editors have been demonstrated, somebody 
with the right mindset and skills should build a customisable JS editor. 
It may take months until the project starts, and years until it's 
usable, but it will happen in our lifetime, I think :-)

>>>Essentially I think the problem is that it's too difficult
>>>to create highly customizable WYSIWYG editors that will function
>>>properly across independent browsers.
>>
>>Possibly.
>>
>>The FCKEdit people have done something quite impressive though.
> 
> Oh, I agree it's very impressive what FCKEdit has done, nor do I
> mean to discount their work.  FCKEdit simply chooses WYSIWYG and
> HTML editing as its primary goals; PmWiki's goals are different.

Indeed.

It might still be possible to build a wiki based on any of the JS 
editors. As a first approximation, you just need to tack on a versioned 
and mergable back-end repository. Second would be a way to represent 
HTML differences to somebody who doesn't know HTML - a real challenge, 
that one, but various useful approximations are conceivable. Finally, 
all the other paraphernalia of a real wiki - topic groups, user 
authentication, etc. etc.

Seems like such a project would be big but entirely within the reach of 
current-day JS editors.

>>>>I'm not sure what place current-day wikis would have in such a scenario. 
>>>>I fear it's an adapt-or-perish situation though - simple wiki markup is 
>>>>never enough (as witnessed by the feature bloat that all wikis have 
>>>>succumbed to, sooner or later), so they all have a syntax that must be 
>>>>*learned*, and a WYSIWYG editor lets people discover instead of learn 
>>>>(and relieves them of syntactic subtleties).
> 
> I should've also pointed out that there are many times when WYSIWYG
> isn't enough; that eventually authors get to a point where they
> need to go beyond whatever limited feature set the WYSIWYG editor
> is providing and muck with the structure.  And doing that also 
> requires a (less forgiving) syntax that must be learned.

Agreed. Though I think a JS editor can be made powerful enough to cover 
99% of everything that's needed.
Heck, people work with MS Word and live with its limitations...

>>However, I've been thinking about the way PmWiki has been evolving. One 
>>of its main goals was (and, probably, still is) ease of use.
>>PmWiki is admirable in this respect, yet whenever I feel like 
>>recommending it to a newbie who's doing his first collaborative project 
>>in the WWW, I find myself hesitating... and wondering whether s/he will 
>>be able to learn all that PmWiki syntax. And, more importantly, how many 
>>visitors can use it.
> 
> I think the point is that an author doesn't have to learn "all that
> PmWiki syntax".  To use every possible feature, yes, but for basic 
> "I want to add or edit a page's contents" it's still pretty
> straightforward.

It's an environment that makes one feel insecure.
You edit a page, you hit a markup you don't understand. What do you do? 
It's difficult to find the corresponding documentation - how do you 
search for "a link with a + in it" in the docs?
It might be a good idea to have some way to show links from all the 
features used in a wikitext to the pages that document these features. 
I.e. make the ?action=source display show links to the corresponding 
documentation.
Plus a new parameter for Markup(). One that gives the link to the 
documentation page, so that PmWiki can generate the links.

>>Well, I usually end up recommending PmWiki anyway - it's still the 
>>leanest generally usable wiki that I know. And I haven't had any 
>>reclamations yet - all who got a recommendation are happy with PmWiki. 
>>PmWiki must be doing something right.
> 
> I'm *very* glad to hear this!  Thanks.  :-)

You're welcome. Despite my occasional misgivings and ramblings, PmWiki 
still has the best software structure of those wikis that I have seen.

I just prefer to sound the alarm *before* PmWiki has finally become too 
unwieldy for the uninitiated.

>>A recent example was the [ link | + ] syntax. My instinctive reaction 
>>was "dear, yet another piece of syntax I have to learn". 
> 
> But in this case you really don't *have* to learn it.  As an author
> you can still create page links the same way as before, and if you
> encountered a [[target|+]] that was written by another author, you'd
> recognize it as being a link to "target" in the same way that 
> [[target|text]] is a link to target.

Sure. But I wouldn't know what that + does. I'd have to find the 
documentation for that syntax.

>>It may be  consistent ... but it certainly isn't intuitive. 
>>I'm pretty sure that newbies will find a lot of other things unintuitive.
> 
> Given that PmWiki is used for a wide variety of applications, and
> with authors and administrators coming from a wide variety of backgrounds,
> I think it's fairly obvious that there will always be some features
> that will not be instantly obvious (i.e., "intuitive") to some
> groups of authors.  I mean, I know lots of people who simply cannot
> fathom the possibility of shared authorship.

Well, shared authorship is a central property of any wiki, so this 
particular example doesn't show the problem.

But I agree there are many things that are needed by just 10% of the 
audience - unfortunately, almost every user needs at least one of those 
10% features.
I don't have a good solution for that. Except adding "discoverability". 
(Stuff like automatically linking to documentation for every feature 
that the user has. "Context-sensitive help" if you will.)

> PmWiki follows more along the lines of "simple things should be simple,
> and complex things should be possible".  It does not mean that all
> complex things can be intuitive, however.

Agreed.

WYSIWYG is probably the wrong term anyway. More something like "direct 
interaction". E.g. "a wiki page consists of objects that can be 
manipulated".
In an ideal world, there would be no need to call up an edit page. The 
wiki page would present itself as a piece of editable text, all relevant 
manipulations would be directly available via a context menu, any 
changes would be visible immediately. (Now I'm still wondering why the 
W3C doesn't define context menus as part of CSS. It would be immensely 
useful: right-click any item in the browser, and you see immediately 
what functionality the site offers for that element. Add a way to update 
just a part of the HTML page, without going through JS, and we have 
eliminated all the problems except network delays. Ah well, I'm just 
dreaming...)

> And although this last point wasn't directed at WYSIWYG, I would
> comment that there are often areas in which WYSIWYG editors are 
> unintuitive also.  I still haven't figured out how to make sections
> and headings work properly in Microsoft Word, so I never use them.
> Whenever I try to use sections, or encounter a document where someone
> else has used them, the changes I make end up reformatting the text
> in mysterious and unexpected ways.

Agreed.

Though that's just Word, not a problem of WYSIWYG in general.

>>Personally, I don't like the trend towards WYSIWYG editors. But I don't 
>>think avoiding them is a long-term options - it's more a question of 
>>"which technology", "when", and "what needs to be done WYSIWYG and what 
>>should remain 'scripted'".
> 
> I think avoiding WYSIWYG is a viable long-term option; I think
> the power that can be gained by a simplified markup approach is
> such that it'll remain viable for some time to come.  For at least
> as long as people think of Word as being the sine-qua-non of WYSIWYG
> editing, specialized markup languages will have their place because
> they're more effective content authoring tools.

Agreed with that :-)

I just don't think that Word is the best what a WYSIWYG editor can do.
Actually its WYSIWYG model is unsuitable for editing online content. 
Word builds heavily on the assumption of a fixed page width and height. 
Browsers have a different idea of "fixed page width", and no defined 
page height at all.

However, Word's way of handling rich text isn't the worst in the world. 
Cut&paste, the concept of a selection on which to apply operations, 
template-based formatting - that's just a small part of what can make 
editing easier. More importantly, it's something that almost every 
computer-literate person knows how to use without looking in the 
documentation.

Regards,
Jo