Best Practice - To Embed or Not to Embed the Participant Center, That is the Question!

Options
What are the community's thoughts about embedding the participant center? Love it, hate it? What's the best practice?


On our team, we've embedded the PC in a pagebuilder page, as well as used the built-in wrapper tool in the PC itself. We've noticed a few issues when embedding. Has anyone else encountered these, or any other issues with either method? 

PARTICIPANT CENTER EMBED ISSUES:
  • JS errors
    • We've seen intermittent issues with using JS to manipulate the DOM, especially on slower internet connections that don't occur when using the built-in PC wrapper tool

       
  • Using an <iframe> creates small issues across the board, including:
    • browser compatibility
    • loading JS (especially libraries) in two places
    • interaction between PC features and the wrapper needs extra JS/jQuery to work, e.g:

      • jQuery( "#embeddedParticipantCenter" ).contents().find( "#msg_cat_nav_overview" ).click()); // PC nav functionality transported to wrapper nav
Have you seen these issues? Do you have a trusty best practice? Other issues you've found?


Thanks,


Lee
Tagged:

Comments

  • Hey Lee, just to confirm: are you editing custom JavaScript within the custom.js file of the Participant Center itself, or the PageWrapper?
  • Hi Chris,


    Thanks for the response.


    We're editing within the custom.js file of the PC. In cases where menu navigation of the PC needed to be included in the wrapper, some JS was applied there. Outside of those small exceptions, all work is being done in the custom.js file of the PC.


    Thanks,


    Lee
  • Hi Lee,


    I would say move away from having to embed the participant center in a pagebuilder -- Doing so gives you greater control on what you would like to do with your Participant Center (including those JS DOM manipulation due to iframe related browser restriction and the endless posibility of rendering it the way you want at initial load instead of manipulating afterwards (optimizing the performance), that to include making it mobile friendly which is currently not yet on vanilla version.


    When you create a new PC2 instance, you can access the entire folder associated of that PC2 instance from the ftp and manipulating a "stand-alone" PC2 instance usually revolves mainly around the following 3 files within that folder:
    • dashboard.html
    • js/custom.js
    • css/custom.css
    If you are more familiar with jQuery (like me) instead of the YUI, you can tap into the "doc ready" state of the PC2 loading which is you call your functions within the following line in that custom.js
     YAHOO.Convio.PC2.Utils.require("pc2:registrationLoaded", "pc2:constituentLoaded", "pc2:configurationLoaded", "pc2:wrapperLoaded", function() {
            //YAHOO.log("Registration, Constituent, Configuration, and Wrapper are all loaded.", "debug", "custom.js");
            //call your JS functions here
        });


    I would also "sanitize" / "separate" our jQuery from default Convio jQuery through the use of the noConflict such as declaring within that custom.js the following line  (and use "myJQ" instead of the regular $ or jQuery)
    var myJQ = jQuery.noConflict(true);


    While on the dashboard.html, you can usually call additional libraries / dependencies (i.e. bootstrap framework to make it responsive), create additional HTML elements (i.e. div containers/placeholders) to load 'reusable' pagebuilders.


    You can also jQuery load CLO pagebuilders and use them as "reusables" benefitting from the S-tag  (i.e. those participant S48 tag for badges etc) as you can actually recreate the URL parameter needed to achieve those.


    Here are couple examples of our stand-alone implementation , feel free to visit and register (free registration) on our walk event at
    http://stepout.diabetes.org  (just launching the 2016 yesterday)  or here is the previous year implementation (based on previous year wrapper) to give you a variety of what are the potentials you could do with a stand alone PC2
    http://stepout.diabetes.org/site/TR/StepOut/StepOutContent?fr_id=11140&pg=entry


    So far it has been a rewarding experience and much stable solution compared to when we were embedding the PC2 in an iframe.


    Hope it helps,


    regards,

    Daniel
  • Just an add on, finally got a time to screencast our recent last 2 year version of non-embedded and responsive PC2 to give you further ideas of the potentials when you are going the stand-alone approach.


    Attached zip contains .webm movie files


    regards,

    Daniel
  • LOVE the mobile-friendliness.  That is a huge drawback for the out-of-the-box PC2.  Your responsive solution looks amazing.
  • Thanks Tanna.


    Just in case, that responsive solution I have is built within the out-of-the-box PC2, with customization/modification made mainly on those 3 files (custom.js, custom.css, and dashboard.html (to put extra html elements as placeholder for jQuery load of reusable pagebuilder, as well as adding couple 3rd party js libraries i.e. bootstrap framework js, modal popup). Thus you guys can also achieve the same responsive PC2 while we are waiting for the official responsive out-of-the-box PC2.


    Other important note:
    • With this "built on top of default" approach, you might not want to be that "intrusive" especially when it comes with moving around default components for the sake of preserving default Convio PC2 Javascript functionality esp. when it comes to DOM manipulation (i.e. keep the parent/child container structure as much as possible, because those DOM manipulation as well as the Convio API that the OOB PC2 is using really look for that parent/child hierarchy, not to mention some of the default CSS stylesheets they have -- so to save you from the hassle/frustration of having to figure out what's going on when things not working)).Also keep those original IDs (on DIV etc), and do not just copy those DIVs with the same ID just because we feel like moving it to different place.
    • Other caveat: Although this is mobile friendly, but because of the above mentioned conservation/reservation we might be limited in terms of making it truly mobile friendly on usability. As you can see how these 2 iterations, we are still trying to tinker around how to best handle the information overload aspect of everything being presented at once. I also don't have that much of liberty when deciding what to show and what to hide because lot of this would come as directives from the rest of stakeholders.
    P.s. 

    And here's the next direction of where we are heading to see if we could just create our own PC2, because most if not all of the functionality within that OOB PC2 is actually coming from the Convio API.


    Here's a prototype of utilizing API to update your own personal page right on the spot without having to go to PC2
    https://community.blackbaud.com/forums/viewtopic/100/21614?post_id=70272#p70272


    regards,

    Daniel

Categories