Feature Proposal: Integrate improvements from Rich Text Editor from VM in Standard (CVS)

Motivation

Improvement of the Rich-Text-Editor and the raw editor in the standard of Foswiki.

Description and Documentation

The standard editor has significant deficiencies, that have been fixed elsewhere already. How can we incorporate the work of Eugen and Michael for the standard? Is that wanted. I definitely think so.

Please see this Demo-Video for further reference:
http://screencast.com/t/HGHdb9JK

Open Issues:

• Integrate Advanced Raw-Editor from Natskin in the Standard.
• Integrate improved WYSIWYG-Editor from Eugen Mayer in Standard.

Examples

Impact

WhatDoesItAffect:

Implementation

-- Contributors: MartinSeibert - 09 May 2009

Discussion

I have reservations. I find this editor fantastic BUT we need to do some changes to make it useable in a Netbook that has 1024x600 pixles.

You only have 3-4 lines of text in the edit windows on such a computer. Even on larger but older laptops the editor has a problem with always taking space for the top and bottom bars.

In the dumb editor we have today I can set the window size to the entire screen and scroll the browser window so I only see the edit textarea.

The rich text editor does not allow you to do that. It is typical that developers use large monitors and do not think about this. But try setting a Netbook. In fact all developers should have one. Or at least install Web Developer Tools for Firefox and use the feature to set the window to specific size.

To use this editor we need a technical solution for small screens.

-- KennethLavrsen - 09 May 2009

I agree. The editor must work on small screens.

-- MartinSeibert - 09 May 2009

19:58 MartinSeibert Lavr: I have an idea for the small screens with the new rich text editor. We simply define a minimum size for the editing window. Then you will no longer have the "I only see 3 lines"-problem any more.
MartinSeibert What do you think?
MartinSeibert Lavr: That is the reality with testing. But you keep quality up.
19:59 Lavr Martin. I had THAT idea plus one more.
20:00 Lavr The other is to not have the buttons below for saving but instead adding small icons at the top bar for that
MartinSeibert Perfect.
Lavr Like we all know from Word/Excel etc
MartinSeibert We should have them on top and below. That is even better for a scrollable page.

-- MartinSeibert - 09 May 2009

Sounds sensible, but I have one reservation.

When I set nowysiwyg=1, I would expect the standard no thrills raw editor. I would not even want the smart edit. Our wiki has been around for years and is used by a lot of technical users and even the smart edit is too much for them. They want the text box and nothing else.

As long as it is configurable I am happy

-- AndrewJones - 09 May 2009

Just for your information. Here's a sceenshot of NatEditPlugin 1024x600:

Versus standard raw edit:

-- MichaelDaum - 09 May 2009

Try with Windows XP with a normal status bar at the bottom, and with IE 7 or 8 incl Google bar. Not much space left. Konquerer on Linux is not the most typical example.

And even with the above example, there are not many lines. You do not get much context while editing a large document. It is a bit like seeing the world through a kitchen roll.

But with a few small tweaks like having a minimal hight of the edit window, and replacing the bottom row with 3 or 4 extra icons at the top bar - and removing the Title field which is a Nat feature will give a significant win.

And there is also some space that can be won by optimising the tabs and Topic name header. They could be more "side by side" for example by having the tabs on the right and the topic name on the left. I even think you could get so much optimized that you do not need to define the minimum edit window size much larger than what fits in 600 height.

There are still some other issues to address.

I have some topics where I have a view template and edit template so the form is at the top so when you do normal edit you see form first. That would not work the same with this editor.

So we probably need to have this editor configurable and not just replace the old one. But it is not the editor that creates this problem. It is the tabs.

The rich text editor or Nat editor is however a significant win for the newbie as well as the experienced but still rather casual user.

And the tab feature may be considered not very desired when you also consider the proposal raised in another feature proposal of eliminating the more screen in favior of a nice menu system

