[MGNLPN-114] Develop trait to target a specific type of visitor Created: 14/May/14  Updated: 03/Jun/14  Resolved: 29/May/14

Status: Closed
Project: Magnolia Personalization
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Task Priority: Critical
Reporter: Andreas Weder Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File S01 - Choose audience 2.png     PNG File S05 - Restrict by visitor 1.png     PNG File S05 - Restrict by visitor 2 - set recurring 1.png     PNG File S05 - Restrict by visitor 3 - recurring.png     PNG File S05 - Restrict by visitor 4 - set logged in 1.png     PNG File S05 - Restrict by visitor 4 - set logged in 2.png     File Trait for visitor type.pdf    
Issue Links:
Cloners
is cloned by MGNLPN-117 Develop trait for gender if a visitor... Closed
Relates
relates to MGNLPN-136 Rename "recurring" to "returning" Vis... Closed
relation
is related to MGNLPN-102 Develop trait to select locations Closed
is related to MGNLPN-103 Develop trait to select segments Closed
is related to MGNLPN-110 Develop trait to specify visit date Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: Personalisation

 Description   

This mockup describes a UI for a trait to specify a specific type of visitor. It allows to differentiate between new, recurring, registered and logged in visitors.

The mockup actually goes further than our initial implementation probably must go. The essence is to be able to distinguished between new and recurring visitors, and for the latter to determine if he or she is logged in or not. There's no need to also be able to specify the username (or group or role) of a logged-in user - in fact, it's unclear if what the mockup offers here is actually what would be required.

The UI of a trait is largely depending on the trait itself, but it also has some aspects it shares with other traits. The UI described here - as the visit date trait, btw - also acts as an example for a trait that uses an embedded dialog, similar in appearance to the embedded dialogs used in small apps, to collect more complex data. While such a dialog is preferable, the alternative would be to open a light dialog, preferably attached to the input field, as is shown by the last of the attached mockups and the attached visual design.



 Comments   
Comment by Andreas Weder [ 14/May/14 ]

Added clickable PDF prototype.

Comment by Roman Kovařík [ 23/May/14 ]

First draft of visitor trait committed on branch:

  • Currently consists of two traits (visitor, visitorrecurring).
    That's because we get parameters like e.g. visitor=new, visitorrecurring=true false. We could possible merge these two traits if we use a custom transformer for main field which also takes care of subfields.
    • visitorrecurring has only traitClass and converterClass, it's field it's part of visitor trait. It's similar solution as for persona trait (We have persona trait defined, but without any fields so the persona fields don't appear between other trait fields)
  • Not yet finished:
    • saving of ruleField ends up with IAE (a custom transformer mentioned above could probably solve this issue).
    • voter
    • detector filter
    • user credentials field (wouldn't be user groups instead of users more logical here)?
    • preview is not refreshed on inner checkboxes changes
Generated at Mon Feb 12 06:34:27 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.