Hiding system fields in Web Widget

9 Comentarios

  • Ron Michael Zettlemoyer

    I too want the name and email address hidden. They're already populated since we know the user and don't want or need the user to change them. It's not just a matter of them seeing or changing something we already know: hiding them reduces the clutter so that the user can focus on what we're asking them.

    I used to have a little Javascript hack that would do this for me (see below) but the latest version of the widget has broken it. :( This works if the contact widget is on the screen but no longer works if it's run before the contact widget is rendered. 

    var tsf = $("#webWidget");
    tsf = tsf.contents();
    tsf.find("input[name='name']").parent("div").hide();
    tsf.find("input[name='email']").parent("div").hide();
    tsf.find(".Icon--zendesk").hide();

     

     

    0
  • Ron Michael Zettlemoyer

    PS - I got curious and found a way to get this working in Javascript again. Here's a rough example:

    var observer = new MutationObserver(function (mutationList, observer) {
        var tsf = $("#webWidget").contents();
        tsf.find("input[name='name']").parent("div").hide();
        tsf.find("input[name='email']").parent("div").hide();
        tsf.find(".Icon--zendesk").hide();
    });

    observer.observe($("#webWidget").contents().find("#Embed")[0], { attributes: true, childList: true, subtree: true });

    0
  • Nicole - Community Manager

    Thanks for sharing that solution, Ron!

    0
  • Daniel Aron

    Hi Tom and Ron, there are a couple of options that may help. You can use the prefill API to prefill form fields and set them to read-only to prevent the user from changing the values. Also, you can now hide the name field from the contact form or ticket forms from Widget admin.

    1
  • Ron Michael Zettlemoyer

    Thanks, Daniel. I've been using the prefill API, and it's good that hiding the name field is now a standard feature. Any reason why you didn't also allow the email to be hid? I knew we could make the fields read only but our goal was to simplify the form and reduce any scrolling (since it's a small box) and not distract the user with anything that didn't require action.

     

    0
  • Daniel Aron

    Hi Ron, we focussed on name field as a priority because it was causing issues with consistency between the Web Widget and the Help Center contact forms. Also name field isn't required by our back-end for us to submit a ticket form, whereas email address is. That said, I understand the need in your scenario, where you have the visitor's email address and want to be able to send it through without displaying it on the UI. We'll take this into consideration for future improvements. 

    0
  • Karen D Snyder

    My requirements were to hide Name, Email, and Subject, change Description explanation, hide Description label, and enlarge Description area. I had a problem with the above solution, because the following code caused a console error, presumably because $("#webWidget") does not yet exist when the document.ready function executes:

    observer.observe($("#webWidget").contents().find("#Embed")[0], { attributes: true, childList: true, subtree: true });

    So I modified the code to look for mutations in the document body, and find the mutations that are from the web widget (target nodeName name is iframe, and target className contains zEWidget-webWidget). This is my code, inserted in script.js in the document ready funciton:

    var observeMutationOptions = { attributes: true, childList: true, subtree: true };
    var observerDocument = new MutationObserver(function (mutations) {
    if (mutations[0].target.nodeName.toLowerCase() == 'iframe' && mutations[0].target.className.indexOf('zEWidget-webWidget') >= 0) {
    var widget = $("#webWidget").contents();
    widget.find('input[name="email"]').parent('div').hide();
    widget.find('div label strong:contains("Subject")').parent('label').parent('div').hide();
    widget.find('div label strong:contains("Description")').parent('label').next('div').text('Please tell us how we can improve this site');
    widget.find('div label strong:contains("Description")').parent('label').hide();
    widget.find('div label strong:contains("Description")').parent('label').parent('div').find('textarea').attr('rows', 12);
    }
    });
    observerDocument.observe(document.body, observeMutationOptions);

    [My code does not hide the name field, because I used the option in agent admin to not display the name.]

     

    0
  • Ron Michael Zettlemoyer

    Good point, Karen. The code I posted was just a snippet of my full code, which doesn't run until #webWidget actually exists. In my implementation, I don't use Zendesk's default launcher buttons to bring up the widget. I have my own UI button. When it's clicked, then I look for #webWidget. If #webWidget hasn't loaded yet, I do nothing. If it has, I set up the mutation on #webWidget and then call zE.activate() to show the widget.

    I haven't done a whole lot with mutation observers in the past but I'd be slightly concerned about putting an observer on document.body because that means you are observing every single mutation on the page. So the code is running A LOT and it's making all of those changes to the widget every single time it runs. It could have a negative impact on page performance.

    It might be better to set up a callback for when the widget is opened (https://developer.zendesk.com/embeddables/docs/widget/core#on-open) and set up your mutation there, on #webWidget, when you know #webWidget is ready.

     

     

     

     

     

    0
  • Karen D Snyder

    Ron, thanks for your answer; now I understand why you didn't have a problem when the observation of  #webWidget started.

    I removed the widget code from script.js, and added code in document_head.hbs to add a callback function on widget open; that is definitely more efficient! I used console logs to establish that the web widget node is added when the widget is launched, and when the widget is opened, the only mutations are style changes. So it is safe to just modify the form when the widget opens, without having to observe mutations. This is the code in document_head.hbs, between <script> tags:

     zE('webWidget:on', 'open', function () {
    var widget = $("#webWidget").contents();
    widget.find('input[name="email"]').parent('div').hide();
    widget.find('div label strong:contains("Subject")').parent('label').parent('div').hide();
    widget.find('div label strong:contains("Description")').parent('label').next('div').text('Please tell us how we can improve this site');
    widget.find('div label strong:contains("Description")').parent('label').hide();
    widget.find('div label strong:contains("Description")').parent('label').parent('div').find('textarea').attr('rows', 12);
    });

    [As for observing the entire document body for mutations, it probably isn't ideal, but unfortunately I was already observing the entire document body because I need to manipulate the search results, which means looking for the addition of zd-autocomplete elements. I couldn't come up with any better way of doing this than observing the document body. Any suggestions welcome!]

    0

Iniciar sesión para dejar un comentario.

Tecnología de Zendesk