You are viewing limited content. For full access, please sign in.

Question

Question

Is there any way to automatically stream a video via weblink?

WebLink Version 10
Updated February 26, 2021
asked on February 25, 2021

I've been hammering on the message board in the Digital Transformation HQ at Empower, so I decided to take a break and post my last question here.

I like the feature in weblink that allows video streaming; we use it in a policy review process we've built.  The only improvement I'd like to see is some way to configure a link such that it directly opens and plays the Weblink entry's attached video file.  Can anyone think of any way to do that?

0 0

Replies

replied on February 25, 2021

Hi Sean,
something like this isn't supported out of the box currently. However in a self-hosted solution you could add a custom click event on the play button in the DocView page when user opens the page and this would show the video. 


Here is sample code you could add to DocView.aspx if you pursue this option. Note this would only open the video player not set it to play directly but its a step in that direction.
 

 <script>
        var maxTries = 5;
        var tries = 0;
        $(document).ready(function () {
            var clickOnPlayButton = function () {
                if ($("#STR_STREAM").length > 0) {
                    $("#STR_STREAM").click();
                    return;
                }

                if (tries < maxTries) {
                    tries += 1;
                    setTimeout(clickOnPlayButton, 1000);
                }
            }

            clickOnPlayButton();
        });
        
    </script>

 

3 0
replied on February 26, 2021

I'm not really a fan of the retry technique that a lot of people use to wait for weblink to fully load. I've had much better success using mutation observers, especially if you're going to be executing multiple "rules". Yes, it's more code, and perhaps more difficult for a javascript novice to understand, but, IMO it makes for something easier to maintain in the long run. It also allows your code to execute at the speed of the browser, instead of waiting for arbitrary timeouts.

Something like this would work:

const targetNode = document.getElementById("docPage");
const config = {
    childList: true,
    subtree: true
};

const callback = function (mutationsList, observer) {
    for (let i = 0; i < mutationsList.length; i++) {
        const mutation = mutationsList[i];

        if (mutation.type == "childList" && mutation.addedNodes) {
            customizeElementsOnAdd(mutation.addedNodes);
        }
    }
}

const observer = new MutationObserver(callback);
observer.observe(targetNode, config);

function customizeElementsOnAdd(addedNodes) {
    for (let i = 0; i < addedNodes.length; i++) {
        var node = addedNodes[i];

        clickPlayButton(node);
    }
}

function clickPlayButton(node) {
    if (node.id !== "STR_STREAM") {
        return;
    }

    node.click();
}
1 0
replied on February 25, 2021

I haven't worked with videos in WebLink yet, but depending on how designed I imagine you could pull this off by adding some custom JavaScript to the page.

Let's assume adding a custom query string parameter won't break the page, and that there's a way to programmatically click the "play" button via JavaScript...

You could add something like "?autoplay=true" to the end of the URL.

Get into the .aspx file for the the video viewer and add a script at bottom to look for that value when the page finishes loading.

var params = new URLSearchParams(window.location.search);

if (params.has('autoplay') && params.('autoplay').toLowerCase() === 'true')) {
    // do something
}

Based on my experience customizing WebLink pages, this code would probably execute before the file actually loads completely, so it would take some experimentation and digging through the structure of the page in the browser to get it all sorted out, but in theory it should be possible.

You might need to use timeouts to wait for the video to be loaded before you can click play, or if the player exists in a frame maybe you could put code in there instead.

Not really the answer, but hopefully it gives you some ideas that may lead somewhere.

 

0 0
View 6 previous replies
replied on February 25, 2021 • Show version history

All major browsers do some form of video autoplay blocking (not to mention plugins and extensions), so I would think twice before spending a ton of energy on this. wink

1 0
replied on February 26, 2021 • Show version history

YouTube, Empower 2021's on-demand sessions, the sites for pretty much any streaming service, and plenty of other things show that video can be auto played in modern browsers without any issues under the right conditions.