I think we should consider combining the menu with adding just the editor features that this proposal requests where the naked user-unfriendly raw editor gets the small tool bar at the top.

-- KennethLavrsen - 09 May 2009

Martin, please try to get the terminology right, and avoid the temptation to propose too much in one topic. I am well aware that end users don't appreciate the fine nuances of what is WYSIWYG and what is Rich Text, but you need to be able to get it right.

Tiny MCE is a WYSIWYG editor - what you see is what you get - and is therefore the only working editor to which this topic - MergeWYSIWYGEditors - is applicable. Since Eugen's work is a plugin to the TinyMCEPlugin, I assume you are proposing making Eugen's plugin part of the standard release. While I am not against this proposal (indeed you will see it listed in the WysiwygTaskTeam's goals) Eugen and I have discussed it, and agreed to delay such an integration until there is more clarity regarding the adoption of jQuery as the standard JS toolkit in Foswiki. Eugen's extensions are heavily dependent on jQuery, and importing that toolkit is a signficant step, especially since it duplicates much of the code already in TinyMCE. To avoid duplication and confusion I have deleted the "merge Eugen's plugin" proposal above; it should be the subject of a separate feature proposal, and coordinated with the WysiwygTaskTeam.

Nat Edit is a Rich Text editor - it does not attempt to offer WYSIWYG. Other rich text editors exist, such as SmartEdit, which deserve consideration. Nat Edit is basically a toolbar that sits at the top of the standard text editor. I would like to see improvements to the standard text editor in Foswiki. WYSIWYG is total overkill for many users. Consistent with other comments herein I am nervous about available screen space for the toolbar. (To save space we have "open on demand" toolbars in http://wikiring.com that drive me nuts when editing forms, as you can't easily "click and start typing" - you have to constantly be mindful of changing screen layout when the toolbar appears). So if there is to be a toolbar, let's make it either permanent, or allocate it fixed space so it doesn't munge the layout on every field change.

-- CrawfordCurrie - 10 May 2009

Its also worth checking how the Nat Edit degrades if Javascript is not available.

-- AndrewJones - 10 May 2009

@Kenneth, try to disable your Google bar. Then make a screenshot. Please try illustrate your editor visions in a drawing/mockup. They seem to be pretty concrete.

@Andrew, Nat Edit currently heavily depends on Javascript, i.e. jQuery. There's no way to move on without. For now, it does not degrade to bare bones right now. The pressure is more on improving user experience for standard browsers.

@Crawford, there is a lengthy discussion about using jQuery in the TinyMCE communitiy. This isn't a thread we need to repeat over here as we can't do much about it. We'll surely see more non-jQuery third party components that are worth including into the Foswiki standard distribution. Sure, it adds more load to the browser having to deal with different worlds. But that's always the case if you try to integrate work from different areas. Infact being able to deal with all sorts of extra tools is one of the strengths of Foswiki: being an integration platform .

For now I am more concerned about how to get the best edit experience possible, even with WYSIWYG disabled.

The two editors already can be used in conjunction with each other. So there is actually no need to merge them. The actual desire is that they should coexist and work together flawlessly. That's already the case with some minor glitches remaining. Can't see the point of an actual merge.

The above video illustrates much more than what has been proposed here. I am very thankful for an independent user to actually point out the user experience improvements that a lot of other Foswiki project members might possibly not be aware of.

-- MichaelDaum - 11 May 2009

Added screenshot of standard raw edit as is on foswiki.org. This illustrates what has been said in the video as well: you need to scroll a lot. That's okay for reading on the web - not so for writing, IMHO.

-- MichaelDaum - 12 May 2009

Next NatEditPlugin will have a minheight parameter so that it won't shrink below a certain height. This way you will then get window scroll bars back again on small screen resolutions.

-- MichaelDaum - 28 May 2009

See AddNatEditToCore now.

-- MichaelDaum - 29 May 2012