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

Unexpected result in the preview if the draft has not been saved

    Details

      Description

      There are 2 cases for this bug:

      1. while creating a content, if the user clicks on the preview buttons before having saved the version, the preview displays a message saying it was impossible to preview the content (normal, it's not saved yet)
      2. while editing a content, if the user does some changes in the form but clicks on the preview buttons before doing a save, the preview will of course not take the last changes into account

      The second use cases is maybe less an issue but this can still be a bit confusing.

        Issue Links

          Activity

          Hide
          Damien Pobel (Inactive) added a comment -

          I added that issue to the inputQ and then I realized there are different questions to answer first, so it's back to the backlog.

          So to sum up, the draft should be saved before showing the preview, in other terms, clicking on one of the preview device button, is like clicking on "Save" and then clicking on the preview device. So here are the open questions:

          1. we can not (yet?) store invalid drafts, so how should the application behave if the user tries to preview a content with an invalid form ? Note that right now, when publishing or saving, if there's a validation error in a long form, it's difficult for the user to be aware of that unless he scrolls the entire form. So this question goes beyond this particular issue but that's definitively something to think about.
          2. what should we display to the user while we are saving the draft ? is a "in progress" notification enough ?
          3. I've just realized there's a position bug between the notification and the preview (the notification breaks the preview positioning and then the close preview link is outside of the viewport). At some point we discussed moving the notification to the bottom of the screen, is that still an improvement you want to see ? If so please, Inaki Juaniz-Velilla [~jince.kuruvilla@ez.no] Roland Benedetti can you create the corresponding story/improvement ?
          Show
          Damien Pobel (Inactive) added a comment - I added that issue to the inputQ and then I realized there are different questions to answer first, so it's back to the backlog. So to sum up, the draft should be saved before showing the preview, in other terms, clicking on one of the preview device button, is like clicking on "Save" and then clicking on the preview device. So here are the open questions: we can not (yet?) store invalid drafts, so how should the application behave if the user tries to preview a content with an invalid form ? Note that right now, when publishing or saving, if there's a validation error in a long form, it's difficult for the user to be aware of that unless he scrolls the entire form. So this question goes beyond this particular issue but that's definitively something to think about. what should we display to the user while we are saving the draft ? is a "in progress" notification enough ? I've just realized there's a position bug between the notification and the preview (the notification breaks the preview positioning and then the close preview link is outside of the viewport). At some point we discussed moving the notification to the bottom of the screen, is that still an improvement you want to see ? If so please, Inaki Juaniz-Velilla [~jince.kuruvilla@ez.no] Roland Benedetti can you create the corresponding story/improvement ?
          Hide
          Jince Kuruvilla (Inactive) added a comment -

          [~damien.pobel@ez.no] thanks for the heads up.

          1) If a user tries to preview content with an invalid form, then we should notify the user with a notification bar error message. This is definitely not the ideal interaction for a user, but let's use this behavior until we find a way to save invalid drafts.

          On this note, do we have any ability to make the page automatically jump/reload to the exact field that is invalid? I've seen this behavior done with other forms on the web and find it extremely helpful.

          2) Yes, I believe that showing a notification to the user is right, however "in progress" seems vague. Let's use "Generating Preview"

          3) Yes, moving notifications to the bottom of the screen is definitely an improvement we'd like to see. I'll create that story.

          Show
          Jince Kuruvilla (Inactive) added a comment - [~damien.pobel@ez.no] thanks for the heads up. 1) If a user tries to preview content with an invalid form, then we should notify the user with a notification bar error message. This is definitely not the ideal interaction for a user, but let's use this behavior until we find a way to save invalid drafts. On this note, do we have any ability to make the page automatically jump/reload to the exact field that is invalid? I've seen this behavior done with other forms on the web and find it extremely helpful. 2) Yes, I believe that showing a notification to the user is right, however "in progress" seems vague. Let's use "Generating Preview" 3) Yes, moving notifications to the bottom of the screen is definitely an improvement we'd like to see. I'll create that story.
          Hide
          Damien Pobel (Inactive) added a comment -

          I created an improvement request for scrolling to the invalid field https://jira.ez.no/browse/EZP-25202

          PR: https://github.com/ezsystems/PlatformUIBundle/pull/459

          Show
          Damien Pobel (Inactive) added a comment - I created an improvement request for scrolling to the invalid field https://jira.ez.no/browse/EZP-25202 PR: https://github.com/ezsystems/PlatformUIBundle/pull/459
          Show
          Damien Pobel (Inactive) added a comment - Merged in master in https://github.com/ezsystems/PlatformUIBundle/commit/e934f3463e5931455124a3d070d1238ce6d7df81
          Hide
          Rui Silva (Inactive) added a comment -

          Tested and approved by QA for master.

          Show
          Rui Silva (Inactive) added a comment - Tested and approved by QA for master.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: