Hi Niels, thanks for your feedback. On Fri, May 15, 2009 at 12:03 AM, Niels Mayer <[email protected]> wrote:

On Thu, May 14, 2009 at 2:01 AM, Marius Dumitru Florea < [email protected]> wrote:

...

For the first outcome I think we all agree that the user has to press Shift+Enter. For the second and third outcomes I see two options:

A) Enter for 2 and CTRL/META+Enter for 3 B) Enter for 3 and CTRL/META+Enter for 2 (if you see any other options please step up)

Sounds like wikimacs (wiki+emacs) :-)

What about using a multiple-repeated enters. Kind of like a keyboard equivalent of a double, triple click, with some visual way of suggesting what level "upwards" in the DOM the return will create the next element (e.g a "box insertion caret" like for drag-drop operations):

* a single enter in a list adds a paragraph or <br> within the current element. It does not create a new list or table entry.

* double-enter, creates a new <li> <tr> etc (depending on if you're in a table, list etc) within the current table/list.

* triple-enter, creates a new <li> <tr> <p> or <br> as the next element outside of the current list/table etc. (if in a nested table/list, it'll correctly add the next element)

We tried doing something similar for paragraphs (hit enter once to create next line, twice for new paragraph) and the feedback we got from users was pretty negative. It looks like the user's expectation about the enter key is that it will create a new item (new paragraph, new list item, new whatever). Thus the concept of double-enter similar to double-clicking doesn't seem to work in practice so far. Thus I think we shouldn't reintroduce it. -- Niels

http://nielsmayer.com

PS: I got to deal with all these fun issues back in ~1995 when i designed WWWeasel (reviewed at an early WWW conf here<http://nielsmayer.com/L27933-1529TMP.pdf> ) http://nielsmayer.com/wwweasel/node26.html<; http://nielsmayer.com/wwweasel/node26.html#SECTION00051000000000000000> http://nielsmayer.com/wwweasel/node27.html It is very helpful for the user to be able to see what's going on "structurally" at the same time as you're editing in WYSIWYG.... If you can graphically depict where in the DOM structure the "return" is pointing, at what level of scope, then it's a lot less confusing to the user.

The WYSIWYM concept is pretty interesting and powerful. I played around with tools such as WYMeditor http://files.wymeditor.org/wymeditor/trunk/src/examples/01-basic.html and I definitely do like the concept. However, this is not the direction we have taken so far with our new WYSIWYG editor. Changing it to make it a WYSIWYM editor on top of what it currently does would require considerable effort. Our focus right now is on eliminating quirks and bugs in all major browsers to make the editor ready for production use. Therefore I think we'll have to wait some time before even considering building a WYSIWYM editor for XWiki. However, please note that since you can store XWiki document contents as XML, you could definitely try to plug WYMeditor on top of XWiki and make it the default edition option. You'd lack the wiki-specific feature, but for content insertion you'd benefit from the WYSIWYM interface :-) Guillaume

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/