feat: improve webapp, improve mobile player, improve design ✨

[IEduStu]

Stremio is awesome and I use it a lot, so I wanted to add the missing features that I think would make its PWA on mobile (and on iOS and iPadOS in particular) first-class.

Changes

• Improved the look and feel on mobile devices
• Improved the look and feel of the mobile PWA app - it now feels much more like a native app on iOS
• Improved the design of the mobile app and desktop app with more immersive navigation bars
• Fixed and issue where the mobile PWA app ignored the system navigation bar and notch, which made some UI elements not easy to reach
• On mobile, the player:
  • Shows a play/pause button on the middle of the screen and behaves like the YouTube/Netflix player
  • When double tapping on the right/left side of the screen it skips 10 seconds or goes back 10 seconds instantly
  • Swiping up on the video enter full screen, and swiping down exits full screen
  • There's a new button in the 3 dots menu to open the video stream in nPlay (on iOS only)
  • On iOS, the volume slider is hidden, as there's not way to actually change the volume of a video using a <video> tag
  • On iOS. a new Airplay button (needs https://github.com/Stremio/stremio-video/pull/74 to work), and a button in the 3 dots menu to open the vidoe in nPlayer
  • On iOS, on landscape, there's a small padding in the bottom to make sure the video is not rendered under the navigation bar, and added a workaround to turn the navigation bar black on some devices (testing on a physical device is needed to add this workaround to every device, so I've made sure it only works on the devices I could test this on)
• Various CSS bug fixes
• Fixed a bug where the maskable icon was overwritten in the build by the regular icon
• On the player, in the 3 dots menu, added a button to copy the video download link
• Added dev container to the repo to make it easier to start a development environment

Live demo: https://iedustu.github.io/stremio-web/

Related pull requests I created for this effort

• https://github.com/Stremio/stremio-video/pull/74
• https://github.com/Stremio/stremio-translations/pull/796

Devices and platforms tested with these changes

• macOS:
  • Arc
  • Chrome
  • Firefox
  • Safari
• Windows:
  • Chrome
  • Edge
• iOS:
  • Safari
  • PWA (Clicking on Add to homescreen in the share menu in Safari)
  • Chrome
• iPadOS:
  • Safari
  • PWA (Clicking on Add to homescreen in the share menu in Safari)
  • Chrome
  • Tested all of these with an external trackpad and without an external trackpad connected
• Android:
  • Chrome
  • PWA

Screenshots

iOS web app

New mobile player design

New mobile player design on iOS

Mobile web

Desktop web

---

Screenshots of how it looked before (for reference)

iOS web app

Mobile player

Desktop web

[CLAassistant]

All committers have signed the CLA.

[tymmesyde]

Hi, thank you for your PR As your PR contains a lot of various things, can you please segment your changes in separate PRs? Like one for fixes or a feature, UI changes, UX changes, etc.. This will make the review easier and there is potentially some changes that we don't want to include in the project

[IEduStu]

It wouldn't be practical to separate it into multiple PRs as all the changes affect each other and dependant on each other. For example, the handling of the notch gaps and adaptations for the mobile webapp are intertwined across all the other changes, I'm not sure how can I separate them.

I wrote the long list to detail all the changes and make it easier to CR, but essentially there are 3 main changes:

• Improvements to the mobile webapp to make it feel native
• Improvements to the player on mobile to make it feel similar to YouTube/Netflix
• Infra changes that I made to make it easier for me to develop all of this, so I left it as part of the PR

You can try the live demo of this here: https://iedustu.github.io/stremio-web/

[tymmesyde]

It wouldn't be practical to separate it into multiple PRs as all the changes affect each other and dependant on each other. For example, the handling of the notch gaps and adaptations for the mobile webapp are intertwined across all the other changes, I'm not sure how can I separate them.

I wrote the long list to detail all the changes and make it easier to CR, but essentially there are 3 main changes:

* Improvements to the mobile webapp to make it feel native

* Improvements to the player on mobile to make it feel similar to YouTube/Netflix

* Infra changes that I made to make it easier for me to develop all of this, so I left it as part of the PR

You can try the live demo of this here: https://iedustu.github.io/stremio-web/

I understand that it would not be practical to separate them, we will discuss which changes we want to keep or not before you do that All your changes are not dependent with each other As you listed in your comment, you updated the style of the tabs, server warning, etc .. You also made changes to the player UX by adding a new component for mobile controls, etc... And also made various fixes Those can be different PRs and are not related

