iv-org / invidious

Invidious is an alternative front-end to YouTube
https://invidious.io
GNU Affero General Public License v3.0
16.44k stars 1.85k forks source link

[Feature request] New Design Language #4113

Open Mennaruuk opened 1 year ago

Mennaruuk commented 1 year ago

Is your feature request related to a problem? Please describe. Recent attempts at building alternative frontends have shown that building clients that are both private-centric and aesthetically pleasing is possible.

Invidious is doing great at muddling the waters for Google and making it difficult to collect user data. However, the UI of Invidious remains outdated.

Describe the solution you'd like I think Invidious should switch to the latest iteration of Material Design. With eye-candy color palettes, bubbly rounded buttons, and catchy typography, Invidious can achieve the ultimate ideal of what us users want from a video sharing site: privacy combined with great design.

I understand Material Design is primarily for mobile. However, on desktop, Google's sites have been increasingly adopting Material You, such as Google Drive, Google Docs, and YouTube.

drive

docs

youtube

Non-Google sites using Material You include Bundled Notes:

BundledNotes

And it doesn't have to be Material Design, as long as it's a modern UI that makes use of color palettes, buttons, and whitespace to convey beautiful websites.

Describe alternatives you've considered Overall, it's hard to beat LibreTube. It features Material You and uses Invidious.

libretube

Newpipe works well, however, the design language is a bit outdated. The developers have stated their intentions to implement Material Design 3.

Other clients have already switched to Material You. Examples include Hyperion, Clipious, LightTube, and ViewTube.

This is not to forget the massive migration to the design language by hundreds of other FOSS apps, including Sync for Reddit, Seal, Mastodon, Signal, Wikipedia, Cloustream, NoFasel, and many, many more.

Design Mockup

rect555

unixfox commented 1 year ago

The issue is that we do not have any designers nor people expert in the frontend for improving the UI. We also want Invidious to still work on old devices, as it is relatively lightweight.

k0zyrev commented 1 year ago

Invidious is excellent in its simplicity: there is virtually zero need for javascript, and it is possible to customize it so there's basically no extra elements other than the video content itself. Call me old fashioned, but I don't think that modern design for the sake of modern design is necessary. I mean what problem would it solve?

That is if by modern design language you mean user-interactable website with lots of javascript. If you're only interested in some mild facelift as on your last screenshot, you could consider using Stylus extension for your browser and either create something on your own, or try looking for custom css styles for invidious (that was just the first thing that came up in search, there are more websites like this).

SamantazFox commented 1 year ago

I personally hate all that eye candy stuff. It's invasive and a bad UX, imo.

But my opinion doesn't matter here. What is needed is a way for users to select a theme, and for contributors to have an easy way to create and install themes.

Alternates themes aren't a thing yet because we're dealing with a lot of tech debt: some styles are still embedded in the HTML, some HTML structures are too simplistic, preventing the use of proper CSS styling, and some front-end stuff is tightly integrated with the back-end.

Whenever I'm touching the front-end, I've been trying to improve the situation. I've also been trying to resolve some accessibility issues, but that's quite some work, and I often need to learn new things along the way, so it takes time. My main goals recently have been to reuse interface components, and add class/id attributes to purge the HTML from inline styles.

Now the reason why we are a bit lagging behind is simple: as unixfox said, we're not (web) designers.

The (self-imposed) design constraint of being able to run without JS is also setting us back. We can't use a ton of JS to display nice buttons & pop-ups dynamically, tabbed content, lengthy drop down menus or anything fancy like that. When a new functionality is added, it must be integrated server side, and not client side. And sometimes, doing "fancy" stuff requires a bit of mental gymnastics.

I'm fully open to design changes, as long as the main theme is kept simplistic and accessible, and that everything is done mostly to improve the "common interface" with other themes.

auroraanna commented 1 year ago

@Mennaruuk Your mockup fails to pass some WCAG for color contrast:

Also, there is just so much whitespace underneath the title of the video. Lots of links and buttons are missing. I guess it's just a mockup but a new design would need to have to fit in all the current functionality.

I think the current design is fine. It is very functional. Not eye candy but it uses the space well, says what everything does, …

By having to use HTML elements for the UI, due to Invidious being serverside, accessibility is kind of forced which is nice.

I feel like having an eye candy UI might be distracting.

mk-pmb commented 1 year ago

@k0zyrev

you could consider using Stylus extension for your browser and either create something on your own,

I'm trying this for months, and it's harder than it should be. See #2837 "[Enhancement] Convey more structure in the DOM tree code."

@SamantazFox

We can't use a ton of JS to display nice buttons & pop-ups dynamically, tabbed content, lengthy drop down menus or anything fancy like that.

In a lot of cases, stuff like that is possible with pure CSS by abusing states of form elements. Feel free to @ me in issues that seem to need JS for UI and I might find a CSS way instead.

mk-pmb commented 1 year ago

On a general note, I'd love if the default invidious focusses on just abstracting YouTube, with very simple design that tries to avoid bloat as much as possible and is very easy to parse and repackage. Because I heard you like alternate frontends, so let me put and alternate frontend in front of your alternate frontend. :D

We have different audiences with different needs. We can never optimize for big fingered touch device users the same way we can for people with tiny displays using a high-precision stylus pointer device, and the people viewing it in a novelty browser on an ancient handheld gaming device.

The good thing is, we don't have to. There are lots of instances. We should make it easy for instance operators to pick the audiences they want, and optimize for them. An instance provider can probably even offer multiple layouts on different subdomains, while sharing profile and session data accross them.

"Easy to parse and repackage" will not only make it easier for users to locally optimize their view of their favorite instance, but also for instance operators to customize their instance's look and feel by injecting appropriate CSS, potentially JS, and where needed even 😱 webfonts.

aaferrari commented 11 months ago

What is needed is a way for users to select a theme, and for contributors to have an easy way to create and install themes.

For the first, you could implement a system similar to the one VidLii has at https://www.vidlii.com/themes where the identifier of the selected theme is stored in a cookie.

To create custom themes I imagine you could use a modular template system. For example, one way to do this would be to separate the frontend of the site into components (the player on one side, the comments section on the other, the related section as an extra component and so on). At the same time, each component could have subcomponents to facilitate the reorganization and arrangement of them (for example, the comments section could be divided into individual comments with content, date of publication, name and avatar of the user and so on).

I don't know if there is something equivalent in Crystal, but with Smarty you can do this with base templates that contain the definitions of each component and subcomponent (for example, using {include}). So when someone wants to make a new theme it would be enough to inherit the base templates and rewrite parts of them as needed.