The vast majority of autoplay blocking efforts are directed at ads.

Chromium-based browsers will ignore the autoplay attribute for HTML video elements, but that's assuming you're using the video tag and even then it is still allowed if the autoplay starts muted.

0 0
replied on February 26, 2021

I think I'm going to side with Ege on this one. As a user, I absolutely hate autoplay videos and spent non-zero time digging through browser options to kill that dead.

1 0
replied on February 26, 2021

Thanks for the replies!  I probably won't spend a ton of energy on this; it was simply requested by some of our users.  Jason - Does Weblink have accessible / editable .aspx pages?  Are those accessed from the serer side?

0 0
replied on February 26, 2021

Oh, I do get why it's requested and it does make sense in some cases. If I open a page to read an article and it just starts auto-playing video, that is annoying to me. But in a case where the only thing is the video, autoplay would likely be fine.

0 0
replied on February 26, 2021 • Show version history

Hi Sean, if you go into the web files on the server/directory where WebLink is installed you can make edits to the pages to add customization.

However, the disclaimer would be that this should be more of a last resort; it is good practice to back up the original file(s) just in case, and to keep in mind that future updates could break things.

As an example, I copied the DocViewer.aspx file and made a DocViewerLite.aspx version with lot of modifications specifically for embedding documents in LF Forms.

When we updated to 10.2 that page stopped working because there were some pretty substantial changes in the 10.2 update.

To fix that all I really had to do was copy the new DocViewer.aspx and add the same modifications to the new version, but it's a good example of how these kinds of modifications can create extra maintenance.

If you do decide that something you want to do absolutely requires modifying those files, then test thoroughly, backup the original files, and document any customizations in case they get wiped out or broken by updates.

1 0
replied on February 26, 2021

Hi Miruna,

I 100% agree. Drives me insane when I open a page and have to scroll through to try and find whatever video is playing in some far flung corner of the site.

In the end I think it really comes down to context and user intent. In general autoplay is widely abused and undesirable; the few exceptions would be, like you mentioned, when the video is the only content and the user is actively seeking it out.

2 0
replied on February 26, 2021 • Show version history

YouTube, Empower 2021's on-demand sessions, the sites for pretty much any streaming service, and plenty of other things show that video can be auto played in modern browsers without any issues under the right conditions.

It's a bit of a complex issue, but in the case of Chrome, it comes down to something called the Media Engagement Index (MEI). This measures the user's propensity to consume media on a given site. Example factors used to calculate it are the size of the video, whether the user has played videos (with sound on) on that domain for at least X seconds before, and others. These are stored by Chrome and you can view yours here if you're curious: chrome://media-engagement

Aside from MEI, Chrome also cares about whether the user has interacted with the domain, such as by clicking or tapping. If they haven't, and the MEI is below a certain threshold, the browser will autoplay the video, but without sound.

Firefox, on the other hand, cares only about whether the user has interacted with the page. If not, it will allow autoplay but also without sound. This has been the case since 2019 I believe.

This is why streaming sites like YouTube don't have issues with autoplay, because chances are the user has visited them and interacted with them before. That assumption doesn't necessarily hold for WebLink though. If the user is inside weblink, then clicks on a video file, that video can probably be autoplayed by adding the "autoplay" html attribute to the media tag. But if they are arriving at the video directly from another location (i.e. by clicking a link to it), then the video might still autoplay, but will probably be muted.

All the above ignores things like user preferences on the browser, and any plugins. The bottom line is that Google itself explicitly says "don't ever assume a video will autoplay" when they talk about web developer best practices. smiley

1 0
replied on February 26, 2021

Hi Ege,

All good points. It's definitely a complex issue and context, user engagement, etc. are huge factors in determining what's "acceptable" or even just courteous.

One challenge for browsers is that there's "true" autoplay, but then there's things that are harder to detect like using JavaScript to just simulate a user clicking the button.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...