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

          Damien Pobel (Inactive) created issue -
          Damien Pobel (Inactive) made changes -
          Field Original Value New Value
          Epic Link EZP-22949 [ 11445 ]
          Damien Pobel (Inactive) made changes -
          Status Open [ 1 ] Confirmed [ 10037 ]
          Damien Pobel (Inactive) made changes -
          Link This issue is duplicated by EZP-25059 [ EZP-25059 ]
          Damien Pobel (Inactive) made changes -
          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. 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
          Damien Pobel (Inactive) made changes -
          Epic Link EZP-22949 [ 11445 ] EZP-25353 [ 52846 ]
          Damien Pobel (Inactive) made changes -
          Status Confirmed [ 10037 ] InputQ [ 10001 ]
          Damien Pobel (Inactive) made changes -
          Status InputQ [ 10001 ] Development [ 3 ]
          Assignee Damien Pobel [ damien.pobel@ez.no ]
          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 ?
          Damien Pobel (Inactive) made changes -
          Flagged Impediment [ 10000 ]
          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.
          Jince Kuruvilla (Inactive) made changes -
          Attachment WF 1.png [ 26331 ]
          Attachment WF 2.png [ 26332 ]
          Attachment WF 3.png [ 26333 ]
          Damien Pobel (Inactive) made changes -
          Flagged Impediment [ 10000 ]
          Damien Pobel (Inactive) made changes -
          Status Development [ 3 ] Backlog [ 10000 ]
          Damien Pobel (Inactive) made changes -
          Status Backlog [ 10000 ] Development [ 3 ]
          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.
          Damien Pobel (Inactive) made changes -
          Epic Link EZP-25353 [ 52846 ] EZP-25541 [ 53500 ]
          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.
          Damien Pobel (Inactive) made changes -
          Status Development [ 3 ] Backlog [ 10000 ]
          Dominika Kurek made changes -
          Labels to-add-to-doc
          Jince Kuruvilla (Inactive) made changes -
          Attachment WF 1.png [ 26331 ]
          Jince Kuruvilla (Inactive) made changes -
          Attachment WF 2.png [ 26332 ]
          Jince Kuruvilla (Inactive) made changes -
          Attachment WF 3.png [ 26333 ]
          Jince Kuruvilla (Inactive) made changes -
          Attachment WF 1.png [ 26401 ]
          Attachment WF 2.png [ 26402 ]
          Attachment WF 3.png [ 26403 ]
          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.
          Damien Pobel (Inactive) made changes -
          Assignee Damien Pobel [ damien.pobel@ez.no ]
          Damien Pobel (Inactive) made changes -
          Status Backlog [ 10000 ] Development [ 3 ]
          Assignee Damien Pobel [ damien.pobel@ez.no ]
          Damien Pobel (Inactive) made changes -
          Status Development [ 3 ] Development Review [ 10006 ]
          Show
          Damien Pobel (Inactive) added a comment - PR: https://github.com/ezsystems/PlatformUIBundle/pull/776
          Damien Pobel (Inactive) made changes -
          Remote Link This issue links to "PR (Web Link)" [ 17376 ]
          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 )
          Damien Pobel (Inactive) made changes -
          Status Development Review [ 10006 ] Documentation Review done [ 10011 ]
          Assignee Damien Pobel [ damien.pobel@ez.no ]
          Paulo Nunes (Inactive) made changes -
          Status Documentation Review done [ 10011 ] QA [ 10008 ]
          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.
          Damien Pobel (Inactive) made changes -
          Link This issue testing discovered EZP-26864 [ EZP-26864 ]
          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
          Paulo Nunes (Inactive) made changes -
          Assignee Paulo Nunes [ paulo.nunes@ez.no ]
          Status QA [ 10008 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Yannick Roger (Inactive) made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Yannick Roger (Inactive) made changes -
          Fix Version/s 1.8.0 [ 14682 ]
          Yannick Roger (Inactive) made changes -
          Status Reopened [ 4 ] Confirmed [ 10037 ]
          Yannick Roger (Inactive) made changes -
          Status Confirmed [ 10037 ] Backlog [ 10000 ]
          Yannick Roger (Inactive) made changes -
          Status Backlog [ 10000 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Alex Schuster made changes -
          Workflow EZ* Development Workflow [ 95440 ] EZEE Development Workflow [ 125021 ]
          Alex Schuster made changes -
          Workflow EZEE Development Workflow [ 125021 ] EZEE and EZP Story Workflow [ 128004 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Confirmed Confirmed
          4s 1 damien.pobel@ez.no 20/Aug/15 4:34 PM
          Confirmed Confirmed InputQ InputQ
          190d 24m 1 damien.pobel@ez.no 26/Feb/16 3:58 PM
          InputQ InputQ Development Development
          6s 1 damien.pobel@ez.no 26/Feb/16 3:59 PM
          Development Development Backlog Backlog
          12d 21h 49m 2 damien.pobel@ez.no 10/Mar/16 1:48 PM
          Backlog Backlog Development Development
          300d 1h 48m 2 damien.pobel@ez.no 04/Jan/17 3:37 PM
          Development Development Development Review Development Review
          7d 58m 1 damien.pobel@ez.no 11/Jan/17 4:35 PM
          Development Review Development Review Documentation Review done Documentation Review done
          5d 17h 5m 1 damien.pobel@ez.no 17/Jan/17 9:40 AM
          Documentation Review done Documentation Review done QA QA
          7m 28s 1 Paulo Nunes 17/Jan/17 9:48 AM
          QA QA Closed Closed
          6h 41m 1 Paulo Nunes 17/Jan/17 4:29 PM
          Closed Closed Reopened Reopened
          19d 18h 31m 1 yannick.roger@ez.no 06/Feb/17 11:01 AM
          Reopened Reopened Confirmed Confirmed
          16s 1 yannick.roger@ez.no 06/Feb/17 11:01 AM
          Confirmed Confirmed Backlog Backlog
          4s 1 yannick.roger@ez.no 06/Feb/17 11:01 AM
          Backlog Backlog Closed Closed
          12s 1 yannick.roger@ez.no 06/Feb/17 11:01 AM

            People

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

              Dates

              • Created:
                Updated:
                Resolved: