search

jellyfin / jellyfin-web

Web Client for Jellyfin
https://jellyfin.org
GNU General Public License v2.0
2.27k stars 1.2k forks source link

Future of the web client: a proposal #1901

Closed heyhippari closed 3 years ago

heyhippari commented 4 years ago

This is not really a proposal anymore. Development has started in https://github.com/jellyfin/jellyfin-vue/.

To prevent confusion, the original proposal has been edited to reflect the current state of the Vue project. The original text is available through Github's post history.

We will leave this issue open for a while to allow further discussion, but discussion about the implementation of the Vue client should be done in the jellyfin-vue repository.

Rationale

The web client has a ton of technical debt and bad design decisions. We have been trying to clean it up for months, but issues encountered during the final phase of the webpack migration due to the inherent design of the client make it clear that a brand new client based on modern technology and using best practices is the easier route to take.

In addition, there is some uncertainty in regards to the migration to Vue. We are not sure which of the proposed routes would work. For reference, the current plan is/was:

Both approaches have issues, which I'll get into below.

Issues with the current plan

Bottom to top

This approach is very dirty, since we have to manually create and insert the Vue components into the various files, requiring a few lines for each component inserted (See https://github.com/jellyfin/jellyfin-web/issues/889#issuecomment-660712707)

It is also likely to break existing features and won't allow us to properly refactor the app until we are very far into the process, leading to potentially non-optimal design and technical debt, even after migration is complete.

Top to bottom

To put it plainly: we're not sure if and how this will work. Theoretically, we can wrap the existing app, with its router and everything, inside of a * route, which will act as a catchall. We could then use a navigation guard to make some translations between the two routers possible.

However, this is completely untested and will possibly require large changes to how the current client works and is organized.

Proposal

Create a jellyfin-vue repository and implement a new client using the already agreed-upon technologies, with a few additions.

Target

No official target. The client will serve as an alternative web client first and foremost. It may or may not replace the current web client at some point in time.

Pros

Cons

Technology stack

The tech stack is chosen to remove as much boilerplate as possible and allow for rapid development with well-known, widely-used technologies, while also allowing us a lot of control, should we need it at some point.

Why not react-native

Simply put: that client had a year of development and got very few contributions.

React Native is also not made for web. Web support is secondary in React Native, while for Jellyfin it is very much the main target and our flagship/reference client.

The community has also voted on what framework they would like to see and potentially work on in the future, and Vue.js was the most popular.

As such, it makes sense to work on a Vue client.

joshuaboniface commented 4 years ago

So, my thoughts:

  1. I don't like the idea of adding significantly more complexity to the web app, regardless of the reasons. Today it's just static files served by Kestrel or (hypothetically) any arbitrary webserver. I think this should remain our goal and if we have to make some minor sacrifices (like less pretty URLs), so be it.
  2. If we are going to go this route, NodeJS isn't a bad solution, but we have to be very cognizant of the Windows and MacOS install base. Will this run for them? We are not a Linux-only app as much as I would like us to be.
  3. I never agreed with the split; I do not fundamentally see the "server" and "web" as different things, they both provide "Jellyfin" the vidoe streaming system; we split them for practical reasons vis a vis the Android client. I do think there should be more inter-discussion between server and web teams, not less, especially until API v2 is completed.
cromefire commented 4 years ago

I specifically don't like the following points:

The final client will require Node.js for hosting

Express.js We can easily add Express as a Node.js server to get more control, if and when we need to.

This introduces a lot of complexity and additional work and shouldn't be need imo

Jest Solid test framework available from the start. We can write tests for the web client as we go, ensuring less breakage in the long term.

There's also karma and cypress, not that jest is bad, but might want to discuss the options first before fixing it

Vuex Store to share state for the entire client

Introduces a lot of complexity (especially for non Vue devs) without any real benefit imo maybe something like RxJS or plain js classes ("services") could handle it as good, but a lot simpler

I'm on the go so don't expect this to be my full argumentation, but it should serve as a starting point

heyhippari commented 4 years ago

This introduces a lot of complexity and additional work and shouldn't be need imo

Pretty much all of it is handled by Nuxt. Unless we need to at some point, we don't explicitely need Express. But if we need to, we can dive into it. Otherwise, it's really as easy as yarn start and Nuxt handles the rest.

There's also karma and cypress, not that jest is bad, but might want to discuss the options first before fixing it

Jest is very well supported by Vue and would be what most Vue devs would expect, imo.

Introduces a lot of complexity (especially for non Vue devs) without any real benefit imo maybe something like RxJS or plain js classes ("services") could handle it as good, but a lot simpler

This would mirror the current way it is done in jellyfin-web, which is very dirty for a Vue app. Vuex allows us to have one central point where we can handle all the shared data across the app in a simple way, without it being really dirty.

Imo, RxJS has a completely different purpose. Vuex is there for a specific purpose: handle shared state.

heyhippari commented 4 years ago 
1. I don't like the idea of adding significantly more complexity to the web app, regardless of the reasons. Today it's just static files served by Kestrel or (hypothetically) any arbitrary webserver. I think this should remain our goal and if we have to make some minor sacrifices (like less pretty URLs), so be it.

We have challenged a lot of what Emby left us with, but challenging Kestrel hosting the web client never came up.

I think purposefully sacrificing things because of Emby legacy is a bad idea. Properly made, it's basically like running any other app and, in my opinion, if someone can't do that, they shouldn't be using Jellyfin in the first place.

If we are going to go this route, NodeJS isn't a bad solution, but we have to be very cognizant of the Windows and MacOS install base. Will this run for them? We are not a Linux-only app as much as I would like us to be.

Any native dependency would be during build only. The end user wouldn't see any of it.

I never agreed with the split; I do not fundamentally see the "server" and "web" as different things, they both provide "Jellyfin" the vidoe streaming system; we split them for practical reasons vis a vis the Android client. I do think there should be more inter-discussion between server and web teams, not less, especially until API v2 is completed.

The split has been discussed multiple times and I think everyone on the team pretty much figured that a standalone web is the direction we are going it, whether statically hosted or run through something like Node.

I'm not advocating for less discussion. There will always be a cooperation between the main web client (whatever it is) and the server team, and this isn't advocating to change that.

cromefire commented 4 years ago

Pretty much all of it is handled by Nuxt. Unless we need to at some point, we don't explicitely need Express. But if we need to, we can dive into it. Otherwise, it's really as easy as yarn start and Nuxt handles the rest.

Well I'm not talking about the development, I'm talking about the deployment, this adds whole class runtime and it deployment difficulties.

I see 2 solutions here:

Static server

Create a server in a language that statically compiles without dependencies. Here we have Go (golang), Rust, C, D, Graal native image, you name it, ...

I know many people hate go and I also don't like it particularly, but as it brings all the building blocks for such a small http server we'd need in the language, it allows us to just write a few lines and we have a static binary that has http. I needed I'd also volunteer to write and maintain it, it's 90% copy-paste anyway. This approach is a bit more difficult on setup though, then the node.js approach I'd like to provide binaries in this case probably so not every one needs to go sdk or at the very least have a node.js script that downloads the SDK and compiles it transparent to the developer to make it as easy as possible.

Also if needed go can proxy requests easily from it's router, so we could proxy the jf api if needed to minimize the port usage or of course it could go the other way around

Continue the run serve it via jellyfin

This doesn't require a lot of work, but makes us more depended on the server.

joshuaboniface commented 4 years ago

Any native dependency would be during build only. The end user wouldn't see any of it.

That has me a bit confused, would NodeJS be a dependency to run the app on my machine, or is it just a build-time dependency to build a set of static files that could then run under any web server? The former is my concern regarding complexity of deployment here.

As mentioned in chat, I'm very much of the opinion that "do what you want to do" is the motto of the project. I will never discourage a new client, but what I want us to focus on is user stability. Telling someone upgrading from (examples) 10.8.0 to 10.9.0 that they have to rip everything out and completely redeploy Jellyfin isn't a good user experience, and that is what I am concerned with at this point.

cromefire commented 4 years ago

Jest is very well supported by Vue and would be what most Vue devs would expect, imo.

I've also seen other tools. I'd say best tool for the job so let's at least evaluate them before deciding just "because other people do it like this".

heyhippari commented 4 years ago

I see 2 solutions here

Both of these run into the same issue: they rely on the web contributors interacting with technology and languages that are not in the usual skill set of a web developer.

We run into this issue currently. Want to fix something regarding to how the web client is handled? You either have to learn C# and Kestrel or bother someone from the server repo until they get it fixed.

This is far from ideal and the proposal simply puts all the tools back into the team that works on the client, so they have control over the entire thing.

That has me a bit confused

Sorry, what I mean is that Node would be required to run it, but you wouldn't need to build any native dependencies through npm or yarn, which is usually the issue on Windows and Mac.

I've also seen other tools

I'd be curious if you have a list, because I've looked at this quite a lot and I haven't seen anything as widely used and adopted in the Vue ecosystem as Vuex, for this specific task.

cromefire commented 4 years ago

This would mirror the current way it is done in jellyfin-web, which is very dirty for a Vue app. Vuex allows us to have one central point where we can handle all the shared data across the app in a simple way, without it being really dirty.

Imo, RxJS has a completely different purpose. Vuex is there for a specific purpose: handle shared state.

Well this is for example how angular is handling it and many not web frameworks (it's also sometimes called repositories and other terms, for example on android). Because (and this is where rxjs is coming in) storing state isn't a problem, we have variables. The problem is propagating state and this is where rxjs shines. The problem with the current client and state is 95% separation of concerns and observability. The first is solved by designating a purpose to a repository/service/what-ever-you-want-to-call-it. The second is where typescript helps because you get the observability where a function is being used and what functionality is available through typing and also through rxjs because it defines a few well know primitives that can be exposed (observable / subject) and that allows proper typing (which makes a huge difference to the current client where this event suff is happening and some magic happens some where: emitter.trigger(instance , "event") (disclaimer this is no actual code)).

cromefire commented 4 years ago

I'd be curious if you have a list, because I've looked at this quite a lot and I haven't seen anything as widely used and adopted in the Vue ecosystem as Vuex, for this specific task.

You mean jest

cromefire commented 4 years ago

I'd also like to add a thing I find important to the proposal:

https://cli.vuejs.org/core-plugins/pwa.html

heyhippari commented 4 years ago

I'd be curious if you have a list, because I've looked at this quite a lot and I haven't seen anything as widely used and adopted in the Vue ecosystem as Vuex, for this specific task.

You mean jest

* https://cli.vuejs.org/core-plugins/e2e-cypress.html (core plugin, e2e, 68.4K/week)

* https://cli.vuejs.org/core-plugins/e2e-nightwatch.html (core plugin, e2e, 32.6K/week)

* https://cli.vuejs.org/core-plugins/unit-mocha.html (core plugin, unit, 45.5K/week)

* https://cli.vuejs.org/core-plugins/unit-jest.html (core plugin, unit, 269.6K/week)

Sorry, apparently I can't read :rofl: Yes, for testing frameworks, I agree that there are other tools available. However, Jest seems to be the most common for unit testing.

E2E is basically a pain to do with the separate server, at this point, so this wouldn't be a consideration for now.

heyhippari commented 4 years ago

I'd also like to add a thing I find important to the proposal:

https://cli.vuejs.org/core-plugins/pwa.html

We would be using this: https://pwa.nuxtjs.org/

cromefire commented 4 years ago

Well e2e is why I'm advocating for a test docker image

cromefire commented 4 years ago

Also I like the general proposal, as I've always advocated for doing it right once to just have less pain in the future.

And to most stuff I didn't mention yet:

Protektor-Desura commented 4 years ago

The more complex you make things the more of a barrier to entry it becomes for new developers to come in and join the project. I would take care about making things more complex and adding a ton of toolsets that new developers will have to learn or know in order to contribute. The other thing is documentation on this. Right now I know that documentation is not something most developers like to do but it is needed for new developers to come along later and join the team when older members get burned out in 6 months to a year. But we need more and better documentation for Jellyfin. I would be happy to add to the documentation but I have no idea how to do that or who to work with on it or any of that which again is a problem. The process to join the group should be very clear and very clear what is expected and how to help.

Yes I know that managing open source projects are way different from other stuff. I have been a part of many open source projects over the years and dealt with managing some of them. There are some really good books out there on managing open source projects and running and managing communities as well.

heyhippari commented 4 years ago

The more complex you make things the more of a barrier to entry it becomes for new developers to come in and join the project.

The current client has a really complex and opaque structure, both for files and code. The new client would respect the Nuxt guidelines and employ best practices for everything.
This makes it pretty much a non-issue, since it's a well documented and popular structure and way of doing things.

The other thing is documentation on this

All the tools used have A-tier documentation and are major projects. In regards to documentation, this allows us to enforce documentation from the get-go, making this a non issue as well.

The process to join the group should be very clear and very clear what is expected and how to help.

Joining the org is not needed for contributing. We encourage and help as much as we can when new or occasional contributors show up.

Someone basically notices people who have contributed a lot and have made meaningful contributions, then invites them. That's it, it doesn't bring you much more things than green ticks on some repositories and some internal discussions that are usually mostly memes.

(I pressed the close button by accident, oops)

cromefire commented 4 years ago

Nuxt: investigating

I only had a rather quick look at it, but seems to be fine, as long as we say with the traditional, non ssr and non static, SPA mode

cromefire commented 4 years ago

Also the serving part I mentioned doesn't have to be an "either ... or ..." we could support both so we could for example have 4 Packages:

cromefire commented 4 years ago

some internal discussions that are usually mostly memes

Well there seems to be a lot of decision making too

heyhippari commented 4 years ago

For info, internal discussion resolved to this:

I will be making a new repository and transferring it to the org as jellyfin-vue to reflect this. My work will then be mainly centered there instead of here, and any contributor is welcome to join in the effort (with the above in mind).

This discussion remains open, of course, but please keep the above in mind.

cromefire commented 4 years ago

as jellyfin-vue

I'd name it jellyfin-web-next then (to make clear there's where a lot of the new development goes to and that it might eventually replace web in the far future)

cromefire commented 4 years ago

I'm also hereby volunteering to help with the implementation once you got the base infra set up

cromefire commented 4 years ago

Nuxt: investigating

I only had a rather quick look at it, but seems to be fine, as long as we say with the traditional, non ssr and non static, SPA mode

It basically seems to be the angular cli (+ builders) equivalent for vue

joshuaboniface commented 4 years ago

as jellyfin-vue

I'd name it jellyfin-web-next then (to make clear there's where a lot of the new development goes to and that it might eventually replace web in the far future)

I want to avoid calling anything "-next" going forward. It will be built as an alternative, not a replacement; if the end result integrates well enough and is superior enough to the default to replace it, only then will we make that call. I don't want to give any false impressions about that, and given our bad experiences with the React client I want to avoid a repeat of treating it like "the new client".

iwalton3 commented 4 years ago

I love the idea of a new web client. There is a ton of technical issues that could be solved by a dedicated rewrite, assuming of course enough people work on it. (For instance, race conditions in the UI and standards such as time units.)

I do have two items I would like to see in a new web client:

Easy to Serve

I don't like the idea of restricting the client to only be served by something like Express.js. I currently serve a copy of the web client locally for MPV Shim desktop mode, and requiring something like that would make it very hard for me to embed the web client. A static web client is also great for security, as the only attack surface is the Jellyfin server and whatever reverse proxy you use (if applicable). If the web client is to be the base for TV apps and other constrained platforms, losing the ability to embed the web client could be a considerable limitation.

This is not to say that you cannot have modern SPA features. Something like try_files (Nginx) or mod_rewrite (Apache) to serve the same index.html file across routes is perfectly fine, and most frameworks will work great with it.

Extensibility

It would be nice to be able to add plugins to the web client, for instance the ebook player could be developed as a plugin. This also opens up the ability to make tools like a dashboard with charts/graphs as well as advanced media management tools without burdening the core web client with the code. I know some modern web frameworks with module compilation, extensive global state, and tree shaking make this difficult to impossible, but it should still be considered.

This is also important, as one of the major goals of a web-based desktop client in the future would be to add MPV support without using the cast mechanism (like MPV Shim Desktop), which would require some kind of deep integration with the web client. If this could be implemented as an alternative player plugin, it would be way more practical. Otherwise you're effectively forking the client, which has tons of maintenance overhead.

cromefire commented 4 years ago

Also cross link, if we want also want a standalone web to be possible here's a short PoC for an application server: https://gitlab.com/cromefire_/spa-server it just does the default:

This is just a PoC but it doesn't need any runtime which is one of the problems with the node method

cromefire commented 4 years ago

Also I don't know about vue-router specifically, but you usually can switch between hash and path mode, so when served via jf or an app server it can use paths and if it makes problems in some apps it can simply be changed to hash (via config or variable or query param or so)

Bitwolfies commented 4 years ago
  • The new client would not be served through the Jellyfin server (more on this later)

I understand you say more on this later, but from what I can gleem from that this new client will either have to be hosted separately/a downloaded app? I’m not totally sure if that’s what it means.

cromefire commented 4 years ago

So you can even serve the current app as a standalone app, this was about making it as a requirement though, but because of strong opposition, I think this point isn't a requirement anymore

heyhippari commented 4 years ago

Indeed, the client (Who lives over in https://github.com/jellyfin/jellyfin-vue and is progressing fast) doesn't require NodeJS anymore. That plan was changed.

Once you build it, it can be served just like the current web client, though if you wish to serve it through the current Jellyfin server, some changes need to be made to the code of the server)

mwamp commented 3 years ago

Hi, I'm sorry to throw in my two cents here especially when it seems you guys already started up with Vue. Did you guys consider Svelte as a web framework for this?

I know it is a less established framework than Vue but my experience with it is that it really makes development easy. For a project of jellyfin's scale I think it's built in state management mechanisms are quite enough.

I guess it would also be easy to use it's brother server framework (Sapper) as a backend for people who are okay with a nodeJS backend and to also build a clean build pipeline to output either a full static app which can be served by any other backend (or even just the web components if preferred)

I just wanted to ask if svelte even came on the table at some point. My main point being that (my personal experience with it) the code quality and ease of development you get with it is really good.

Feel free to ignore if this is off topic at this stage

heyhippari commented 3 years ago

Hi @mwamp. No worries, questions are always welcome, as we wish to be as open as possible on everything we do.

We held a month-long community consultation over in #889 back in March to help us decide which framework the community wanted us to support in the future. While Svelte wasn't considered directly, the decisions ultimately came to a few factors that we can summarize as such:

At the time, one of the considerations was also to be able to migrate in-place, meaning converting jf-web to our chosen framework. This limited us further in our choices, due to not every framework being able to support such a thing.

Other things came into play, of course, but these were the main parameters.

At the end of the day, as explained above, jellyfin-vue is currently seen as an alternative web client and not a replacement for the current one. It's basically a bunch of contributors trying something else for a while to see where it can go. This may be reconsidered at any time, depending on the evolution of both clients, but that's where things stand now :smiley:

Contributions to existing clients are always welcome and, of course, anyone is encouraged to make their own (and we're happy to help via Matrix or help you promote clients with a blog post and a Reddit thread).

s0urcelab commented 3 years ago

@MrTimscampi Hi~ Even though your guy decide to migrate to Vue, i still wanna give a try to build a React client. As you mention above, client will be hosted by nodejs independently, i'm confused about 2 things:

dkanada commented 3 years ago
  1. Yes, every request goes through the API on the server.
  2. We have an initial OpenAPI document somewhere by @crobibero that should help a bit.
Bitwolfies commented 3 years ago

At the end of the day, as explained above, jellyfin-vue is currently seen as an alternative web client and not a replacement for the current one. It's basically a bunch of contributors trying something else for a while to see where it can go. This may be reconsidered at any time, depending on the evolution of both clients, but that's where things stand now 😃

This is sort of what worries me, the fact that this isn't yet trying to be a replacement just yet, more of an experiment which is fine, completely throwing out the current client for a as of yet untested and unproven replacement would be a move as bad as Emby closing its source. But everything I've seen about the current client is that its a complete mess, which is evident, considering if it wasn't you wouldn't be creating a replacement. I guess I'm just wondering if your mindset is "Well we might be bulling something to replace the current client" or "We need a replacement client, this is the start of that, it might fail, but we need a replacement." and if it's not the second one, why not? While its true anyone can go out and build a replacement client, this is being made by a core team member with the intention of being an official replacement, or as official as an open source client can get.

I really really hope I'm not coming off as rude or an asshole or anything, I just want to understand what the goal of this is, and if the end goal isn't to replace the main client, why the effort isn't just spent there.

Thanks for everything you do Timscampi, this 100% would not be what it is without you, and everyone else who contributed, really sorry if this comes off bad at all, I have nothing but respect for what you, and everyone else does here. :)

dkanada commented 3 years ago

It's not a replacement because we have a set of features that will take an extremely long time to reach with a brand new client. Our primary goal is to avoid breaking the current user experience, so obviously we can't just implement 70% of the features and call it good enough to replace the existing web client.

This is most definitely an official project that aims to create a modern client for browsers, that's not in contention. The reason we don't want to call it a "replacement" is because we don't want to completely abandon the current web client for a project that would probably take over a year to reach feature parity.

