24 Oct
2008
24 Oct
'08
1:16 p.m.
Hi,
In the current implementation of the WYSIWYG editor, when adding content,
pressing the return key creates a new paragraph (<p></p>) and pressing
shift-return creates a new line (<br>).
In the wiki editor, the following behavior was discussed and implemented (
http://www.mail-archive.com/devs@xwiki.org/msg04436.html ) :
*>> So typing a new line in the wiki editor will result in a br tag in the
> corresponding HTML? And two consecutive new lines
in wiki editor will
> result in a new paragraph?
>
> yep exactly.*
After talking with our project managers and gathering their feedback from
the way customers use our tool, I think that implementing a similar behavior
in the WYSIWYG editor would be more intuitive for users :
- Pressing return once generates a new line - <br>
- Pressing return twice generates a new paragraph - <p></p>
In order for this behavior to be transparent for the user, the CSS setting
the height of blank space between 2 paragraphs should set it a one line's
height.
In order to respect user intentions on the screen, we would also need to
handle the case where the user inputs, say, 4 return keypresses in a row. We
could handle it by inputting <br> tags and having the last tag be a
paragraph :
<p> Some text </p>
<br>
<br>
<br>
<p> some other text </p>
Another option would be to go the way of recent editors such as Google Docs
and ditch <p> in favor of <br> tags only.
So there are 3 options:
1. Keep the current implementation (*pros:* it's working this way
already, *cons:* it's not what our project managers say our users expect)
2. Use 1 return keypress for <br> and 2 return keypresses for <p> (*pros:
* it's more intuitive for users, it keeps the semantic meaning of <p>, *
cons:* it takes time to implement and we're already lacking time)
3. Input <br> only everywhere, all the time (*pros:* that's what modern
editors do, *cons:* additional work, we lose the semantic meaning of <p>)
I'm +1 for option 2.
Guillaume
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://blog.xwiki.com/
25 Oct
25 Oct
9:39 a.m.
Guillaume Lerouge wrote:
Hi,
In the current implementation of the WYSIWYG editor, when adding content,
pressing the return key creates a new paragraph (<p></p>) and pressing
shift-return creates a new line (<br>).
In the wiki editor, the following behavior was discussed and implemented (
http://www.mail-archive.com/devs@xwiki.org/msg04436.html ) :
*>> So typing a new line in the wiki editor will result in a br tag in the
+0 for option 1.
+1 for option 2.
-1 for option 3.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
> corresponding HTML? And two consecutive new
lines in wiki editor will
> result in a new paragraph?
>
> yep exactly.*
After talking with our project managers and gathering their feedback from
the way customers use our tool, I think that implementing a similar behavior
in the WYSIWYG editor would be more intuitive for users :
- Pressing return once generates a new line - <br>
- Pressing return twice generates a new paragraph - <p></p>
In order for this behavior to be transparent for the user, the CSS setting
the height of blank space between 2 paragraphs should set it a one line's
height.
In order to respect user intentions on the screen, we would also need to
handle the case where the user inputs, say, 4 return keypresses in a row. We
could handle it by inputting <br> tags and having the last tag be a
paragraph :
<p> Some text </p>
<br>
<br>
<br>
<p> some other text </p>
Another option would be to go the way of recent editors such as Google Docs
and ditch <p> in favor of <br> tags only.
So there are 3 options:
1. Keep the current implementation (*pros:* it's working this way
already, *cons:* it's not what our project managers say our users expect)
2. Use 1 return keypress for <br> and 2 return keypresses for <p> (*pros:
* it's more intuitive for users, it keeps the semantic meaning of <p>, *
cons:* it takes time to implement and we're already lacking time)
3. Input <br> only everywhere, all the time (*pros:* that's what modern
editors do, *cons:* additional work, we lose the semantic meaning of <p>)
I'm +1 for option 2.
26 Oct
26 Oct
1:28 a.m.
New subject: [xwiki-devs] [Proposal] New Line behavior in the new WYSIWYG editor
On Fri, Oct 24, 2008 at 4:16 AM, Guillaume Lerouge <guillaume(a)xwiki.com>wrote;wrote:
In the current implementation of the WYSIWYG editor,
when adding content,
pressing the return key creates a new paragraph (<p></p>) and pressing
shift-return creates a new line (<br>).
How would [[return]] affect being in the <UL> or <OL> or <DL>
environments?
Seems like those should have newline behavior that enters a new
list-element, e.g. "<LI>" or <DD> etc.
IMHO, this context-dependent [[return]] behavior is often why I've found it
useful to have some kind of indication of the "structure" or environment one
is currently in, and a dynamic menu of the possible "special subnodes" that
might be available in a given context. In a paragraph context, a dynamic
choice for <BR> vs <P> might be made more apparent in a "special
area" of
the display, in order to be more apparent to the user.
For example, http://nielsmayer.com/wwweasel/node27.html implements these:
Navigation through the document is made easier by the
use of emacs key
bindings and Motif/Mac-like key bindings. Keyboard commands for moving up
and down lines will move between different markup elements including ``in
line'' images, horizontal separators, and anchors. Context sensitive
insertion of spaces and carriage returns ensure that only legal HTML is
generated. For example, spaces are not significant in HTML documents except
within preformatted (<PRE>) elements, so extra spaces (which would not be
visible in a WWW browser) are caught and the user is advised that the spaces
will not be entered in the document.
One important feature of WYSIWYG view is the automatic generation of the
appropriate separator markups upon hitting the <return> key: for example,
if in a list (ordered, unordered, menu, etc) environment, it makes sense
that hitting return will start the next list item (especially since extra
whitespace typed into WWWeasel's WYSIWYG view are ignored). If in a
definition list, then <return> will cause toggling between entering the
definition-term or the definition-definition. Finally if in a ``generic''
environment not covered by definition lists or list environments then
<return> will start a new paragraph.
I also have found it extremely useful to be able to display both structure
and WYSIWYG information at the same time, e.g.
http://nielsmayer.com/wwweasel/node26.html ... This is especially true for
selection as it is easier to control the extent of something selected for
cut/paste; for example, if one can see the cut/paste animating over the
"structure" being selected (WWWeasel v2, unpublished, I have the
Winterp-Lisp-code for it since I wrote it...).
Additionally, providing "UI-hysteresis" to make selection or cut/paste
&&
drag/drop targets sticky-to-markup-structure is a helpful UI-aide for the
user.
--
Niels
http://nielsmayer.com
6 Dec
6 Dec
9:06 a.m.
FYI, I've discussed with Vincent about the new line behavior and we
agreed to follow option 2 (well, Vincent already did this in the
rendering module), precisely:
* 1 return key generates a br
* 2 consecutive return keys generate a paragraph
* for each consecutive return key above 2 we'll generate a div with
class wikimodel-emptyline (their purpose is to separate paragraphs).
You can follow this on http://jira.xwiki.org/jira/browse/XWIKI-2936
Thanks,
Marius
Guillaume Lerouge wrote:
Hi,
In the current implementation of the WYSIWYG editor, when adding content,
pressing the return key creates a new paragraph (<p></p>) and pressing
shift-return creates a new line (<br>).
In the wiki editor, the following behavior was discussed and implemented (
http://www.mail-archive.com/devs@xwiki.org/msg04436.html ) :
*>> So typing a new line in the wiki editor will result in a br tag in the
> corresponding HTML? And two consecutive new
lines in wiki editor will
> result in a new paragraph?
>
> yep exactly.*
After talking with our project managers and gathering their feedback from
the way customers use our tool, I think that implementing a similar behavior
in the WYSIWYG editor would be more intuitive for users :
- Pressing return once generates a new line - <br>
- Pressing return twice generates a new paragraph - <p></p>
In order for this behavior to be transparent for the user, the CSS setting
the height of blank space between 2 paragraphs should set it a one line's
height.
In order to respect user intentions on the screen, we would also need to
handle the case where the user inputs, say, 4 return keypresses in a row. We
could handle it by inputting <br> tags and having the last tag be a
paragraph :
<p> Some text </p>
<br>
<br>
<br>
<p> some other text </p>
Another option would be to go the way of recent editors such as Google Docs
and ditch <p> in favor of <br> tags only.
So there are 3 options:
1. Keep the current implementation (*pros:* it's working this way
already, *cons:* it's not what our project managers say our users expect)
2. Use 1 return keypress for <br> and 2 return keypresses for <p> (*pros:
* it's more intuitive for users, it keeps the semantic meaning of <p>, *
cons:* it takes time to implement and we're already lacking time)
3. Input <br> only everywhere, all the time (*pros:* that's what modern
editors do, *cons:* additional work, we lose the semantic meaning of <p>)
I'm +1 for option 2.
Guillaume
9:48 a.m.
New subject: [xwiki-devs] [Proposal] New Line behavior in the new WYSIWYG editor
On Dec 6, 2008, at 9:06 AM, Marius Dumitru Florea wrote:
FYI, I've discussed with Vincent about the new
line behavior and we
agreed to follow option 2 (well, Vincent already did this in the
rendering module), precisely:
* 1 return key generates a br
* 2 consecutive return keys generate a paragraph
* for each consecutive return key above 2 we'll generate a div with
class wikimodel-emptyline (their purpose is to separate paragraphs).
Actually it's not just for paragraphs but for separating any block
elements (paragraphs, lists, block macros, hr, headers, etc)/
Thanks
-Vincent
You can follow this on
http://jira.xwiki.org/jira/browse/XWIKI-2936
Thanks,
Marius
Guillaume Lerouge wrote:
> Hi,
>
> In the current implementation of the WYSIWYG editor, when adding
> content,
> pressing the return key creates a new paragraph (<p></p>) and
> pressing
> shift-return creates a new line (<br>).
>
> In the wiki editor, the following behavior was discussed and
> implemented (
> http://www.mail-archive.com/devs@xwiki.org/msg04436.html ) :
>
> *>> So typing a new line in the wiki editor will result in a br tag
> in the
>>> corresponding HTML? And two consecutive new lines in wiki editor
>>> will
>>> result in a new paragraph?
>>>
>>> yep exactly.*
>
> After talking with our project managers and gathering their
> feedback from
> the way customers use our tool, I think that implementing a similar
> behavior
> in the WYSIWYG editor would be more intuitive for users :
>
> - Pressing return once generates a new line - <br>
> - Pressing return twice generates a new paragraph - <p></p>
>
> In order for this behavior to be transparent for the user, the CSS
> setting
> the height of blank space between 2 paragraphs should set it a one
> line's
> height.
>
> In order to respect user intentions on the screen, we would also
> need to
> handle the case where the user inputs, say, 4 return keypresses in
> a row. We
> could handle it by inputting <br> tags and having the last tag be a
> paragraph :
>
> <p> Some text </p>
> <br>
> <br>
> <br>
> <p> some other text </p>
>
> Another option would be to go the way of recent editors such as
> Google Docs
> and ditch <p> in favor of <br> tags only.
>
> So there are 3 options:
>
> 1. Keep the current implementation (*pros:* it's working this way
> already, *cons:* it's not what our project managers say our users
> expect)
> 2. Use 1 return keypress for <br> and 2 return keypresses for <p>
> (*pros:
> * it's more intuitive for users, it keeps the semantic meaning of
> <p>, *
> cons:* it takes time to implement and we're already lacking time)
> 3. Input <br> only everywhere, all the time (*pros:* that's what
> modern
> editors do, *cons:* additional work, we lose the semantic meaning
> of <p>)
>
> I'm +1 for option 2.
>
> Guillaume
5859
days inactive
5902
days old
4 comments
5 participants
participants (5)
-
Guillaume Lerouge -
Marius Dumitru Florea -
Niels Mayer -
Sergiu Dumitriu -
Vincent Massol