[TRtomasz]

on addons page there is shade visible from the top and over first element, it should only add shades once someone starts scrolling i think firefox does not like this new effets on the discover, it produces some artifacts

[kKaskak]

Issues found:

1. Keyboard does not open when trying to log in on PWA (iPadOS iPad Pro 11") (sometimes it opens).

2. App bugs out a lot while switching routes or simply trying to open the keyboard, to leave the app and enter again.

3. One letter in the redesigned pop-up for the streaming server is only partially visible (padding fix required).

4. There is an issue with shades on Firefox (tested on MacBook Pro M1 the newest macOS Firefox v.123.0.1 (64-bit))

https://github.com/Stremio/stremio-web/assets/117831817/6ba83818-303d-4ced-8c8f-74f69570a461

5. Play / Resume icon on the bar is missing? Users might be confused why it was removed.

6. Search route preview is broken

7. Settings page section buttons are broken

https://github.com/Stremio/stremio-web/assets/117831817/287f7cdd-d2a1-4be1-a731-d93579259265

8. Top bar color is broken see before and after photos

Before

After - (here the app broke after trying to swipe up to exit it)

Good points:

1. Shades look nice, but we need to ensure cross browser support. In some case scenarios items that are object to shades (top & bottom) are almost invisible which we should take into account.
2. Redesigned MetaDetails page looks fresh, tho also in some case scenarios readability might be poor. (it heavily depends on the background image, and we have a different one for each movie / series)

Please keep in mind that this is just speaking from the user perspective. I did not review any of the code yet, so there was no code quality review done. Next time please split such large PR into multiple as @tymmesyde mentioned already, addressing one issue / new feature at a time. Large PR are way more time-consuming to review.

[IEduStu]

@TRtomasz I fixed both your comments, let me know if you still see flickers in Firefox after the fix

[IEduStu]

@kKaskak I fixed all your comments except 5. In the screenshot you attached the pause button is in the middle of the screen, just like in YouTube/Netflix. This UI looks like that only on mobile devices; I included tablets in this since this is how it looks on YouTube and Netflix apps on my iPad.

Let me know if you still encounter any more issues after my fixes.

[kKaskak]

@kKaskak I fixed all your comments except 5. In the screenshot you attached the pause button is in the middle of the screen, just like in YouTube/Netflix. This UI looks like that only on mobile devices; I included tablets in this since this is how it looks on YouTube and Netflix apps on my iPad.

Let me know if you still encounter any more issues after my fixes.

https://github.com/Stremio/stremio-web/assets/117831817/223ff8e8-7693-4db2-8ffb-6096ec76d19d

This is still not fixed. After clicking an element, it correctly navigates to it, but there is a ref issue and the active element does not change.

https://github.com/Stremio/stremio-web/assets/117831817/0800c775-b070-4e8e-ab21-bc17c607ce8c

[kKaskak]

Other than that good job 👍🏼

[kKaskak]

The last one seems to still not focus as it should but this I believe is a specific page zoom issue

https://github.com/Stremio/stremio-web/assets/117831817/e51aa3b1-686c-4b8c-b93e-beba8b8c5962

[IEduStu]

@kKaskak Thanks for helping me solve these issues :) Can you please check again if the issues are solved on your device now?

I couldn't reproduce the issue with the black gap and white line at the top on my iPad, so I made a change that I think may help but I couldn't verify it. If you can record how you reproduce it it could help me a lot.

[kKaskak]

Why would we want to disable all hover effects on PWA? Why would we remove the labels on the navbar? Why would we make it harder to actually click on navbar buttons?

[IEduStu]

@kKaskak I disabled the hover effects only when you you a "coarse" device, AKA a finger on a touch screen, since without it this leaves the hover state on the button after you click it until you touch something else, which isn't the behavior of native apps.

I haven't removed the labels on the navbar, the functionality is the same as before. What I did do is to increase the text contrast a bit when the navbar is at the bottom without showing the navbar labels when the navbar is on the left of the screen (like it was before).

I didn't make it any harder to click navbar buttons; the effect of the clicks is now even faster than it was before which makes it easier to navigate the app.

Try the latest build and see firsthand how it looks and behaves. This URL updates with every change I make, you can install it as a PWA and see it in action.