Also, just because this web client exists doesn't mean the other one is immediately useless. The purpose of this client will probably change over time, perhaps we will decide to declare it the official successor, or maybe just continue to push it as an alternate client with different goals. My guess is that if we ever completely deprecate the existing web client, jellyfin-vue will indeed be the replacement. In general though, I think that both will exist as parallel projects for quite some time.

heyhippari commented 3 years ago

The opening post has been edited to reflect the state of the things as they stand currently. Hopefully this prevents some confusion in the future for people finding this :)

I guess I'm just wondering if your mindset is "Well we might be bulling something to replace the current client" or "We need a replacement client, this is the start of that, it might fail, but we need a replacement."

Officially, we don't want to commit to something that might not happen. We already had a false start with the React Native client, so proclaiming a new client this early feels wrong. We also don't want to attach a specific version or date to a new client, because who knows if/when that happens. It just sets expectations that we may or may not meet.

Unofficially, my mindset is the second. I've made it quite clear that I think we'll lose more time trying to beat this into submission than implementing something new. However, I'm bound by what the team wants, so I can only speak and work for myself :smiley:

As @dkanada says, the Vue client is still a long time away. We've got some of the very basic features down quickly (Home screen, library navigation, basic item details, authentication and video playback is in the works). But there's a ton more to go, and who knows how long that'll take. Until the client is viable as a day to day driver, I'm expecting activity over there to be limited.

I really really hope I'm not coming off as rude or an asshole or anything, I just want to understand what the goal of this is, and if the end goal isn't to replace the main client, why the effort isn't just spent there.

No worries. As I said before, questions are always welcome :wink:

This is all a voluntary project, so I can't really force people to go work on something else :smile: I can only move myself to another sub-project and hope people follow.

Thanks for everything you do Timscampi, this 100% would not be what it is without you, and everyone else who contributed, really sorry if this comes off bad at all, I have nothing but respect for what you, and everyone else does here. :)

Thanks, it's always appreciated :wink:

ldexterldesign commented 3 years ago

Disclaimer: I don't have a major issue with the design

Hi all,

Sorry if this has been answered somewhere else or I've completely overlooked it in this issue but Is this a redevelopment or a redevelopment AND redesign plan?

"Feature parity" is mentioned a few times here...

Personally, thing is, I don't care about parity. I don't care about a bunch of jellyfin features and I'd rather not wait >1 year to experience the same thing. I've never felt emby/jellyfin has been good (enough) for consuming anything but video.

The main reason I invest CPU cycles in jellyfin instead of mpv for video is that:

"Simple" additions like full hotkey support (inc. player) would go a long way towards better UX out of the box

I see your kanban but please consider putting untechnical user stories somewhere so users can vote on what users want priority-mapped

I would hope an MVP can appear, for example with the features above, in <1 year, then someone like myself can drop into the project with a vested interest in contributing or learning some of the tech' stack to make a contribution (have done basic vue but currently in svelte land)

Hope to hear back

Sincerely

dkanada commented 3 years ago

@ldexterldesign we already have an MVP available at jellyfin-vue that has video playback in an open pull request and lots of other features. You could probably start using it as a proper client very shortly, and adding features is much easier than with the current web client.

ldexterldesign commented 3 years ago

Hi @dkanada, thanks for reply. For a play, is a docker container too much to ask at this stage (happy to help)?

heyhippari commented 3 years ago

We already have a Dockerfile in the repository, though it is largely untested.

We are focusing on the main features first, so being able to visualize your files and playing them. I'm not doing votes for priority, because we run the risk of things being prioritized in the wrong order and I personally think that it's a terrible way to run a project.
When doing project management (Which is essentially what I'm doing on jellyfin-vue, along with implementing it), you have many things to consider (Which features are dependent on others, which have a higher priority for functionality, etc).

I do intend to start making it more available once a few things are working. Most notably:

This is to ensure that you are able to watch videos in the client and that your progress is reported to the server, which I consider the bare minimum for a usable client.

We are doing some pretty heavy redesigns on a lot of how the client looks and work, since the general consensus among the team is that we have a lot of really bad UX decisions that are holdovers from Emby. We're also trying to give Jellyfin more of its own identity along the way.

The kanban is only to track the features that Jellyfin Web has and that we need to implement to essentially be a reference client. The release plan is to make preview releases as major features get completed, to get user feedback along the way. More info will become available as we reach closer to that first preview release :)

