15 May
2009
15 May
'09
11:23 a.m.
Hi Niels,
thanks for your feedback.
On Fri, May 15, 2009 at 12:03 AM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
On Thu, May 14, 2009 at 2:01 AM, Marius Dumitru Florea
<
mariusdumitru.florea(a)xwiki.com> wrote:
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
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) 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
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/