Adapt Learning Community: Inview and components completion

Hi,

A query about how (and when) basic components (graphic, text) are set to complete. These are tied into the Inview library in core and currently set to complete as soon as a single pixel is visible on screen. This becomes very apparent when the page level progress extension is installed.

Would it not make more sense for a basic component to set to complete only once all of it has been visible on screen? This is what Kineo clients have been requesting over the past months with Adapt projects. Especially with regard to the text component.

Are there any current plans to review how this works? We have developed extended inview functionality to take account of top and bottom before setting completion. We would be happy to discuss pushing this back into core if this modified functionality is something that is considered desirable.

Hello,

Just seconding what you’re saying Gav. I’d recommend that the OS branch implements the inview approach as you describe.

We’ve had several instances of pages that, upon load, are setting text and graphics items sitting in bock 2 as complete because a few pixels at the top of the component are in view. Meanwhile components in block 1 which require some form of interaction are not flagged as complete so you get something like this in the page level progress bar:

1.Accordion title: Incomplete

2.MCQ title: Incomplete

3.Text title: Complete

4. Graphic title: Complete

5. MCQ title: Incomplete

6.Graphic title: Incomplete

This is a bit daft to my mind and something we need to try and avoid.

Thanks,

Paul

Show parent | Reply

Hey,

I think the way in-view is implemented isn't that great at the moment. But I'm not too sure how reliable the old setup is.

Take for instance I'm on a mobile device that stops javascript on scroll - I have some large padding on the bottom of a text component. The component's top is visible but the bottom element isn't. But all the text is visible - I scroll down the page quickly on my device and miss the bottom element being inview. I've read the text but because the bottom element wasn't in-view it wasn't set to complete.

Although this can happen in rare cases where styling is different - I'm not sure having it setup to fail because a theme looks different is the right approach.

Have we thought about not allowing any component to be set to ready until after the page is ready. This way you don't get page level progress updating before elements are visible. I also think the component should be responsible for setting how it should be set to in-view. Would be nice if a component could set the element - which would normally be the .component-widget. This way it's more flexible and not tied down into core code.

There's also an approach of having all the elements in a page set to _isVisible:false as a default. The way Adapt is now setup stops any component being set to complete if it's not visible. This would stop components being set to complete even if they are not shown but before the page is ready

On another point - I think each page element needs to trigger an in-view event. This would mean we can build plugins around whether certain elements are in-view and when they go out of view. I can see the power of this already with playing videos in the background based upon if an article is in-view.

Also, there's some great plugins that enable effective inview triggers

Scrollspy - used by bootstrap

viewport - looks good for all types of viewports

inview - the updated version has some great new features

Thanks,

Daryl

Show parent | Reply

Hi D,

"Take for instance I'm on a mobile device that stops javascript on scroll - I have some large padding on the bottom of a text component. The component's top is visible but the bottom element isn't. But all the text is visible - I scroll down the page quickly on my device and miss the bottom element being inview. I've read the text but because the bottom element wasn't in-view it wasn't set to complete."

That is pretty unlikely and would only happen on a page viewed on mobile, with a text/graphic component in the final block of page. We were getting the issue I described on desktop and tablet on page load and we received push back from clients regarding the functionality until we changed it (and we've had nothing since).

If there is a better way of achieving the same outcome then I'm keen to look at it, but as it currently stands it won't work for our existing client base so we'll have to change it for internal use and that seems a bit of a shame.

Maybe I'm missing a point you make though - do the ideas you describe specifically address the issue I highlight in the post above?

Cheers,

Paul

Show parent | Reply

Thanks Daryl, for the detailed response.

I agree that the way inview is implemented in Adapt at the moment isn't great - hence why we have forked it as it isn't fit for our purposes as it currently stands. All 3 of the plugins you reference look good, and would offer a better solution for us in that they track when a component enters and leaves the viewport. Any of these plugins would be preferable solutions to the version currently used in core. Is there a plan to update to use one of these? re. your point about mobile devices that stop javascript on scroll - I'm slightly confused that you have raised this as a concern yet have went on to suggest javascript-based plugins that track scrolling. Maybe I'm missing something?

Essentially what we have done with our forked inview is implement some of what these plugins are offering. In terms of reliability, we have been using this version for months across numerous Adapt projects without a hint of a problem. It has went from being a major issue with clients to simply not being an issue.

I take your point about isVisible and see that it works. However, the point that Paul raises still happens regardless once the page is ready. The point is that components set to complete once a single pixel is visible. This happens after the page is ready. I don't see _isVisible as relevant here in terms of a solution to the partly-inview -> set to complete issue.

I think we are in agreement that the current solution in Adapt is not great. Happy to discuss further on how this can be improved in core, and contribute if that is helpful.

Show parent | Reply

Hey,

My point about waiting until page is ready fixes another issue that has not been fixed yet, but would better enhance the users experience. Take a typical Adapt page and the download speed. If this takes 2 seconds to download all the images on the page, then the text component that is not visible to the user but is in fact set to inview - page level progress will say it's complete. But by waiting for the page to be ready and then checking this, all components won't be set to complete giving the user the correct feedback in page level progress.

Paul - the situation I talked about will probably only affect mobile devices but could even affect iPads or other devices that stop javascript on scroll. On quite a lot of our courses recently we're adding a lot of space between elements and this is my concern. I have no problem with the way it's implemented in our older branch but we can't put something in that has a chance of not firing on some devices.

The reason I suggested other plugins is not about the scrolling issue but more with these are fully tested libraries that are used by thousands and have massive performance enhancements. The current inview plugin isn't support anymore. They also have some great features that we could use throughout core.

What I'd like to see is more flexibility in how inview is triggered - we should be giving component creators the choice of what element should be the inview trigger. Although I feel we should have a default of .component-widget. When we put plugins into core we should be looking at flexibility and what it can offer other plugins. For instance scrollspy enables us to specify what element we are tracking - we can use it for components but also plugins can use this feature too.

Thanks,

Daryl

Show parent | Reply

Hi,

I still don't think the situation on tablets/mobile is as common as the one we've had to deal with countless times on desktop with real clients - and desktop is still the primary platform for course delivery.

Basically, if it can be configured so it fixes the problem I highlight then I'm fine with it. If it doesn't we're still at square one. Clients don't want text and graphics flagging as complete on a page before they can be read by the learner.

With regards to what plugin we use/page load etc, I don't mind. It's the specific problem with the inview functionality that I'm interested in.

Tar,

Paul

Show parent | Reply

Thanks Daryl.

Good to know that you're of a mind that inview should be improved from how it currently works. Once there is a plan in place to implement a solution then we'll be happy to contribute resources, so long as it addresses our requirements outlined by Paul. Until then we'll continue to use our own forked version to meet our clients' requirements around completion. If we get time then we can investigate using one of the plugins you listed.

Show parent | Reply