[pmwiki-users] Pre-alpha rich text WYSIWTF editor

Randy Brown alongkiss at aprivatespot.com
Tue Mar 29 18:23:09 CDT 2011

On Mar 29, 2011, at 4:42 PM, Ashish Myles wrote:

> Has anyone played with such a
> plugin-based text editor or GUI editor or IDE and could provide any
> insights?

While I haven't tried WYSIWYG editing, my experiments with section editing have led me to some observations and conclusions that may be helpful for any WYSIWYG project:

1. Section editing becomes important when offering WYSIWYG, unless you want to outlaw most markup on pages. Sections allow author-friendly pages to also have all sorts of unfriendly markup, by keeping the two separate.

2. Defining what sections should be hidden, versus what should be edited and how it should be edited is most flexibly done on the page itself rather than hardcoded into the editor. 

3. The more users have to look at unnecessarily, especially if it's hard to understand, the less they'll want to look. That's the problem with markup, but it's also a problem with long WYSIWYG pages. Sometimes you want to see only the section you want to change, and sometimes you want to see all the sections so each is in context. So I think the best thing is to let the author determine which sections appear on the edit form.

4. Another reason to allow author control is that offering something for editing that isn't intended for editing creates the risk of the next author changing it inadvertently. If it's really supposed to be editable, the first author can make it editable. (Of course everything is editable with the normal PmWiki editor - I'm just referring to the WYSIWYG editor.)

5. By specifying on the page the section's appropriate editor, or indicating that it's not to be shown, or that it's to be shown dimmed, tools and help can be made context sensitive and appropriate for the content. In my previous email I suggested a page text variable for each editable section to control this, but there may be other ways.

6. Users need to be able to edit anything that appears on the page, including text in anchored sections, page text variables, and page variables such as the page's title. 

7. There are several modes of editing to take into account:

a) Whole page / markup oriented
b) Whole page WYSIWYG (which is what WTF currently does)
c) Single section editing (which could be either WYSIWYG or markup oriented)
d) Multiple section editing where more than one section is visible to the end user at the same time.

8. I think it's ideal if the edit forms for each type of editing can be configured to provide links to the other types, so for example the edit link could default to one type of editing, but contain links to reload the page using the other types of editing. Also, by allowing the URL to control the section and type of editing, authors can do things like put on a page one link for whole page editing and another for editing just the categories.

Final observation: When section editing, the worst problem seemed to me edit conflicts. Edit conflicts force the user into normal editing mode, or to abandon the changes, because you don't know where the conflict is without seeing everything. 


More information about the pmwiki-users mailing list