ldexterldesign commented 3 years ago

2011 - Elements of User Experience,The User-Centered Design for the Web and Beyond - Jesse James Garrett - Pearson Education

Prioritizing Requirements

Collecting ideas for possible requirements is not hard. Almost everyone who regularly comes in contact with a product—whether they are inside the organization or outside—will have at least one idea for a feature that could be added. The tricky part is sorting out what features should be included in the scope for your project.

Screenshot 2020-10-08 at 12 16 40

Sometimes a strategic objective will result in multiple requirements (left). In other cases, one requirement can serve multiple strategic objectives (right).

It’s actually fairly rare that you see a simple one-to-one correlation between your strategic objectives and your requirements. Sometimes one requirement can be applied toward multiple strategic objectives. Similarly, one objective will often be associated with several different requirements.

Because the scope is built upon the strategy, we’ll need to evaluate possible requirements based on whether they fulfill our strategic goals (both product objectives and user needs). In addition to those two considerations, defining the scope adds a third: How feasible will it be to actually make this stuff?

Some features can’t be implemented because they’re technically impossible—for example, there’s just no way to allow users to smell products over the Web yet, no matter how badly they might want that ability. Other features (particularly in the case of content) aren’t feasible because they would demand more resources—human or financial—than we have at our disposal. In other cases, it’s just a matter of time: The feature would take three months to implement, but we have an executive requirement to launch in two.

In the case of time constraints, you can push features out to a later release or project milestone. For resource constraints, technological or organizational changes can sometimes—but, importantly, not always—reduce the resource burden, enabling a feature to be implemented. (However, impossible things will remain impossible. Sorry.)

Few features exist in a vacuum. Even content features on a Web site rely on the features around them to inform the user on how best to use the content provided. This inevitably leads to conflicts between features. Some features will require trade-offs with others in order to produce a coherent, consistent whole. For example, users may want a one-step order submission process—but the tangle of legacy databases the site uses can’t accommodate all the data at once. Is it preferable to go with a multiple-step process, or should you rework the database system? It depends on your strategic objectives.

Keep an eye out for feature suggestions that indicate possible shifts in strategy that weren’t apparent during the development of the vision document. Any feature suggestion not in line with the project strategy is, by definition, out of scope. But if a suggested feature that falls outside the scope doesn’t fit any of the types of constraints above and still sounds like a good idea, you may want to reexamine some of your strategic objectives. If you find yourself revisiting many aspects of your strategy, however, you’ve probably jumped into defining requirements too soon.

If your strategy or vision document identifies a clear hierarchy of priorities among your strategic objectives, these priorities should be the primary factors in determining the priority of suggested features. Sometimes, however, the relative importance of two different strategic objectives isn’t clear. In these cases, whether features end up in the project scope all too often comes down to corporate politics.

When stakeholders talk about strategy, they usually start out with feature ideas, and then have to be coaxed back to the underlying strategic factors. Because stakeholders often have trouble separating features from strategy, certain features will often have champions. Thus the requirements definition process becomes a matter of negotiation between motivated stakeholders.

Managing this negotiation process can be difficult. The best approach to resolving a conflict between stakeholders is to appeal to the defined strategy. Focus on strategic goals, not proposed means of accomplishing them. If you can assure a stakeholder with her heart set on a particular feature that the strategic goal the feature is intended to fulfill can be addressed in some other way, she won’t feel the needs of her constituents are being neglected. Admittedly, this is often easier said than done. Demonstrating empathy with the needs of stakeholders is essential to resolving feature conflicts. Who says tech workers don’t need people skills?

Hope it's useful

Sincerely

Maxr1998 commented 3 years ago

We already have a Dockerfile in the repository, though it is largely untested.

I've been using it since it was merged and I didn't face any issues, fwiw.

heyhippari commented 3 years ago

For an update, some small issues have been fixed with the Docker image and we should build it and upload it to Dockerhub automatically pretty soon.

ldexterldesign commented 3 years ago

@Maxr1998 @MrTimscampi 👋 https://github.com/jellyfin/jellyfin-vue/issues/256

thornbill commented 3 years ago

Closing this since development on a new client based on Vue has started in https://github.com/jellyfin/jellyfin-vue/.

In the meantime, bugfixes and incremental improvements will continue in this project.