just to tell from my experience with basic users of WYSIWYG HTML editors:
one of the first things anyone does when using a WYSIWYG editor is to try to
indent text with the TAB key as anyone does in any text editor and it
doesn't work. Result: they feel frustrated compared to OO or MSOffice. You
can try to explain that it's HTML and not Word but their first feeling is
bad and the conclusion is:"Your stuff is not good enough yet and I don't
want to spend time on that"
br
Pascal
On Sun, Dec 28, 2008 at 2:43 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Sat, Dec 27, 2008 at 8:21 PM, Anca Paula Luca
<ancapaula.luca(a)xwiki.com> wrote:
Marius Dumitru Florea wrote:
> Hi devs,
>
> We have to decide upon the proper behavior of the Tab key in the new
> WYSIWYG editor. Open Office has the following behavior:
>
> A) If the caret is inside a table cell then jump to the next one (or
> previous one with Shift).
+1
>
> B) If the caret is at the beginning of a list item then indent that item
> (or outdent with Shift). By indent I mean make it a subitem of the
> previous list item.
+1
>
> C) Otherwise insert a Tab. The Tab doesn't always have the same width;
> it depends on the top ruler and on the caret position. Shift+Tab is
ignored.
>
> I'm +1 for A) and B)
>
> Regarding C), it's difficult to have the same behavior. What we can do
is:
>
> C1) Insert spaces (say 4); we would have to use non-breaking spaces of
> course.
+0.5
>
> C2) Insert just one (breaking) space to discourage users from using the
> tab key to layout text.
-0 I'd really prefer C1) or doing nothing.
I'm +0 for C1) and +0.5 for C2).
+1 for A) and B)
-0 for C1). Imagine users could indent everything at the start of every
line
with tabs to have a paragraph indented 4 spaces
away from the left. We
definitely should not allow that.
Which makes me think about the degree of wysiwyg-ness of what we're
building
since the width of the editor is never preserved
/ guaranteed for the
view.
Indeed users should not rely on that but we need
to make sure somehow
that they
are well aware of it.
there is also :
C3) do nothing
+0
and:
C4) default browser behaviour -- move focus to next form field (which is
happening now for all situations)
-1 for this, we should not loose WYSIWYG focus. Plus even if FF jump
to next form field by default it's not the case for IE which insert a
tab character and I doubt we did anything to change this behavior yet,
do we ?
and also:
C5) if the cursor is at the beginning of a paragraph it should indent the
first
line in the paragraph (the CSS way), but I am
pretty sure that's too much
trouble.
+0 for C2)
+0.5 for C3) and C4).
Happy coding,
Anca Luca
I need your vote asap.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs