Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-24724

As an editor, I want to be able to reorder the elements in the RichText editor

    Details

      Description

      The currently selected element should get an outline and it should be possible to drag and drop it before or after any other element in the RichText area.

      See also description in EZP-25059

      1. WF 1.png
        375 kB
      2. WF 2.png
        378 kB
      3. WF 3.png
        376 kB

        Issue Links

          Activity

          Hide
          Damien Pobel (Inactive) added a comment -

          [~jince.kuruvilla@ez.no] Roland Benedetti Inaki Juaniz-Velilla I've been working on that story for almost a week now and you can see in this video where I am (note: it's invisible in the video but while you are dragging an element, there's a ghost image of the dragged element near the mouse pointer note2: it's a really a prototype!). When you give the focus to a paragraph, an handle element appears (the grey horizontal line with a sign similar to = in it) and you can use it to drag the element in the editor. The future position of the element is represented by the black dotted line and when you are over an element if your gesture goes down the future position of the element is below that element otherwise the future position is above the element. It's not exactly what is described in EZP-25059 but it's the closest I can do. This is kind of working for simple paragraphs but extending this behaviour to others elements raises several questions/suggestions/issues:

          1. Should I follow the same handle strategy for embeds and images ie when it receives the focus, I'm revealing the handle ? I'm asking because embeds and images are not editable (ie you can not add or remove text in those elements), so the handle is not strictly necessary. So when such element has the focus (or even if it does not have the focus), the editor could directly have the "drag" cursor and be able to move it anywhere in the editor.
          2. Align embeds/images vs. drag and drop: The embeds/images can now be aligned on the left or on the right. In such case, those elements are "floating", that basically means the visual order of elements in the editor is not trivial any more and this can lead to strange result from the editor perspective when dragging and dropping others elements. For instance, if you have an image floating on the left with some text on its right and if you drag an element so it's added right after the image, the element will be visually added right before the text not below the image.
          3. How do we handle list ? Let me explain how a list is represented in HTML (that's a bit technical, sorry ) To represent a list you basically have the following markup:

            <ul>
              <li>List item 1</li>
              <li>List item 2</li>
              <li>List item 3</li>
            </ul>
            

            <ul> is the list itself, the <li>s are the list items. At the moment in the editor, when you click on a list you actually give the focus to one of its list item but you should not be able to freely drag and drop a list item because a list item (<li> element) should always be in a list (<ul> element). Also, since the list itself (the <ul>) can not really get the focus, there's no way for the editor to move the whole list. So the list behaviour should be carefully defined/designed. Also, we'll have the same issue with any composed element that is not read only (like tables or custom tags maybe).

          After thinking a bit about the whole topic, I think having the ability to both edit and drag and drop elements in the editor at the same time is really too complicated and will inevitably lead to bugs and functional problems (I'm sure there are more edge cases). To avoid that I would suggest we introduce a "structure mode" in Online Editor to handle the elements position. In that mode, the user would not be able to edit the content but only to move (and maybe remove) blocks. The elements would just be stacked (so in that mode a left aligned embed is not floating) so the editor can only focus on the order of elements and for composed elements (like the list), we could easily let the user pick a sub-element (an item in the case of a list) or the whole element without conflict the editing process. That mode could look like what Sir Trevor is providing.

          Any opinion on that ?

          Show
          Damien Pobel (Inactive) added a comment - [~jince.kuruvilla@ez.no] Roland Benedetti Inaki Juaniz-Velilla I've been working on that story for almost a week now and you can see in this video where I am (note: it's invisible in the video but while you are dragging an element, there's a ghost image of the dragged element near the mouse pointer note2: it's a really a prototype!). When you give the focus to a paragraph, an handle element appears (the grey horizontal line with a sign similar to = in it) and you can use it to drag the element in the editor. The future position of the element is represented by the black dotted line and when you are over an element if your gesture goes down the future position of the element is below that element otherwise the future position is above the element. It's not exactly what is described in EZP-25059 but it's the closest I can do. This is kind of working for simple paragraphs but extending this behaviour to others elements raises several questions/suggestions/issues: Should I follow the same handle strategy for embeds and images ie when it receives the focus, I'm revealing the handle ? I'm asking because embeds and images are not editable (ie you can not add or remove text in those elements), so the handle is not strictly necessary. So when such element has the focus (or even if it does not have the focus), the editor could directly have the "drag" cursor and be able to move it anywhere in the editor. Align embeds/images vs. drag and drop: The embeds/images can now be aligned on the left or on the right. In such case, those elements are "floating", that basically means the visual order of elements in the editor is not trivial any more and this can lead to strange result from the editor perspective when dragging and dropping others elements. For instance, if you have an image floating on the left with some text on its right and if you drag an element so it's added right after the image, the element will be visually added right before the text not below the image. How do we handle list ? Let me explain how a list is represented in HTML (that's a bit technical, sorry ) To represent a list you basically have the following markup: < ul > < li >List item 1</ li > < li >List item 2</ li > < li >List item 3</ li > </ ul > <ul> is the list itself, the <li>s are the list items. At the moment in the editor, when you click on a list you actually give the focus to one of its list item but you should not be able to freely drag and drop a list item because a list item (<li> element) should always be in a list (<ul> element). Also, since the list itself (the <ul>) can not really get the focus, there's no way for the editor to move the whole list. So the list behaviour should be carefully defined/designed. Also, we'll have the same issue with any composed element that is not read only (like tables or custom tags maybe). After thinking a bit about the whole topic, I think having the ability to both edit and drag and drop elements in the editor at the same time is really too complicated and will inevitably lead to bugs and functional problems (I'm sure there are more edge cases). To avoid that I would suggest we introduce a "structure mode" in Online Editor to handle the elements position. In that mode, the user would not be able to edit the content but only to move (and maybe remove) blocks. The elements would just be stacked (so in that mode a left aligned embed is not floating) so the editor can only focus on the order of elements and for composed elements (like the list), we could easily let the user pick a sub-element (an item in the case of a list) or the whole element without conflict the editing process. That mode could look like what Sir Trevor is providing. Any opinion on that ?
          Hide
          Damien Pobel (Inactive) added a comment - - edited
          Show
          Damien Pobel (Inactive) added a comment - - edited Self note: prototype code pushed to https://github.com/ezsystems/PlatformUIBundle/tree/ezp-24724_reorder_oe
          Hide
          Jince Kuruvilla (Inactive) added a comment -

          Hey Damien,

          Thanks for the detailed explanation above - i think we need to jump on a call on Monday and discuss this in detail, but until then, thoughts below:

          Should I follow the same handle strategy for embeds and images ie when it receives the focus, I'm revealing the handle ?

          Instead of giving users the ability to move content by hovering (then clicking and dragging) on the element borders, why don't we bring back the "move" icons in the contextual toolbar? See the attached wireframes (WF 1-3) That way, we can keep the existing behavior and relegate the moving functionality to a specific point in the UI.

          For instance, if you have an image floating on the left with some text on its right and if you drag an element so it's added right after the image, the element will be visually added right before the text not below the image.

          Wait, isn't this the expected behavior though? In your situation, I'm dragging the new element in between the image and the text, correct? Then it makes sense that the new element appears in the place that the text did. Maybe this would be better explained on a call?

          How do we handle list ?

          We should make the list it's own separate element. Is there a reason why it's not in the current implementation? If it's an element, then the user would be able to move the lists around, wouldn't they? Let's dive into this a little bit more on the call

          I would suggest we introduce a "structure mode" in Online Editor to handle the elements position. In that mode, the user would not be able to edit the content but only to move (and maybe remove) blocks.

          If we allow users to move the elements by use of the "move" icons in the toolbar, wouldn't that achieve the same goal as the separate "structure" mode? Essentially the same as Sir Trevor, except the functionality would be within the toolbar that appears when a user clicks on the element instead of on hover as it is currently in Sir Trevor.

          Show
          Jince Kuruvilla (Inactive) added a comment - Hey Damien, Thanks for the detailed explanation above - i think we need to jump on a call on Monday and discuss this in detail, but until then, thoughts below: Should I follow the same handle strategy for embeds and images ie when it receives the focus, I'm revealing the handle ? Instead of giving users the ability to move content by hovering (then clicking and dragging) on the element borders, why don't we bring back the "move" icons in the contextual toolbar? See the attached wireframes (WF 1-3) That way, we can keep the existing behavior and relegate the moving functionality to a specific point in the UI. For instance, if you have an image floating on the left with some text on its right and if you drag an element so it's added right after the image, the element will be visually added right before the text not below the image. Wait, isn't this the expected behavior though? In your situation, I'm dragging the new element in between the image and the text, correct? Then it makes sense that the new element appears in the place that the text did. Maybe this would be better explained on a call? How do we handle list ? We should make the list it's own separate element. Is there a reason why it's not in the current implementation? If it's an element, then the user would be able to move the lists around, wouldn't they? Let's dive into this a little bit more on the call I would suggest we introduce a "structure mode" in Online Editor to handle the elements position. In that mode, the user would not be able to edit the content but only to move (and maybe remove) blocks. If we allow users to move the elements by use of the "move" icons in the toolbar, wouldn't that achieve the same goal as the separate "structure" mode? Essentially the same as Sir Trevor, except the functionality would be within the toolbar that appears when a user clicks on the element instead of on hover as it is currently in Sir Trevor.
          Hide
          Damien Pobel (Inactive) added a comment -

          I think it's close to impossible to implement the interaction the wireframe. I need to check the details, but I think because of the markup structure, it won't be possible to move both the toolbar and its associated content.

          For the aligned image: it's the expected behavior, I'm fine with it but I'm sure non tech users will find that a bit confusing.

          For the list, we can change the behaviour (ie consider the list as one "widget") but that mean it won't be possible for the user change the setting (for instance the alignment) for a list item only.

          Show
          Damien Pobel (Inactive) added a comment - I think it's close to impossible to implement the interaction the wireframe. I need to check the details, but I think because of the markup structure, it won't be possible to move both the toolbar and its associated content. For the aligned image: it's the expected behavior, I'm fine with it but I'm sure non tech users will find that a bit confusing. For the list, we can change the behaviour (ie consider the list as one "widget") but that mean it won't be possible for the user change the setting (for instance the alignment) for a list item only.
          Hide
          Roland Benedetti added a comment -

          Hi, looking forward to synch on this in a call.

          I'd like to say:

          • I am not sure to understand the implementation challenge but I trust you
          • I am not against a "structure" mode but have the impression it would make things more complex for the user, and also make more work?
          • For the list, so far I don't think we have settings, this said, for me once we have them, it makes more sense to have them for the whole list.
          Show
          Roland Benedetti added a comment - Hi, looking forward to synch on this in a call. I'd like to say: I am not sure to understand the implementation challenge but I trust you I am not against a "structure" mode but have the impression it would make things more complex for the user, and also make more work? For the list, so far I don't think we have settings, this said, for me once we have them, it makes more sense to have them for the whole list.
          Hide
          Jince Kuruvilla (Inactive) added a comment -

          [~damien.pobel@ez.no] - I updated the wireframes attached to this ticket - should now reflect the new arrow-behavior we agreed on.

          Show
          Jince Kuruvilla (Inactive) added a comment - [~damien.pobel@ez.no] - I updated the wireframes attached to this ticket - should now reflect the new arrow-behavior we agreed on.
          Show
          Damien Pobel (Inactive) added a comment - PR: https://github.com/ezsystems/PlatformUIBundle/pull/776
          Hide
          Damien Pobel (Inactive) added a comment -

          @QA again, I clicked on merge before sending to QA... (Not Enough Coffee Syndrome )

          Show
          Damien Pobel (Inactive) added a comment - @QA again, I clicked on merge before sending to QA... (Not Enough Coffee Syndrome )
          Hide
          Paulo Nunes (Inactive) added a comment -

          @[~damien.pobel@ez.no]:
          I can't move "lists", because the up/down arrow don't appear for them (when we are on a list, only the plus sign ("+") appears on the left side).
          Following the arguments you gave in this comment, I was unsure if this is an expected limitation. Can you please confirm?

          Show
          Paulo Nunes (Inactive) added a comment - @ [~damien.pobel@ez.no] : I can't move "lists", because the up/down arrow don't appear for them (when we are on a list, only the plus sign ("+") appears on the left side). Following the arguments you gave in this comment , I was unsure if this is an expected limitation. Can you please confirm?
          Hide
          Damien Pobel (Inactive) added a comment -

          Paulo Nunes that's a very valid feedback. That's not really expected but at the moment our support for list is very minimal in the editor. As you wrote, there's no toolbar for list so nowhere to put the move buttons (and the remove button is also missing btw). So I created another improvement EZP-26864 to handle that.

          Show
          Damien Pobel (Inactive) added a comment - Paulo Nunes that's a very valid feedback. That's not really expected but at the moment our support for list is very minimal in the editor. As you wrote, there's no toolbar for list so nowhere to put the move buttons (and the remove button is also missing btw). So I created another improvement EZP-26864 to handle that.
          Hide
          Paulo Nunes (Inactive) added a comment -

          QA Approved
          Out of this approval is EZP-26864

          Show
          Paulo Nunes (Inactive) added a comment - QA Approved Out of this approval is EZP-26864

            People

            • Assignee:
              Unassigned
              Reporter:
              Damien Pobel (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: