Hi, On Thu, May 14, 2009 at 1:12 PM, Vincent Massol <[email protected]> wrote:
> > On May 14, 2009, at 12:47 PM, Marius Dumitru Florea wrote: > > > Hi Vincent, > > > > Vincent Massol wrote: > >> On May 14, 2009, at 11:01 AM, Marius Dumitru Florea wrote: > >> > >>> Hi there, > >>> > >>> Right now the new WYSIWYG editor allows us to create simple lists > >>> like > >>> the following: > >>> > >>> ----------8<---------- > >>> * plants > >>> * animals > >>> ** invertebrates > >>> ** vertebrates > >>> ---------->8---------- > >>> > >>> By pressing just Enter when the caret is inside a list item we > >>> create a > >>> new list item. This is the basic mechanism. It's simple and it > >>> should > >>> remain so. > >>> > >>> If I want to make the previous list a bit more complex: > >>> > >>> ----------8<---------- > >>> * (((= Plants = > >>> > >>> Plants are living organisms belonging to the kingdom Plantae.))) > >>> * (((= Animals = > >>> > >>> Animals are a major group of mostly multicellular, eukaryotic > >>> organisms > >>> of the kingdom Animalia or Metazoa. > >>> > >>> They are divided into:))) > >>> ** (((== Invertebrates == > >>> > >>> An invertebrate is an animal lacking a vertebral column.))) > >>> ** (((== Vertebrates == > >>> > >>> Vertebrates are members of the subphylum Vertebrata, chordates with > >>> backbones or spinal columns.))) > >>> ---------->8---------- > >>> > >>> I have to be able to insert new lines inside a list item using the > >>> Enter > >>> key but without creating a new list item. Let's consider the > >>> following > >>> state: > >>> > >>> ----------8<---------- > >>> * (((= Plants =))) > >>> ---------->8---------- > >>> > >>> We have a level 1 heading inside a list item. The caret is inside > >>> the > >>> heading, at the end. Pressing Enter can have the following three > >>> outcomes: > >>> > >>> 1. Continue editing in the heading, but on a new line: > >>> > >>> ----------8<---------- > >>> * (((= Title 1 > >>> x =))) > >>> ---------->8---------- > >>> > >>> 2. Continue editing in the same list item but after the heading, > >>> in a > >>> paragraph: > >>> > >>> ----------8<---------- > >>> * (((= Title 1 = > >>> > >>> x))) > >>> ---------->8---------- > >>> > >>> 3. Create a new list item: > >>> > >>> ----------8<---------- > >>> * (((= Title 1 =))) > >>> * x > >>> ---------->8---------- > >>> > >>> 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) > >> > >> I don't think we need META. > >> I'd go with the simplest: > >> * when inside a group, use the normal enter behavior for the > >> underlying element. If you're in a header then enter create a new > >> paragraph, etc) > >> * you need to position the cursor after the group in the list item > >> and > >> press enter to get a new list item > > > > The problem is that the list item wraps the group and there's no > > (easy) > > way to place the caret after the group but in the list item. > > That's why I suggested a visual way to identify the group so it's easy > to see if the caret is inside or outside the group (ie. before the </ > div> or after). > > > In fact the > > WYSIWYG editor is not aware of a group: it simply sees a list item > > with > > content inside. But since the caret is inside a heading the Enter > > key is > > treated accordingly, even if the heading is inside a list item. That's > > why I think we need a META+Enter to be able to get out of the list > > item. > > > >> > >> Note: another solution could allow to get out of the group by > >> pressing > >> tab but we said we wanted to keep the standard browser tab behavior. > > > > I don't see how we could use the Tab key. > > It would have the same effect as your META+Enter and would go to the > next list item for example. But again since we don't want to us Tab > it's moot. > > >> If we really want to introduce a new META+Enter then I'd definitely > >> vote +1 for A). > >> > >> BTW how are groups represented visually in the editor? Maybe this is > >> the real problem? > > > > Groups are not represented visually in a special way. As I said, the > > editor is not aware of them right now. I don't see how drawing a > > border > > around the group would help (through CSS). Also, in this case the > > XWiki > > 2.0 syntax user is forced to use the group notation in order to add > > complex content inside a list item because there's no other means of > > doing this so I don't think he would expect to see a border around the > > content in the WYSIWYG editor. > > I don't agree. For your description above of the different uses case > you *do* want to differentiate where you're inside a group or not > since the behaviors are not the same. So it makes sense to me to have > some visual clue of a group so that the user knows what behavior he'll > get. Well, there is no representation of a group per se in the WYSIWYG (you don't have a visual clue as to whether the caret is **here|** or **here**| ) and since you don't know where you are you can't get the caret in / out of the group using the left / right arrow keys. I'm not aware of any WYSIWYG editor that has such a way of displaying where exactly the caret is in relation to groups (either in desktop or web WYSIWYG editors). Additionally, I'm not sure we want to go into this direction since it poses numerous UI & technical issues. I've tested the behavior of OpenOffice Writer and it's the following: when a list item is also a heading, hitting enter when the caret is at the end of the line gets the caret out of the list and creates a new paragraph. In DekiWiki, hitting enter when the caret is at the end of the heading item creates a new list item. As I pointed it out in the JIRA comment, the most common behavior will be for users to expect a new list item to be created when they hit the enter key, whatever the content located in the list item. If we implement A) , users will have no clue about what they need to do to get out of the list if they put a heading in a list since they won't know about CTRL/META + ENTER. Choosing A) would result in making the most intuitive / most used option hard to reach. I really don't think that's what we want. Thus I'm strongly in favor of B) Enter for 3 and CTRL/META+Enter for 2 Guillaume > Thanks > -Vincent > > > Thanks, > > Marius > > > >> > >> Thanks > >> -Vincent > >> > >>> > >>> I'm +1 for A) for the following reason: if the user has inserted a > >>> heading in a list item then he will surely want to add more content > >>> after that heading, thus pressing just Enter is the natural way of > >>> doing > >>> this. From a technical POV the caret is first inside a heading and > >>> then > >>> inside a list item so the heading should have the priority of > >>> handling > >>> the Enter key. > >>> > >>> NOTE: Choosing A) or B) doesn't affect the way simple lists are > >>> created, > >>> which is using just Enter. > >>> > >>> Please cast your votes and sorry for the long mail, > >>> Marius > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users > -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