[kKaskak]

@kKaskak I disabled the hover effects only when you you a "coarse" device, AKA a finger on a touch screen, since without it this leaves the hover state on the button after you click it until you touch something else, which isn't the behavior of native apps.

I haven't removed the labels on the navbar, the functionality is the same as before. What I did do is to increase the text contrast a bit when the navbar is at the bottom without showing the navbar labels when the navbar is on the left of the screen (like it was before).

I didn't make it any harder to click navbar buttons; the effect of the clicks is now even faster than it was before which makes it easier to navigate the app.

Try the latest build and see firsthand how it looks and behaves. This URL updates with every change I make, you can install it as a PWA and see it in action.

Could you explain in more detail why the decision to lower accessibility on PWA by removing all hover effects would benefit our project? Also labels are there for a reason when you tap / hover the navbar buttons.

[IEduStu]

@kKaskak When you move a mouse over an element it triggers :hover, when you tap an element on a touchscreen it also triggeres :hover and it stays like that until you tap outside the element. The handling of :hover for a mouse and a finger on a touchscreen should be different, since on desktop you need to have an effect when a mouse is over a button for example, but on a touch screen there's no really such a thing as a hover - you can either not touch the screen or do touch the screen (in which case you'd trigger :active for as long as the finger is down on the screen, but unlike :hover, when you lift the finger from the screen then :active will end).

:hover works the way it does on touchscreens since there are some websites that when you hover over a button it can open a submenu, using only CSS, and emulating :hover is required for this to actually work on mobile. Usually, when you define :hover for an element you intend to only change its design when the user points the mouse over it, but not trigger for what technically :hover does on mobile.

On native mobile apps (for example), after you click a button, there's no effect left on it after you lift your finger off the screen, so a PWA used on a touchscreen should behave the same.

In the CSS code that I changed, you can see that I wrapped only :hovers with a media query like this:

@media (pointer: fine) {
    .my-class:hover {
        background-color: rgba(0, 0, 0, 0.24);
    }
}

A coarse pointer is a touchscreen, and a fine pointer is a mouse (for this case), so this CSS code makes sure that only on devices where the primary input device is a mouse :hover will work.

This CSS code is meant to preserve the current behavior for desktop devices and make the behavior of elements on mobile devices more intiuitive and native-like.

The only case where it may feel different than what you're used to is when you use a mouse on a touchscreen device where mouse is not the primary input device, like an iPad, in which case the hover effects will no longer be visible even when you use a mouse. If you'd like to enable the hover effect on touchscreens when a mouse is connected to the device (like when using a mouse or a touchpad with an iPad), it's possible to do by changing the media query to @media (any-hover: hover) { ... }, but this may look more like a bug when the user uses their finger and not their mouse. Let me know if you'd like it to work like that and I'll make the change.

I'm not sure what you mean about lowering the accessibility of the project, as I haven't made any change that hides visible information, and focus styles are still in place just like before.

[kKaskak]

@kKaskak When you move a mouse over an element it triggers :hover, when you tap an element on a touchscreen it also triggeres :hover and it stays like that until you tap outside the element. The handling of :hover for a mouse and a finger on a touchscreen should be different, since on desktop you need to have an effect when a mouse is over a button for example, but on a touch screen there's no really such a thing as a hover - you can either not touch the screen or do touch the screen (in which case you'd trigger :active for as long as the finger is down on the screen, but unlike :hover, when you lift the finger from the screen then :active will end).

:hover works the way it does on touchscreens since there are some websites that when you hover over a button it can open a submenu, using only CSS, and emulating :hover is required for this to actually work on mobile. Usually, when you define :hover for an element you intend to only change its design when the user points the mouse over it, but not trigger for what technically :hover does on mobile.

On native mobile apps (for example), after you click a button, there's no effect left on it after you lift your finger off the screen, so a PWA used on a touchscreen should behave the same.

In the CSS code that I changed, you can see that I wrapped only :hovers with a media query like this:

@media (pointer: fine) {
    .my-class:hover {
        background-color: rgba(0, 0, 0, 0.24);
    }
}

A coarse pointer is a touchscreen, and a fine pointer is a mouse (for this case), so this CSS code makes sure that only on devices where the primary input device is a mouse :hover will work.

