10 Replies Latest reply on Nov 19, 2013 3:01 PM by moman

    HTML Widget "policy"

    laurabecraft

      Looking for some feedback on how other Communities handle requests/issues with the html widget. 

       

      We have a small shop, so our message to users has mostly been that if they want to use the html widget and get fancy with their pages, they have to do the work themselves.  We don't have  the resources, or training to develop or support it.  If they  see other pages they like and want to know how to do them, then we encourage them to contact the other owner and inquire as to how they did it.  If that person wants to share, good, if not, that's okay to.  Our policy has been a mostly "use at your own risk" sort of thing.

       

      BUT (because you knew there had to be one), this is causing problems.  If they are using Javascript, and there is something wrong, it can cause the page to "lock up" and not allow you to edit it.  Apparently, in the previous version of Jive (we are on 6.01 now), our admin could do something in the console and release the page.  That seems to have changed with this version so it's resulting in more calls to us = more tickets to Jive.

       

      I'm just curious how other communities are responding to requests from users to either design their pages, or fix their pages, or just what the communication is in general when you talk about that widget or general page design.  Our users are getting very creative, often at the expense of the whole point of Jive, but if it helps them to use it, then maybe it's not such a  bad thing.  Personally, I would rather they focus on how to collaborate better rather than designing the perfect toolbar that consumes half the page, but that's just me....

       

      Thanks.

        • Re: HTML Widget "policy"
          cservilio

          In our community we have actually restricted the ability to use JavaScript to only admins--that way we don't have to worry about the page-breaking issue. It has still happened a couple of times, and we used the Admin Essentials plugin to fix that, but we have not installed it on our new 6.0 instance yet so if someone really needs a JavaScript widget I always try it in the test environment first.

           

          However, when I do the community manager training with our community managers, I try to tell them that the point of the homepage is not to be fancy and complicated, but to surface the really important content and activity from their group.  They want their users to be able to see at a glance what's new and relevant, not have to go searching around through every tab in the group.  I try to tell them to think of content as the lifeblood of their community and not to get hung up on the display.  (I also usually point out that in the future our users will probably consume more and more content via their streams and may not visit individual group pages that much.)  Not sure if any of this will matter to your users, but that's how I try to frame it!

            • Re: HTML Widget "policy"
              laurabecraft

              Hey Caitlin, thanks for the feedback.  Unfortunately, our chance to restrict the JS ability is a bell we can't unring, I wish we could. 

               

              I like the way you frame your message.  We do try to reinforce our communication that Jive is for collaboration and sharing, expertise location, etc and to design spaces and groups for usability.   But we have a few areas that are just really hung up on trying to design it like a web-page to the detriment of usability.  Even if they were "web sites" they would violate a few design practices :-).  I think at some point we'll need to remind them to watch their Community Manage Reports and if they see a dip in traffic, consider the design as one explanation. 

               

              For anyone else starting out, I would suggest going the route you did and then consider opening it up for more maybe later.  But start more restrictive at first.

                • Re: HTML Widget "policy"
                  nbussard

                  We require anyone using javascript to create it and test it in UAT. It's easy for us to enforce this because we also restrict scripts to admins only, but at least you could offer that option when people inquire.

                   

                  Additionally, we encourage people who create fancy javascript pages to publish their code and an explanation of how to use it, both so we can see what they did in case they leave the company and we need to fix it, and so other people can benefit from what they learned. The extra added bonus to this is that others are more likely to want to re-use existing code, which ultimately leads to more uniformity and a decrease in the My Space effect.

                   

                  It may also be prudent to explore whether un-granting the script permission truly is a bell that can't be unrung. Since adding this type of code can wreak all kinds of havoc with your site, you may find yourself forced to "unring" it under emergency conditions. At least if you understand the implications ahead of time, it will make it easier should you find yourself in need of restricting it.

                   

                  Hope that helps.

                  • Re: HTML Widget "policy"
                    nicholas.cafaro@rbc.com

                    Excellent point.  We are in the process of designing our internal community page at an organization with 80K employees and already we are really facing push back from Enterprise Support for this very reason.  You will have much more success with support groups if you stay within bounds of the "out-of-the-box" widgets.

                • Re: HTML Widget "policy"
                  Melissa.Rosen

                  We are running v5.  We take the same approach as you, Laura-- folks are welcome to use html if they have those skills, but our team does not support, teach, or troubleshoot html. Also, by ruling of a different team (information security), javascript is not allowed-- it is stripped out if someone tries to use it. There is sort of a workaround using iframes (the script actually lives somewhere else and is called up via the iframe code). That said, most people don't seem to pursue the workaround.

                  • Re: HTML Widget "policy"
                    ycheong

                    We're in exactly the same boat, i.e., not enough manpower to help with everyone's group / space design.

                     

                    Fortunately, we have a handful of people who have been very willing to share code (HTML, that is, not Javascript since that can only be placed by admins) and we created an HTML group in our Jive instance where users can ask questions and swap code. (Mostly this means copying existing code and making a few tweaks.) The main problem now, two+ years in, is that people who have no coding experience whatsoever see some of the nicely-designed places and just want us to do all the work. We're telling users that if they're willing to learn the basics, they can go to the HTML group; if not, they can use the out-of-the-box widgets. Unfortunately, many users go all starry eyed over the pretty designs and completely ignore features and function! Alas ...

                    • Re: HTML Widget "policy"
                      laurabecraft

                      These are all  very helpful responses.  It's interesting to see the different approaches and if I can persuade our team to consider changing our policy, these are good alternatives.

                       

                      I want to update my previous comment "If they are using Javascript, and there is something wrong, it can cause the page to "lock up" and not allow you to edit it.  Apparently, in the previous version of Jive (we are on 6.01 now), our admin could do something in the console and release the page.  That seems to have changed with this version so it's resulting in more calls to us = more tickets to Jive."

                       

                      We received a response back from Jive, and it appears "we have met the enemy and he is us".  This was Jives response regarding our issue: 

                      Starting in 5.0.4 all HTML widgets are wrapped in an iframe which prevents the overview page from becoming stuck (Upgrading to Jive 5.0.4 If Your HTML Widgets Use JavaScript). However, in 5.0.5 we introduced a property where you can disable this feature (html.widget.safemode.enabled=false). Looking at your system properties you currently have this disabled. If you would like to prevent this from happening in the future I would recommend either re-enabling the system property (it does require a restart for it to apply) or creating a separate test group where you can verify the HTML code placed in the widget does not render the overview page in-accessible.

                      Yikes!  So  I need to dig further into why our team disabled this.

                        • Re: HTML Widget "policy"
                          nbussard

                          There are pros and cons to having it that are explained in that link, mainly that I could break existing functionality, but it sounds like in your case (lots of unknown authors experimenting across groups) it may be helpful to have it enabled. We have it disabled, and I believe it was because, as the documentation states, "You also can't use the Javascript in a widget to manipulate HTML elements outside the widget frame." Several of our custom widgets needed to have that enabled. Good luck!

                        • Re: HTML Widget "policy"
                          moman

                          One of the things that makes this challenging, too, is that the Jive-provided description within the widget itself reads: "Renders your HTML with JavaScript or even CSS." So even if JavaScript is disabled, users get a message telling them that they can use it. Has anyone found a good way to provide the appropriate messaging to users?