There are some great ideas coming out in this thread. One which I support 100% is this one.
I'd suggest something a much broader and it goes to the basic architecture of how MC works.
I won't bore you with my experience with large database dependent software systems and their transition from central mainframe processing to distributed fat client processing back to central server processing with thin clients, and now to SaaS implementations. But I will point out that nearly all our favourite mobile Apps whether music streaming or social media are using central processing and thin clients.
Panel, or more specifically the use of HTML5, is a good move, but it needs to go much further and get better.
This sort of thing is a problem as far as I am concerned:
Speaking of the devil, drmimosa's post here illustrates how convoluted simple things can get:
https://yabb.jriver.com/interact/index.php/topic,105883.msg785646.html#msg785646
A user should just never see that stuff. That is why we aren't all software developers. A product should be designed to be a great user experience, and as simple as possible. All the complexity should be under the covers, and the developers should be looking after that. So a user just says "I want to play music from my server", the software says "Here are all your servers. Which one do you want to use?", the user picks one, the software connects and offers the contents. The user then says "I want to shut down/restart/whatever that requires authentication", the software says you need to sign in to do that Yes/No, the user provides credentials, or uses a token or similar provided by the owner of the server, only the first time they connect, and the software connects. The user never sees a URL, or credentials unless they are the owner, and the whole process is done with AAA+ security. No plain text User ID and Password.
This is why MC is a Geek's tool and not a Luddite's. Let's face it, even savy users can't or don't want to understand the tech underneath the software tool they are using.
One point of difference is that presently one piece of code (JRiver Media Center) currently can serve as client, server, or both.
This is great, but there is one huge hole in that statement. That is that for important maintenance functions such as building or editing Views, collecting Cover Art and so on, a user has to go to the MC Server, or use third-party tools like Teamviewer, Remote Desktop, VNC (Geeks tools), none of which I find acceptable when working in MC Standard View doing maintenance. Again, if the use of the Client or Server version of MC was transparent to the user in terms of what they could do, then this wouldn't matter. But in actual fact, not only does the user need to be aware that they are on a Client of the MC Server despite the two looking identical, but they also need to know what they can do which will work, and what they can't do because of the architecture. In fact, the user has to understand the architecture to some degree in order to avoid being tripped up. There isn't even a readily available, complete list of what will and what won't work when doing maintenance using a Client!
I see so many threads where it is genuinely hard to work out what sort of MC configuration people are using, and sadly often they don't know, or can't describe it.
Again, this is why MC is a Geek's tool and not a Luddite's. Users of Android and iOS, the main computing platforms of many if not most people these days, are getting used to fantastic integration, brilliant Discovery functionality, and generally being led by the nose by software that not only hides any and all technical issues but works really well.
Anyway, I'll get off the soapbox now. I hope all the comments and suggestions in this thread are taken as they are meant; constructive feedback on a product that we all love and want to see succeed well into the future.
