More > JRiver Media Center 18 for Windows
Wish List: New MC User from XBMC & iTunes
Daydream:
20 posts above I believe I suggested exactly that. Why can't there be a Theater View Configurator/editor that actually looks like Theater View (at scale, not full screen)? Menu items should have Properties (Enable, Disable, Set rules for what they trigger, etc), the views should have options - set the user default choice for each type of media, and any other properties that can be applied top to bottom. And so on.
rick.ca:
--- Quote ---Why can't there be a Theater View Configurator/editor that actually looks like Theater View (at scale, not full screen)?
--- End quote ---
While some sort of preview function (even just a mode switch between the same menu in the configuration and in Theatre View) would be helpful, I certainly don't agree with this. Having to select properties of specific menus and elements from a graphic representation would be even more frustrating to use than what we have now. I'm not sure what the answer is, but a big part of the problem with the current system is that it hides most of the settings—making it difficult to tell what a menu does without opening a number of different dialogs to see what the settings are. And, of course, to the inexperienced user, looking at those settings one-at-time doesn't mean much.
The simple consistent structure of Theatre View lends itself to a tree-like presentation of it's configuration. Maybe something like...
Main menu item
Rules for file display
Expression
Sorting
File caption (expression) override for this view
Direct links to applicable File Info Panel templates
Sub-menu name
Rules for file display
Expression
Sorting
Options
Direct links to applicable File Info Panel templates
Roller item
Category name
Field, path, expression, etc.
Category name
Field, path, expression, etc.
Etc.
Etc...
[Afterthought] 8)
The idea is to show, to the extent possible, what each menu item does by displaying it's actual settings. Any sort of overview could be displayed by expanding and collapsing branches. Some of them—particularly expressions—might mean little to a new user, but double-clicking such a branch would show them in the usual dialog where they are less cryptic (and where, of course, they can be modified). Nesting and menu order would be supported by drag-and-drop, and any branch could be copied and pasted to another applicable parent (a great help for building similar but different menus). There would be the option to 'disable' (and hide) any branch—to support a number of purposes: Backing up an existing branch while modifications are made to a copy; hiding alternate views while deciding which one is preferred; archiving superseded or rarely used branches; etc. An import/export function could be included for archiving, backing up and exchanging any branch with other libraries. All these functions could be provided on a branch context menu, along with commands for adding any applicable child items.
I don't think there's any question something like this would be much more effective for experienced users. It might seen it could be even more overwhelming for new users, but I don't think so. It's ability to show an overview of the entire configuration while exposing the settings would remove much of the mystery of the current UI. Although there would still be a learning curve to ascend, this would be greatly assisted by clearly showing the relationship between behaviours observed in Theatre View and the settings that drive them (as in, "ah, that's why the TV Shows view does that and the Movies view does not.") Some things that remain a mystery when examined in detail make perfect sense when easily compared to other similar things. Also, the combination of the copy, paste and hide branch functions (together with easy switching between the configuration UI and the resulting Theatre View) would make it easy to learn by trial & error.
Such a UI would also open the door to other ways of supporting new users. For example, disabled alternative stock views that might be preferred due to user circumstances or preferences. For many reasons, it would be helpful to provides a 'menu comment' for documenting the configuration and display in a tooltip. Here, that could be used to indicate what such an alternate view is intended to be (e.g., "An XBMC-like menu for TV Series" or "Movies safe for family viewing by Decade and Genre"). Doing so might motivate users to exchange their favourite views, further increasing understanding and the willingness to use the configuration system.
Daydream:
The problem is that we're not (well, a new user it's not) in the business of expanding and collapsing branches. The business is (my view) to 1) organize the content in a make-sense and pleasant enough way to facilitate viewing; 2) viewing the content is the business.
So I have 2 questions:
- what are the core criteria we're trying to satisfy with Theater View 'cause I'm not sure anymore. MC it's a very, very flexible application but Theater View is an interface, a 10ft interface. As a subquestion here ask if Theater View was actually developed with less flexibility in mind than MC itself, then maybe that's why we're stuck and there is no way out but a rewrite. Totally going off the rails subplot - compare features developed at Pro level in MC with features developed at Entertaining level (and left there).
- who, and if at all possible to be identified, how many users need an expression to define a view. My opinion is that if you're a regular user and you need to write an expression with functions and whatnot to define a view then a) there's something wrong with your content; b) there's something wrong with the core logic this application is pushing; 3) you're an advanced user with advanced requirements, and you're a minority and the application should not cater up close and personal to you' but more to the side, after you press a button that says "all bets are off".
Movies, Series, Pictures, Music. That's it, 4 types of media (let's leave pdf and likes as a special niche). I wanna know how did we get from these to expressions and complicated file captions, and expand/collapse a zillion options. And I wanna know how many (new) users don't understand anything from them vs how many pro users actually take advantage of them.
rick.ca:
--- Quote ---The problem is that we're not (well, a new user it's not) in the business of expanding and collapsing branches.
--- End quote ---
I disagree. Everyone is familiar with the behaviour, and even if some are not inclined to use it here, that hardly constitutes a 'problem'. Such things normally come with 'expand/collapse all' commands which would serve them well. In this case there could be such commands—one for options (so 'collapse all' would result in an uncluttered view of the menu structure) and one for submenus (so 'collapse all' would result in just the main menu items, one of which could then be expanded to the sub-menu of interest).
--- Quote ---As a subquestion here ask if Theater View was actually developed with less flexibility in mind than MC itself, then maybe that's why we're stuck and there is no way out but a rewrite.
--- End quote ---
No, it wasn't. The essential design of Theatre View is one of the shining examples of flexibility and power in MC. I believe Matt has said the configuration UI is not something he's proud of.
--- Quote ---how many users need an expression to define a view.
--- End quote ---
All of them. '[Album]' is an expression. A single field might be used in an expression category simply so the caption can be something different. '[Released] [Album]' is an expression. All searches are expressions. Expressions are ubiquitous in MC. Those having an aversion to expressions should be using iTunes.
--- Quote ---I wanna know how did we get from these to expressions and complicated file captions, and expand/collapse a zillion options.
--- End quote ---
If it were that simple, there wouldn't be any need to configure anything. Those who need such over-simplification would find WMC a better choice of media manager, but surely no one wants that. With the exception of File caption (expression) override for this view, what I described is just a better way to present the options that we already have. I'm fighting a losing battle, but I know the idea of hiding options and functionality out of fear users will be too stupid to understand them is misguided. It only results in more confusion and frustration. Those who are happy with the simple stock menus will likely find this sort of presentation easy to understand (e.g., no one can be confused by complex expressions that do not exist). But they don't care anyway. Those who do would find this much more functional and easier to use. And, as I tried to explain, it would also provide a better overview of how things work, making the whole thing less intimidating. It might be used in the absence of the need to change anything—just to gain some insight as to how things work.
spiggytopes:
All of them. '[Album]' is an expression. A single field might be used in an expression category simply so the caption can be something different. '[Released] [Album]' is an expression. All searches are expressions. Expressions are ubiquitous in MC. Those having an aversion to expressions should be using iTunes.
This explains everything and, to me, highlights an attitude problem. You seem to be saying that those who are too stupid to use "expressions" are certainly not clever enough to join your exalted ranks. Is this so? And, are we also just too lazy as well?
You forget those who are keen to join you but not willing to spend time (and I mean time as in hours, not just a couple of mouse clicks) to configure something that other humbler software just does straight out of the box .....
I have spent many hours here over the last months asking questions and TRYING to pick things up as I go.
I am sad (yes, sad) to tell you that I can see absolutely no reason to move my video collection to MC from Media Browser (music is a different matter and I use MC for that).
Perhaps you could enlighten a moron .....
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version