Problems with responsivnes and Find the words

Submitted by SubjectX on Thu, 06/18/2020 - 12:44
Forums: 
Bugs in content types

Greetings,

using Find te words type of content with mobile devices seems to break the responsive design.

For example: https://h5p.e-cho.org/index.php/poklici-pod-zemljo/

Works fine on desktop Chrome, its 11x11 grid.

Looking at the narrow mobile display, it doesnt show full width, cuts off after 6th or 7th column. Height and rows remain full (11).

How can I fix that?

Regards, Anze

 

BV52's picture

BV52

Thu, 06/18/2020 - 20:49

Hi Anze,

Thank you for reporting this. Since find the words is a community contributed content type I suggest that you cotact the developer directly through his git repository.

-BV

otacke's picture

otacke

Thu, 06/18/2020 - 21:18

Hi all!

Just summing up some different threads.

The scrolling problem is a common issue among some content types - at least Drag&Drop, Drag Text, Image Pairing and obviously Find the Words. Since H5P is inside an iframe, the algorithm inside the content type cannot know its real position when dragging without some extra checking. That "extra checking" would need to be implemented and it won't be perfect and would even need some more effort to make it work when content is embedded. I'll gladly propose a solution if the H5P core team agrees that this is quite an frequent problem that needs fixing.

Best,

Oliver 

BV52's picture

BV52

Fri, 06/19/2020 - 18:55

Hi Oliver,

I've informed the core team about this.

-BV

falcon's picture

falcon

Tue, 06/23/2020 - 14:13

I'm sceptical of solutions that require a script from us in addition to the iframe in order to work. If this can be solved without our own script running on the third party site I'm happy, but if a script is required for this we'll at least need to be able to check if the script is there or not so that the content type can be designed to work also when such script is not available. For instance if a content type wants to have an always visible navigation bar on top it will be possible with such a script probably, but the content type needs to work when the script is not there as well.

otacke's picture

otacke

Tue, 06/23/2020 - 17:13

I agree that a solution similar to h5p-resizer.js is not desirable as it would also have to put into the embed code. Ideally it would work out of the box, but I am not sure if the problem can be solved without some extra script - at least I didn't find a good way to do it. I'd love to learn more though if anyone knows better tricks than I do.

Currently, given such a script that allows scrolling, I believe the worst case would be that

  • it works when on the same server (with or without the script),
  • it works when embedded and the script is present, and
  • it does not work when embedded somewhere and the script is not present.

You're not worse off than today, although maybe this "inconsistency" in behavior could be interpreted as worse.

falcon's picture

falcon

Mon, 06/29/2020 - 21:52

I think the potential problem would be that content types are developed in a way that assumes that the ability to make things sticky on top of something is always possible for instance, and that the content types break if this is not possible. As long as it is easy for the content types to check if these extra features are available or not and we document that it is very important that we have a good fall-back in all content types I'm happy.

otacke's picture

otacke

Tue, 06/30/2020 - 13:51

I understand and agree. Would some variable like H5P.scrollParentSupported be sufficient? Content types could check it just like H5P.fullscreenSupported.

I also agree about documentation. That's a domain that H5P is falling behind a little in general, IMHO.