Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MusicHawk]

This was discussed in prior versions, but I'd like to raise it again given that MC15 allows 2-way library editing. Of course, my comments are IMHO...

Problem: I find that the field/tag Rating -- displayed as 1 to 5 stars -- is too easy to change inadvertently by simply clicking on the field.

Yet the Rating value often represents serious effort by the library owner to evaluate, organize and then select songs or images or whatever. So an unintended (and probably unnoticed) change in a Rating can really mess up the user's careful work.

Rating is too easy to change because it requires just one click on the stars field, in a view or in the Tag Action Window. No other field that I know of can be changed with just one click. The other tags require first clicking (or tabbing or other explicit action) into the field, THEN typing (or selecting from a list) a desired value.

In contrast, because Rating gets changed simply by clicking on it, wherever the pointer happens to be, that star gets selected and thereby becomes the Rating. In my experience, this caused "odd" songs to disappear from, or be added to, smartlist and views that used Rating for selection.

Example I've seen many times: Selecting a row in a view is commonly done by clicking on the row. Clicking on any column in the row is harmless -- EXCEPT clicking on the Rating column. Oops -- changed the Rating. Yes, un-do reverts the change, but the problem is that the user doesn't always notice the undesired change in Rating, since the user was really just trying to select a row.

Further, the Rating column in a view does not behave like other columns. To select a view row, just about any column in the row can be clicked, EXCEPT Rating. Clicking any row in the Rating column does not select the row, but instead potentially changes the Rating value. Therefore, a user trying to select a row can click the Rating column, not realizing it is different from all the others, and not get the row selected. So the user clicks again, or tries another row. Meanwhile, the user is perhaps changing several Rating values (there's 5 out of 6 chances to click a different star) before realizing the need to click a different column to actually select the row.

Summary: It's too easy to change the Rating value by clicking, unlike all other field/tag values.


Suggestions: To help protect the Rating field/tag value, perhaps alter view behavior so Rating can't be changed by clicking the view column, but can be changed via the Tag Action Window. Or add a pop-up to select a value, not just click a star. Or add a confirmation step if Rating is changed in a view.

Or allow more library-level control over the Rating field, so it can be set to display stars OR the underlying number (0 to 5). Setting Rating to show the number would then cause the field to work just like all the others, requiring field selection then typing. This is essentially what I've done as a workaround.


My workaround: After having what amounts to data loss due to clicking wrong stars, I stopped using Rating and added a custom field that I use for the same purpose. It accepts the same 0 to 5 values but is a "safer" way to store my track rating. But now I don't have the original field's nice stars, and the value I set in a custom field isn't recognized by other software. So it would be wonderful to "fix" how the standard Rating field works.


And... It would be helpful (and powerful) if the standard Rating field could be controlled via an expression. This would allow for computed ratings based on whatever the user desires.

Maybe the total "fix" is to allow standard fields to be user-controlled the same as custom fields. For instance, allow the view column stars display to be used for any (reasonable) number-content field, and/or not-used for the Rating field, as desired.

[tunetyme]

+1

I've solved it by setting up my own rating column.  I rate from 0 to 10.  This solves the half star problem and allows me to have my own rating system as well as a public opinion system.  It would be nice to reduce the risk of having the star system so easily changed.

I use the stars as my tool to identify those that are Top 20 for 1 or more months 5 stars.  Top 40 4 stars.  Good Album tracks 3 Stars etc.   

[MusicHawk]

I considered using 0 to 10 for my custom rating field, but instead I'm using 0 to 5 to match what the Rating field does. I'm hoping that the standard Rating field will be improved as suggested, then I can directly migrate my separate ratings back to the standard field.  Tools > Library Tools > Move /Copy fields allows pushing values into Rating without manually editing each record.

Also, I've heard (but not verified) that the 5-star approach is desirable to be compatible with other media managers/players.

But, if the underlying Rating value could be 0 to 10 or any other range the user desires, presumably MC could auto-convert to 0 to 5 by simple math, rounding the result, so any arbitrary number scale could be displayed as 0 to 5 stars. Or maybe more precisely by a half-stars system.

Also, while stars are cool, they take screen space. Stars fit in the Tag Action Window, but in a view where horizontal space is limited, having the option of just displaying the number would be a big help (per my experience with my substitute custom field).

[tunetyme]

MusicHawk:

As I said I use both.  Each have a different purpose.  There is some music that I might rate as an 8 or a nine that never showed up on any charts.  There is some music that has charted that absolutely sucks.  By using the two methods I can identify both personal and public opinion.  With the personal I can provide a greater detail in my ratings.  A scale of 0 to 5 doesn't address all the info I want to encode in a rating.

Tunetyme

[gappie]

have you guys considered using a calculated field for showing the ratings. so using the original rating field but when looking at a view showing a calculated field that only shows the rating and can not be edited?

 
gab

[MusicHawk]

Same goal, it seems. I use multiple fields to home in on the tracks I really want to play, including Chart to contain the highest chart position. As you say, chart position doesn't directly indicate "let's hear it again". So I use my custom field alternative to Rating for my overall opinion of a track. In smartlists, the selection is further refined by Keywords, Tempo, Year, etc.

I literally ignore the Rating field (it's not in any of my customized views), because the problem of inadvertent change makes it too delicate to use for any purpose. Sometimes I use Tools > Library Tools > Move / Copy fields to update Rating, just so the stars I see in Tag Action make sense, but that's a one-way thing since it's not the true field.

[MusicHawk]

Yep, I originally used a calculated field to show the Stars Rating value as a number in a view. But (at least in prior versions of MC) it was a big effort to control the columns of every important view and playlist, so the true Rating was exposed here and there.

After some unfortunate incidents, I added a custom "safety" field into which I copied the Rating value periodically. But this was a full database update, a tad heavy for the purpose since the value is also stored in the media files (put a huge load on my backup system). So I switched to simply using the custom field and ignoring the Rating field. (This all happened some time ago; I've been using MC since MJ 7.)

I then realized that there was no particular reason to display 0 to 5 as Stars in a wide-ish column when a single-digit conveyed the same rating evaluation, plus saved view space and provided random-click immunity.

If Rating allowed an expression, I could continue to use the custom field for the real value, and auto-update Rating to match, treating it as a non-editable field. This would provide the benefit of seeing Stars where desired without the risk that clicking them changes anything that matters. .... yet another way the situation could be improved.

But best would be allowing total control over the Rating field in views. Then, I'd switch it to show the numbers and behave like a normal field.

Ideally, the Rating field could be handled as a number field in a view, but show Stars in the Tag Action window, and also be displayed as Stars in a theater and visualization modes.

[Gl3nn]

Agree on the danger of altering the built-in rating field.  Count me as another who created a personal rating scheme that's more secure. 

I use the stars as a "visual" tool but rely on my field for real evaluations.  Even if the stars were locked-down, I wouldn't change my method - I like my way better.

[rick.ca]

have you guys considered using a calculated field for showing the ratings. so using the original rating field but when looking at a view showing a calculated field that only shows the rating and can not be edited?

Apparently not. The attached illustrates an important (if you like stars) embellishment gappie should also get credit for.

Note there's a quirk in how the add field dialog behaves. You have to first select "Calculated data," add the expression and save. Reopen, switch to "User data," change to "String" / "Cannot be edited" and save. Reopen, switch back to "Calculated data" and save.

So there you are. Stars based on Rating—which can be excluded from the view to prevent unwanted changes.

[MusicHawk]

Very cool. Thanks to gappie and rick.

But to clarify: My change request isn't intended to focus on a safe way to show read-only Stars (I'm happy to show a Rating number instead), though I appreciate the clever way to do so.

I'm requesting a safer, more consistent way to show and EDIT the actual Rating field, tweaked so it isn't so easily changed by random clicks, therefore doesn't have to be excluded from views by custom field and/or clever technique. I think "average"/casual users who might not delve into custom fields should have their Rating data protected too.

I'm hoping to use the standard Rating field so my data is, well, standard. And to let the real live Rating field, as Stars or a number, be in any/all views. This would be possible if it was less vulnerable to random clicks, by requiring at least one more click, to select or confirm, to actually change the Rating value. The current field behavior just seems like a poor UI design for important data.

[rick.ca]

The current field behavior just seems like a poor UI design for important data.

It's clearly a very good design for those who want a quick and easy way to change the rating. I'm sure the "average user" is quite happy with the behaviour, and isn't concerned about having their data protected—especially from themselves. Requiring a confirmation would annoy most because it makes changing ratings more difficult.

What's wrong a "clever technique" that's easy to implement and effective? Those who are concerned about clumsy clicks can display the custom field and use the tag window to change the rating (which is conveniently located at the top of the window). Or they can swap it for Rating when they want to make changes. Or they can leave Rating in the view—but off-screen—so they have to scroll horizontally to make it visible. Any of these solutions would be more efficient and less irritating than a confirmation.

I do wonder, however, why so many standard field attributes are locked. It seems at least some with this concern would be satisfied if they could change the "edit type" of Rating to "standard."

I probably won't use any of these techniques—because I'm happy with my current practice. I copy Rating to a "backup" field which is generally not included in views (and not as stars if it is). I periodically compare the two, filtering to show only those that have changed. I then decide which should be updated to the "backup" field and which restored to their original values.

[Alex B]

I do wonder, however, why so many standard field attributes are locked. It seems at least some with this concern would be satisfied if they could change the "edit type" of Rating to "standard."

Regarding the "locked" rating field, it is possible to create a user field that shows up as "five stars".  When preferred, the "Edit Type" value can be changed to "Standard" and the field will then reveal the actual values instead of the clickable stars.

Unfortunately this option is still locked to integer numeric values from one to five. It would be more useful if it could handle any number of all kinds of values (also textual) that are defined in the semicolon delimited list. Then the first star would apply the first value, the second star would apply the second value and so on. The number of stars would be defined by the number of listed values. (I've been requesting this for a long time.)

My original feature request is in this thread: http://yabb.jriver.com/interact/index.php?topic=36753 and here's some further discussion: http://yabb.jriver.com/interact/index.php?topic=48761.

[rick.ca]

Regarding the "locked" rating field, it is possible to create a user field that shows up as "five stars".  When preferred, the "Edit Type" value can be changed to "Standard" and the field will then reveal the actual values instead of the clickable stars.

Yes, but it seems one of the requirements other posters have is the standard rating field be used. I assume this is important because, while a user field will be saved to a tag as well, only the default field will be recognized by other software.

(I've been requesting this for a long time.)

It's nice we could offer a way to bump this.

Reading through that quickly made me wonder if the best solution would not be a completely flexible option for displaying an appropriate graphical representation of any field type with any contents. For numeric fields (yes, integer or decimal), a valid range and the number of stars (or whatever) would be specified—and the two would simply be mapped to one another linearly. So you could take an existing field with values ranging from 1.7 to 4.3 and display it using 7 stars, if that happened to make sense. An optional edit mode would necessarily use the same mapping, so fractional stars should be allowed for decimal fields. Some choice of graphics could be offered—the bare minimum would be radio buttons for application that have nothing to do with rating, and a slider for depicting numerical measures. There could be an option to display the underlying value beside the graphic. If the options selected effectively reduced the display to boolean values, a checkbox could be used instead of one star or button.

And, very important: Although the edit type may need to be constrained, it should be possible to apply this to any standard field. So, for example, if one wanted to display Bitrate as a (non-functional) slider, they could do so.

Wow. No wonder this hasn't been implemented after three and a half years.

[MusicHawk]

Not trying to get the last word, but I just encountered ANOTHER way a track's Rating can be goofed up, inadvertently.

I was working through a bunch of tracks I'd previously ripped but hadn't tagged carefully, listening and tagging. Since I only sort-of know the songs, I was using the top slider to jump ahead to see if there was a tempo or style change or something else I should know about.

After doing this a bunch of times, I scrolled back up through the tracks. The view I'm using doesn't display Rating because I don't use it. But as I scrolled the list with the Tag Action window open, I noticed many of the tracks somehow have a Ratings value -- various number of Stars displayed. Huh?

Continuing my work, I vowed to pay more attention to what I was clicking, assuming I was accidently doing this in the Tag Action window. And almost immediately I found the trap -- elsewhere.

In the top window that displays track info when a track is playing, there are the same Stars that appear in the Tag Action window. When I'd go up to click the playing track progress bar to jump around in the track. But if the bar end's current position happened to be in the area of the Stars, I'd sometimes click a Star -- they are just a few pixels away from the progress bar. And BAM -- the Rating of the track was changed.

AND... I don't find any way to remove the Stars from the track info display. Customize Display shows the various fields that are displayed, but it does not show a field representing Rating/Stars -- so there's nothing to change. Yet there they are.

So, Rating Stars show by default in most views, and always in the Tag Action window, and apparently always in the track info display. In all cases Stars is the ONLY track field/tag (I know of) that can be changed by one inadvertent click, and that's too easy.

As a half-way fix, how about making the playing-track info area read-only? None of the other displayed data seems to be editable, just Rating Stars. And also, making Rating an explicit field in Customize Display so it can be removed if desired?

BTW, the three different Rating Stars displays are only semi-synchronized. If I change Stars in a view, the other two update promptly. But if I change Stars in the playing-track area, the view updates only after a delay, and the Tag Action window Stars don't seem to update until revisiting the track. Changing Stars in the Tag Action window also isn't immediately recognized by the other displays. I can readily set a track to 2, 3 and 4 Stars simultaneously, and not know which is the "real" rating until I revisit the track.

Also, I strongly vote for allowing full control over standard fields -- everything that is allowed for custom fields. And for allowing Stars to be the display format of any number-based field. And for giving MC the automatic simple math required to convert any reasonable number range into 5 integers to control the Stars.

[hit_ny]

I do wonder, however, why so many standard field attributes are locked. It seems at least some with this concern would be satisfied if they could change the "edit type" of Rating to "standard."

Because if you changed them there would be no way to get other players that are expecting std parameters to read them. At that point how do you revert back to std, you can't, not without redoing your work. A change would zero out all the content in that field.

Whats worse is if you had also changed other 'std' fields too, the problem then gets compounded. At which point there is no way to tell which fields are std std or semi-std

Locking those fields is a way of saving a user from themself, because std is std and should not be changed at least not by the user.

But to clarify: My change request isn't intended to focus on a safe way to show read-only Stars (I'm happy to show a Rating number instead), though I appreciate the clever way to do so.

I'm requesting a safer, more consistent way to show and EDIT the actual Rating field, tweaked so it isn't so easily changed by random clicks, therefore doesn't have to be excluded from views by custom field and/or clever technique. I think "average"/casual users who might not delve into custom fields should have their Rating data protected too.

I'm hoping to use the standard Rating field so my data is, well, standard. And to let the real live Rating field, as Stars or a number, be in any/all views. This would be possible if it was less vulnerable to random clicks, by requiring at least one more click, to select or confirm, to actually change the Rating value. The current field behavior just seems like a poor UI design for important data.

A random click will only set the rating if & only if the mouse is directly over the ratings field. That's two events that need to occur in parallel to change a rating.

Is your ratings field close to other fields that you frequently edit ?

Would it help to relocate if between other fields that are not frequently edited. Could it decrease the likelihood of a random click as you would not normally be in the vicinity.

Other than what has already been suggested I cannot think of a way that would afford the same convenience as presently offered but with added security.

[rick.ca]

AND... I don't find any way to remove the Stars from the track info display. Customize Display shows the various fields that are displayed, but it does not show a field representing Rating/Stars -- so there's nothing to change. Yet there they are.

Right-click and de-select "Show ratings."

Because if you changed them there would be no way to get other players that are expecting std parameters to read them. At that point how do you revert back to std, you can't, not without redoing your work. A change would zero out all the content in that field.

I understand there are reasons to lock some settings. My question was "why so many standard field attributes are locked"—meaning some are locked unnecessarily. And my case in point was the edit type of Rating. The edit type has no bearing on how the value is saved.

Locking those fields is a way of saving a user from themself, because std is std and should not be changed at least not by the user.

I suppose you must be thinking of the "data type" of Rating. Yes, obviously that needs to be protected. But there's no good reason to protect it's "edit type." But you name the apparent design philosophy I was calling into question. That's the idea users must be protected from themselves. As a user, I find any hint of this condescending and infuriating. What am I to think when I'm denied an option I need for the apparent reason I'm too stupid to understand the consequences? Yes, there are situations where some users are stupid (and in some situations, I'm one of them), but in many cases the item being protected is very unlikely to even be seen by users who aren't knowledgeable enough to handle the option. What's the idea behind this? A user will be smart enough to find and change the edit type of Rating, but too stupid to understand where his stars went after doing so?

The edit type of Rating may not be the best example of unnecessary locking. Maybe it was done because the same field with this same attribute is displayed in the player bar and tag window—and it was decided it was more important to preserve consistency of appearance and behaviour. Even so, I'd say the consistency should be enforced, but the change allowed.

And to call for reinforcements on this point, I'll just say "Media Sub Type."

[hit_ny]

And my case in point was the edit type of Rating. The edit type has no bearing on how the value is saved.

It might not in the case of Rating but what about the rest of the std fields (100+) ?

Some of the edit types available don't make sense for other std fields, so then what do you do. Blank them out. This is extra work for nothing isn't it, from a developer pov.

Either they decide to allow edit type to be changed for all std fields or none at all. Making exceptions and I don't mean just in terms of fields but as a philosophy on a more general level throughout the program, is usually detrimental in the long run unless absolutely called for. Even that isn't a valid reason but an emotional one.

But there's no good reason to protect it's "edit type."

See above.

But you name the apparent design philosophy I was calling into question. That's the idea users must be protected from themselves. As a user, I find any hint of this condescending and infuriating. What am I to think when I'm denied an option I need for the apparent reason I'm too stupid to understand the consequences? Yes, there are situations where some users are stupid (and in some situations, I'm one of them), but in many cases the item being protected is very unlikely to even be seen by users who aren't knowledgeable enough to handle the option. What's the idea behind this? A user will be smart enough to find and change the edit type of Rating, but too stupid to understand where his stars went after doing so?

What about the second reason I gave, that std is std and should be immutable. This implies everything about a std field is locked.

The edit type of Rating may not be the best example of unnecessary locking.Maybe it was done because the same field with this same attribute is displayed in the player bar and tag window—and it was decided it was more important to preserve consistency of appearance and behaviour. Even so, I'd say the consistency should be enforced, but the change allowed.

Yes, but your only referring to a display issue what about functional issues, fields can be displayed & interacted with in so many places in the program that lots of bugs could potentially be introduced. Its a can of worms.

TAnd to call for reinforcements on this point, I'll just say "Media Sub Type."

Exceptional case, did not get very far last time did it.

Just to be clear I don't have a position on this issue either way just thinking out loud for the ppl that have to do the actual work

[rick.ca]

It might not in the case of Rating but what about the rest of the std fields (100+) ?

The specific field attributes that need to be protected for any legitimate reason should be locked. Those that don't should not be locked. Many "standard" fields seem to have been added for no other reason than an assumption some users might need them. They're not affected by any significant program interaction (and being included in some useless sample view doesn't count). Many of the video fields added, for example, I could not use because they were not of the appropriate type. Even though it made absolutely no difference to the function of the program, I was denied the easy fix of just changing the type to what I needed. To add insult to injury, my substitute custom fields had to be given different names, and the useless standard field cannot be deleted.

Some of the edit types available don't make sense for other std fields, so then what do you do. Blank them out. This is extra work for nothing isn't it, from a developer pov.

Yes, of course they would be greyed-out—as is the standard practise for such things. Since when is accommodating the needs of users "extra work for nothing"?

Either they decide to allow edit type to be changed for all std fields or none at all. Making exceptions and I don't mean just in terms of fields but as a philosophy on a more general level throughout the program, is usually detrimental in the long run unless absolutely called for.

Nonsense! Sure, similar things in similar circumstances normally should be given the same treatment—consistency is simpler, easier to understand and less error-prone. But to apply that idea to all attributes of all standard fields is silly. That's why we end up with video fields we can't use. That's why we can't do perfectly sensible things like change the edit type of a standard field from "standard" to "cannot be edited" to protect data that should not be changed. And it certainly doesn't make the program any easier to use or configure. If only the things that need to be protected are locked, then seeing exactly what those things are offers considerable insight into how the program and database work, and makes those restrictions easier to accept and work around. Locking everything completely removes that information and makes the program that much more difficult to understand and use.

What about the second reason I gave, that std is std and should be immutable.

It's a fallacy no matter how many times it's repeated.

Exceptional case, did not get very far last time did it.

It's not exceptional. It's another good illustration of what goes wrong when such an arbitrary approach is taken. For reasons that could only fall under the category of "protecting users from themselves," the list of acceptable values for Media Sub Type is locked. So if we need more value, were forced to add a custom field with exactly the same meaning and purpose as the standard one. Then most references to media sub type must use the correct version, or both. As we have heard, this seems to be extremely annoying for users with a legitimate reasons for adding sub types. And I don't believe we've heard of any justification for restricting the list.

[hit_ny]

The specific field attributes that need to be protected for any legitimate reason should be locked.

How many std fields come under this definition ?

Those that don't should not be locked.

To 'unprotect' these fields requires a framework to be created and applied for each & every field out there. Once thats done then every field needs to be reviewed and correlated for what makes sense. Then they need to study whether these changes could adversely affect other areas of the program and if thats ok implement it. Then comes the hard bit, the testing and the bugs this 'feature' might introduce.

Many "standard" fields seem to have been added for no other reason than an assumption some users might need them.

Can you show that these fields do not exist in any existing standards, it would be reasonable to say if they did not exist in any standard that they are proprietary to MC.

Whether these proprietary fields ought to be open or not is debatable.

Many of the video fields added, for example, I could not use because they were not of the appropriate type. Even though it made absolutely no difference to the function of the program, I was denied the easy fix of just changing the type to what I needed. To add insult to injury, my substitute custom fields had to be given different names, and the useless standard field cannot be deleted.

I don't dispute anything here, but stds are there for a reason and companies that play fast & loose with them do so at their own risk.

Yes, of course they would be greyed-out—as is the standard practise for such things. Since when is accommodating the needs of users "extra work for nothing"?

Because of the second order effects this change will cause. It's not as easy as you make it out to be. Fields are the basic units of the database and therefore affect the very core of the app, much thought must be put into anything that modifies their behaviour. This more than anything is why its not happened as quick as you would like.

Nonsense! Sure, similar things in similar circumstances normally should be given the same treatment—consistency is simpler, easier to understand and less error-prone. But to apply that idea to all attributes of all standard fields is silly.

I've explained to you the rationale of keeping things the way they are, if you choose to ignore the development side, the business side and only focus on the user side then you've still not got it.

That's why we end up with video fields we can't use. That's why we can't do perfectly sensible things like change the edit type of a standard field from "standard" to "cannot be edited" to protect data that should not be changed.

You may have a case if any of these fields are not defined in any accepted std otherwise no.

It's a fallacy no matter how many times it's repeated.

Where's the fallacy ?

It's not exceptional. It's another good illustration of what goes wrong when such an arbitrary approach is taken.

Actually no, the way its now is std across the board for all std fields, what you're asking for will make treatment of std fields arbitrary. This is designing for the exception. And it is exceptional because only few fields out of the majority are desired to be editiable.

IFor reasons that could only fall under the category of "protecting users from themselves," the list of acceptable values for Media Sub Type is locked. So if we need more value, were forced to add a custom field with exactly the same meaning and purpose as the standard one. Then most references to media sub type must use the correct version, or both. As we have heard, this seems to be extremely annoying for users with a legitimate reasons for adding sub types. And I don't believe we've heard of any justification for restricting the list.

I'd say the complications that would arise as a result of this change are the primary reason it has not been considered.

It's still early days yet you might get lucky but I think its unlikely

[MusicHawk]

My sense (maybe just a hunch) is that MC has three types of "standard" -- AKA built-in -- fields/tags

INDUSTRY STANDARD -- Fields that are also built into other major media players/managers, such as Windows Media Player, iPod, etc. Presumably, the data type, size and purpose of such fields are de-facto standards. (And perhaps actually defined somewhere...). So it is prudent to have these in MC too. But note that there have been various efforts to define tags, different ID standards that aren't consistently consistent. So even some "industry standard" fields might be debatable.

J.RIVER STANDARD -- Fields that JR "invented" in earlier versions of Media Center or even Media Jukebox, in use so long that they are retained for cross-version consistency, even if not reliably recognized outside of MC.

USER JUMP-START -- Fields that JR added to MC to help users get going with the major media types MC is intended to handle, mainly music, photos, DVD and TV. There seem to be more of these with each MC version, so the standard library fields list is now quite long.


If this is more or less correct...

It seems reasonable that MC contains INDUSTRY STANDARD fields.  However, all MC needs to do is store these fields in media files (MP3 etc) in a standard fashion. There can be wider variation within MC itself, since MC's data format is proprietary. I think some of this already happens, where MC stores certain data in STANDARD tags and also in proprietary tags. Assuming Rating (what started this thread) is such a field, it still could be somewhat flexible within MC, but forced into standard format/number range when put into an MP3 tag.

It seems helpful that MC by default contains JR-STANDARD fields. But it's a gray area to clutter up newer versions with older version fields that might no longer be truly useful. But perhaps I'm wrong and this doesn't happen.

JUMP-START fields are highly debatable and should be user-controllable, because (I'm assuming) they are just in MC to help users realize what kind of tags they might want to use for certain media. Say a use of MC is subtype video, to manage TV shows -- lots of tags might be used by someone who really cares about episodes and actors and similar. But say MC is instead used for Home Videos -- the useful tags are essentially the same as for still photos, not TV or movies. And does a photo library need Beats-Per-Minute? (I know, some fields can sort-of be hidden based on media type, but that's a different can of worms.) Maybe such tags could be truly optional, perhaps offered as templates the user can select to have MC add them without lots of typing, but otherwise they behave as custom fields.]

One improved approach might be:

• MC identifies the different classes of fields/tags, perhaps by grouping or color-coding.
• INDUSTRY STANDARD tags are always in MC's library, but whether fully locked is debatable (per-tag debate -- what aspect must be locked?)
• J.R STANDARD tags are in the library by default but can be excluded by the user (grayed-out...) so they don't appear in view designs, etc. Possibly they can be deleted, with a caution about breaking backward compatibility.
• JUMPSTART tags are not in the library by default, but can be added by the user from templates. THEN they can be modified by the user individually, including change in datatype, display characteristics, even deleted.  Same idea as visualizations, etc.

Meanwhile, back at the ranch...

Back to discussing the Ratings field , I originally requested that MC 15's UI be made a tad more consistent by making the Rating Stars field behave like other fields, requiring two steps to change its data -- click IN, then TYPE -- to avoid inadvertent, unnoticed data change/LOSS that happen now when simply clicking ON the field.

This request led to the field locking debate, because one way to accomplish this is to allow Rating to directly (rather than via tricks) be instead shown as the underlying integer, thereby editable in exactly the same way as all other "text" fields. Same Rating integer data, just an alternative way to display and edit it.

If it seems "unnatural" that the Rating value of 0 to 5 might be shown as an integer rather than set of Stars, that restriction seems unnatural. MC accepts dates but it doesn't force them to appear as embedded calendar pages. Recording Duration isn't shown as a stopwatch. Etc.

[rick.ca]

Thanks, MusicHawk, for bringing this back on topic. I used the term "standard field" in the proper MC context to mean simply "field created by the developers and not added by the user." We don't need to engage the spurious argument that because they're called that they all must be fields meant to comply with some significant external standard. My whole point, as you have nicely outlined, is that this is not the case—and locking them all down as if it is unnecessary and counter-productive.

Categorizing fields the way you have is useful for understanding the issues. I'm not so sure doing so to determine how they are to be treated would work. For the most part it would, but then there would be exceptions and resulting confusion (e.g., a field is added as a "jump-start," but is also included in an external standard for a different media type). I'm happy to let the developers keep track of all the internal interrelationships and external standard compliance issues—as I'm sure they must. Just use that knowledge to lock what needs to be locked (whether that be specific field attributes or entire fields)—and leave the rest alone.

J.R STANDARD tags are in the library by default but can be excluded by the user (grayed-out...) so they don't appear in view designs, etc. Possibly they can be deleted, with a caution about breaking backward compatibility.

If the ability to change standard fields came with the ability to reset each field to it's default values (including restoring deleted fields which perhaps would be hidden rather than deleted), this would go a long way in addressing the concern about protecting users from themselves.

JUMPSTART tags are not in the library by default, but can be added by the user from templates. THEN they can be modified by the user individually, including change in datatype, display characteristics, even deleted.  Same idea as visualizations, etc.

So this is a nice idea, but I would have no problem with such fields being added, as long as I understand what they're for and have the ability to change or delete them.

I know I'm dreaming, but it would be really cool if the classification issue would be addressed head-on by making interrelationship and standards compliance information available in the field configuration (e.g., in a popup or tooltip). The coolest solution would be to use the program's own database capability to present a field table showing the purpose (i.e., intended record types), attributes, internal interrelationships (i.e., precedents, dependents), external standards (read and write). This would be particularly useful in cases where there is more than one relevant external standard—as with photos. Imagine being able to instantly see a list of fields used for a particular media sub type (including user-created sub types!) and all their settings. It would make organization and maintenance so much easier.

[genEus]

Maybe for those who are worried about accidentally changing the star rating, JRiver can put a checkbox somewhere in the Tools -> Options:

Use double-click to edit Rating

[rick.ca]

That would conflict with the current (configurable) double-click behaviour. But something very similar may be an effective option. A mouse-over currently puts the field into edit mode. If that required a click instead, the second click could be used to change the rating. (And if there is no second click, the state would return to normal when the mouse is removed.) The effect would be to protect the field from random clicks, yet still be changeable with a "two-click." The second click would just need to be delayed enough that a double-click is not registered.

[MusicHawk]

I second this!

Per my original post (so long ago), I request a change to MC so Rating Stars requires selection by first clicking INTO the field -- the same step that all the other fields require -- before allowing the value to be changed by the subsequent action.

[rick.ca]

Per my original post (so long ago), I request a change to MC so Rating Stars requires selection by first clicking INTO the field...

At first, I thought you were referring to your original post in this topic—in which you suggested everything but! Now I see you've been working on this a while...

If MC ever gains the ability to control how the Rating field works, I would happily switch back to using it.

You'll have to forgive me. This was 10 days before I arrived here. Maybe your mistake was to let on you had a workaround. Had you not done so, the new guy's suggestion would have be implemented by now.

[tunetyme]

I like the idea of first clicking into the field.  That would solve it for me!

[gappie]

I like the idea of first clicking into the field.  That would solve it for me!

i like the idea also..

 
gab

[MusicHawk]

To round out the request, the Rating Stars field should require clicking in (selecting) before it can be changed in ALL the places it appears, including these three: Tag Action Window, Playback Display, and View column.

I don't think the Stars are live when shown in a visualization but if so, that should be protected too.

And , I'm also still hoping to get the  optional ability to show and use the underlying number. And the ability to use a different number range. And the ability to use decimal numbers. And to have MC map all of these to 5 stars, or even better 5 half/full stars for a 10 point Rating range.