[MGNLPN-165] "Preview as visitor" on a variant leads to inconsistent results Created: 12/Jun/14  Updated: 09/Sep/14  Resolved: 09/Sep/14

Status: Closed
Project: Magnolia Personalization
Component/s: Preview App
Affects Version/s: 1.0
Fix Version/s: 1.0.1

Type: Bug Priority: Major
Reporter: Andreas Weder Assignee: Christopher Zimmermann
Resolution: Fixed Votes: 0
Labels: usability, ux
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

eebundle snapshot: magnolia-enterprise-bundle-5.3-20140612.072113-288
eebundle snapshot: magnolia-enterprise-bundle-5.3-20140612.210538-295


Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Our idea of allowing to directly view a particular page variant as a visitor has a major flaw: if that variant is opened in the Previews app, the selected "anonymous" persona is typically wrong. Or at least, the combination of variant shown and persona selected is often wrong.

Steps to reproduce:

  • create a page variant and assign it to a German audience
  • in Pages, select that variant, then choose "preview as visitor"
  • the page opens up in the Previews app, the selected "anonymous" persona, however, is not supposed to see this variant

I see the following options:

  1. we add an "unselected" state, including a different image. This state would be selected in such a case. I still see value in offering a full-screen preview here and in then being able to toggle through the available personas to verify, who exactly sees the variant I've just previewed.
    • Question: What do we show if - in a normal previewing scenario - someone selects "unselected"?
  2. pre-select the first persona that would see the variant (ambiguous result)
  3. add one or more traits with values that would allow an anonymous user to see the variant (ambiguous result)
  4. show a 404: don't show the page in such a case.
  5. show the initial, original main node
    1. Redirect in PreviewApp
    2. Check in info.magnolia.personalization.preview.ui.action.OpenPreviewAppAction if it's a variant and if so use the main node to open the PreviewApp
  6. make action "Preview as visitor" unavailable for variants

I'm clearly in favor of 1) as it is simple and supports the flow that I then click through my personas directly without further ado (i.e. I don't have to remove traits that would have been added by option 3). 2) and 3) are probably difficult to implement, but they also lead to a surprising, unforeseen UI, which I want to avoid. 4) actually feels more like the system is broken.



 Comments   
Comment by Philip Mundt [ 12/Jun/14 ]

Testing this on the current build reveals, that one is always redirected to the mainNode when viewing a variant, which I would consider correct behavior (this would have been my suggestion for option 5.)!?

Comment by Andreas Weder [ 12/Jun/14 ]

Sure, yes, your "option 5" is totally fine with me. It's consistent, correct behavior. I've focused on keeping the full-screen preview of the exact page I've selected when clicking on "preview as visitor", but that's hijacking the Previews app at this point in time.

Comment by Andreas Weder [ 12/Jun/14 ]

Actually, I just tested again with the latest snapshot (magnolia-enterprise-bundle-5.3-20140612.111537-290): this is still the case here.

  • created page variant for /demo-project/about/subsection-articles
  • edited the page, assigned it to the Swiss country segment
  • in the page tree, selected the variant, then clicked on "preview as visitor"
  • Previews app opens with "anonymous" persona, but shows the Swiss variant, not the master page
Comment by Andreas Weder [ 02/Sep/14 ]

I've discussed (currently) possible solutions with Philipp Mundt. I'd go for option 5.2 now.

Since these two apps have different purposes - the page editor and preview are for working on the physical page structure and thus show variants; the preview app is for previewing an entire site as a specific type of visitor -, we won't be able to bridge the gap smoothly anyway, since variants must show up under the same URL as their master page on an actual site. Since we want the preview app to be as accurate as possible, option 1 is not really wanted - there's no such thing as an "unselected" persona. Nevertheless, jumping directly from editing a variant to the preview app is an important part of the editing flow. We should keep that.

Thus I'd go for the proposed option 5.2, but with the added requirement that we show an info notification if the page shown by the preview app is not the one I was on when I chose the "preview as visitor" action, e.g. "This is the page shown to unknown visitors by default. Choose a persona and/or trait on the right to preview its personalized variants.". I've discussed this along these lines with Philipp already.

Comment by Christopher Zimmermann [ 02/Sep/14 ]

Fix works but does not include the required info message specified in the previous comment.

Comment by Mikaël Geljić [ 03/Sep/14 ]

I don't really mind but here's a bunch of further variations (sorry, couldn't help myself).
Essentially I find it always a little bit awkward if we have to explain how the UI works ("Choose a persona...").

Option 5.3: Open message as an alert or confirmation before switching to preview app (OK I understood, please proceed). Would work best if we had a way to discard such message once for good though — [ ] Remind me next time.
Option 7: Rename the action "Preview as anonymous"
Option 8: Add an indication in Preview app, telling what variant is currently resolved: "Showing original page", "Showing variant ${variantTitle}"

(2¢)

Comment by Christopher Zimmermann [ 04/Sep/14 ]

When OpenPreviewAppAction detects a variant, it adds a parameter to the location so that PagePreviewSubApp can display a notification.

Unfortunately it was not possible to display the notification directly in OpenPreviewAppAction since PagePreviewSubApp displays the preview as an overlay as well and therefore would simply cover the notification!

Note: The parameter added to the location is ":::source=variant", the colons are necessary because the DetailLocation has several items with fixed positions in the fragment.

Comment by Christopher Zimmermann [ 09/Sep/14 ]

All info messages can be clicked on - then they wont dissapear by themselves.

Generated at Mon Feb 12 06:34:57 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.