This CSS code is meant to preserve the current behavior for desktop devices and make the behavior of elements on mobile devices more intiuitive and native-like.

The only case where it may feel different than what you're used to is when you use a mouse on a touchscreen device where mouse is not the primary input device, like an iPad, in which case the hover effects will no longer be visible even when you use a mouse. If you'd like to enable the hover effect on touchscreens when a mouse is connected to the device (like when using a mouse or a touchpad with an iPad), it's possible to do by changing the media query to @media (any-hover: hover) { ... }, but this may look more like a bug when the user uses their finger and not their mouse. Let me know if you'd like it to work like that and I'll make the change.

I'm not sure what you mean about lowering the accessibility of the project, as I haven't made any change that hides visible information, and focus styles are still in place just like before.

We'll discuss this with the team and I will give you a final answer.

[IEduStu]

I've updated the screenshots to the latest version of this branch and detailed all the platforms and browsers I've tested this on to make sure everything works correctly.

If you still find issues, let me know so I can fix them, but I think that the current version of the PR is stable and covers all the platforms and browsers I could test this on. I've been using it daily for a while now to spot all the issues I could find and I think I got them all.

I've attempted to maximixe the capbilities of Safari on iOS and iPadOS, and Chrome on Android, to make the PWA feel as native as possible on mobile devices, while making sure the desktop version also works great.

[kKaskak]

I started to extensively test your PR on my android device as a PWA. One thing I noticed is that local search no longer appears under search history. I will be testing it by simply using, the coming days. Be patient as I might be slow to review everything. Have a nice weekend

[kKaskak]

Hi. I noticed a small offset issue in the back button in the player route. Can you fix that?

[kKaskak]

https://github.com/Stremio/stremio-web/assets/117831817/24a694e7-8f12-4c78-925b-515a9935d190

[IEduStu]

@kKaskak I couldn't reproduce this issue where the back button jumps up. How can I get to a situation where it happens?

[kKaskak]

@kKaskak I couldn't reproduce this issue where the back button jumps up.

How can I get to a situation where it happens?

As I previously mentioned when you enter the player it's not in the same position as on other routes.

[IEduStu]

I see what you mean. On desktop it's on the same place, but on mobile I've shrunk the height of the header a bit to make more space available to touch the video area to hide the play/pause overlay. This was very beneficial for some smarphone screen sizes I tested this on, but is irrelevant when the screen is tall enough, so I've added a fix to only shrink the header this way when the screen height is not tall enough.

[kKaskak]

There is one more thing that should be adjusted. The top navigation bar in iOS PWA now has a default white color which isn't the case on /development

[IEduStu]

I've just installed the PWA app from this link on my iPad and there's no white bar at the top. The white bar was an issue with earlier versions of this PR, so if you installed the PWA with an older version you have to reinstall the PWA it fo fix it.

[gazer000]

On the ModalDialog styles, the .buttons-container custom style for mobile screen should be nested under .modal-dialog-content otherwise the modal's button list flex direction stays row and texts will clip on mobile screen

[kKaskak]

I've just installed the PWA app from this link on my iPad and there's no white bar at the top. The white bar was an issue with earlier versions of this PR, so if you installed the PWA with an older version you have to reinstall the PWA it fo fix it.

I'm sure I'm running the latest version, and it still happens. I also installed a new version to be sure 100%, it still shows up.

[kKaskak]

On the ModalDialog styles, the .buttons-container custom style for mobile screen should be nested under .modal-dialog-content otherwise the modal's button list flex direction stays row and texts will clip on mobile screen

Yes that's true. Thanks for mentioning it.

[IEduStu]

@kKaskak Can you please share with me what version of iPadOS do you have installed and whether there are custom accessibility features enabled on your iPad? I couldn't reproduce the issue with the status bar color that you experience, but I've made some change that might fix it, althougt I cannot test that it does something on my iPad.

Essentially, this PR changes the meta tag in the head of the HTML to:

<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">

Which according to Apple's documentation makes the status bar transparent. Then, I made sure to cover the area of the status bar with CSS to make the gradient of the background of the app go under the status bar.

This is how it looks on my iPad Pro 12.9" with iPadOS 17.4.1:

BTW I also fixed the issue with .buttons-container in ModalDialog on mobile

Update: I just tested it again with my iPad updated to iPadOS 17.5.1 and I still couldn't reproduce the issue with the status bar color