[pmwiki-users] wysiwyg editor for wiki

[Pico]

Chris Cox wrote:
> Pico wrote:
> ...
>> So, to make sure that I am clear here, I am not talking about some holy grail of
>> WikiWYSIWYG.  The goal is much more modest.  I called it WYGWNSY ("what you get
>> will not surprise you") in PITS/00773 before I knew about WYSIWYM, but whatever
>> we call it, I think it would be a huge first step (and I think that for many
>> people who are thinking about WYSISYG, that first step might be enough).
> 
[snip]
> 
> Perhaps what is needed is a recipe for wysiwyg enclosures.
> Then you're not creating wiki markup, but rather creating
> direct html that is embedded with some meta information (or
> simply a rich content with a well defined HTML presentation)
> that exists outside of the css and style structure of
> PmWiki.... think embedded frame.
> 
> That's probably doable and doesn't defeat the feature set
> of PmWiki... just handles a blob with it's own set of
> language and rules (e.g. HTML) and makes it embeddable
> and has some non-pmwiki way to make edits.

Yes!  I think we are getting somewhere.  Let me take a step back and 
make some space for this: I will concede the way we currently enter and 
engage with out PmWiki markup does not need to be changed, because it 
works for us, and it works very well.

If I understand you correctly, the idea would be to provide an editing 
interface that allows an author to add and edit text without being 
exposed to all of the underlying PmWiki markup.  Because the underlying 
PmWiki markup continues to exist as the definitive expression of the 
author's instructions to be interpreted by PmWiki in rendering pages for 
readers, it is not threatened or diminished with we provide authors who 
are more proficient in words than code with an additional editing layer 
that allows them to squint and focus on what they need to work on: text 
and context, phrasing and spacing, emphasis and asides.

I keep thinking back to the differences among ordinary text editors and 
word processors.  In particular, I'm thinking of the options that 
WordPerfect has always provided to authors in balancing between final 
text and underlying code, allowing writers to move in close to reveal 
the underlying formatting codes and step back in progressive increments, 
by hiding the code, showing and then hiding symbolic representations of 
select code (hard returns, tabs, comments), and continuing to step back 
further through draft and page modes to a final print preview.  I do not 
mean to say that PmWiki needs to provide authors with so many layers and 
increments, but it would be nice to have one more editing layer that 
can allow authors to shift their focus away from the underlying source 
of instructions to PmWiki to view the basic forms and structures that 
begin to emerge from those instructions, as well as the essential shapes 
and texture that emerge when a layer of "skin" is applied to suggest 
tones and highlights, even if they are only models and approximations of 
the final results.

Here is something that I recently stumbled across that totally 
challenged my assumptions and views about interacting with web content: 
direct manipulation of rendered html (using javascript and css) 
http://tool-man.org/examples/index.html

The working examples provided on that site include:
draggable layers
drag and drop sorting of lists and toolbars
editing in place that follows the axiom Alan Cooper calls "allow input 
wherever you have output".

If you have never seen these, you have to just go there and try it.  It 
is really an amazing thing to experience.  I am not saying that we could 
just take that and turn it into a recipe to provide a killer editing 
layer.  But it may provide some exciting inspiration to do more than we are.

Pico