INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  

Poll

I like the new style of editing in the Action Window

Yes
- 3 (12.5%)
Doesn't matter
- 3 (12.5%)
Not every change
- 8 (33.3%)
No
- 10 (41.7%)

Total Members Voted: 24

Voting closed: October 28, 2010, 01:42:23 am


Pages: 1 [2]   Go Down

Author Topic: Poll: Action window editing behaviour  (Read 11098 times)

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: Poll: Action window editing behaviour
« Reply #50 on: October 18, 2010, 06:32:47 pm »

Here is a real world example of ripping a CD and using the new editing features to enter tags:

For the sub_genre tag (my own user defined field) I typed  "Or" and got this dropdown list:

"Choral"
"Or"
"Orchestral"

For the Album tag, I typed "Symphony No. 8" and got this list

"Symphony No. 8"
"Symphony No. 18"
"Symphony No. 28"
and
See all 12 results"

Somewhere in that list is a valid autocompletion possibility "Symphony No. 8 'Unfinished' ".  This choice should appear in the short list in place of the "18" and "28" choices.

If I click on "See all 12 results and then press Tab to get MC to accept what I typed, MC does not respond to the Tab key however many times I press it.  There are other anomolies in MC's behavior.  Sometimes I am unable to type additional characters into a field after I clicked to see all the suggestions.  If I switch to a different program and come back to MC, the tag field I was editing will have the focus  but I am unable to enter text or delete characters using the backspace key.  Pressing Backspace at this point dumped me out of the "Devices & Drives" view for my DVD drive to the Audio view.  This new editing feature is not ready for prime time.

Autocompletion is a good idea.  I do not want an aggressive spell checker in the Tag editing window. I do not want MC to be second guessing everything I type.  I do not want to sift through a list of bogus suggestions when I'm trying to enter tag values.

Bill
Logged

rick.ca

  • Citizen of the Universe
  • *****
  • Posts: 3729
Re: Poll: Action window editing behaviour
« Reply #51 on: October 18, 2010, 08:29:30 pm »

So it's probably safest at this point to switch to the Firefox (and older Chrome) model of requiring down + enter to accept a suggestion.  It simplifies tab navigation and avoids what advanced users are objecting to.

This is disappointing. You had it right the first time. The assumption most editing involves adding new values is false. Most of my data is, one way or another, imported. For the most part, it doesn't need editing. If it does, values do exist (even though they need to be changed) and getting a suggestion from those can be useful. All that's necessary is sensible way to change a suggestion to what is needed. That can often be an effective way to add a value that is new, but which should match the pattern or format of the existing data.

There are many editing/tagging situations where the desired value does exist. In many cases, the objective is to select one or more values from those that do exist—taking care not to create new values (e.g., categorizing something based on an established set of keywords or attributes). In all those cases, a suggestion system works great, and adding a new item is clearly an exception. Since the objective is to select an existing value, the idea that the typed value should be the default is absurd. The requirement of the additional keystroke to select the suggested value is inefficient and only increases the chance of error.

So it would seem there are conflicting behaviours, each of which is best suited to particular circumstances. This is not the sort of thing that can be resolved by making it optional. Virtually all users will face both circumstances, and then would have to waste time setting the option every time the circumstances changed. There needs to be one solution that handles both situations, even if that requires users to train themselves in it's proper use. So I wonder what purpose this discussion might serve other than to determine which behaviour should be favoured as the default.

I'm for the suggested value being the default. That's necessary if selecting existing values using the suggestion function is to be efficient. Adding new values is quite different. But in that situation, the user is typing what may be the entire string anyway. An extra keystroke or two to accept, reject or change a suggested value is not a significant imposition. Perhaps a tweak would help: After selecting suggestion so it can be changed to the desired new value, the new value could become the default—so pressing Enter on completion of the edit would add the new value.
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Poll: Action window editing behaviour
« Reply #52 on: October 18, 2010, 09:29:44 pm »

This is disappointing. You had it right the first time. The assumption most editing involves adding new values is false. Most of my data...

Sorry, but it seems that you lost the argument (that part of it anyway, I don't have strong feelings on the keyboard-only tag AW navigation thing).  More people had issues with the new system than liked it.  Having to hit DOWN + ARROW or SHIFT-Enter is not that big of a hardship.

I've been using Shift-Enter all night and it works great.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

MusicHawk

  • Citizen of the Universe
  • *****
  • Posts: 796
Re: Poll: Action window editing behaviour
« Reply #53 on: October 18, 2010, 11:00:32 pm »

I don't think this is a debate about whether MC does searching and suggesting -- no reason not to add these useful features and likely Matt can improve them over time. But there are two serious problems. Here's my attempt to state them, offer analogies for clarity, and suggest a solution.


This is partly a debate about whether the new mode is default field behavior -- happens first and foremost -- or optional -- happens when the user wants it.

Analogy: If MC gained the ability to give different view cells different colors (an actual request in the past), would it be welcomed? What if changing colors involved JR changing the arrow keys of MC so pressing up/down/left/right altered colors? Sure it would be possible to learn the new way, use Shift+Arrow to move to the next cell. but first the color change "suggestion" would have to be accepted, or another color chosen, or the original color re-selected. Nothing wrong with the new ability -- but should it break more basic functionality?


The other part of the debate is about inconsistent keyboard navigation/behavior, such as the broken navigation via Tab key. I (and apparently others) found MC to be very efficient at keyboard-only work. That long-lived (years!) behavior has vanished.

It might not seem to be a hardship to switch to different keys, but really, it is a HUGE change. Mouse fans might not realize how incredibly and intensely important keyboard behavior is to keyboard-centric users. Why change what users know and can probably do blindfolded, arbitrarily, to different keys, just to allow a new capability? Why not give the NEW capability the NEW keys?

Analogy: What if MC made guitars, but switched the D and E strings because, well, Google lists more songs in D than in E. Would guitar players welcome this "improvement"? A computer keyboard, and the software actions mapped to the keys, are identical in nature to a piano keyboard or guitar strings+fretboard. If you know how to "play", it's because your brain and hand muscles know exactly what will happen with each action, and have melded into a magical think-and-it-happens mode. Change ANYTHING and the brain-hand connection doesn't stumble, it breaks. It's the day the music died.


I suggest that JR treat MC like a mature product (version 15, after all), and assume that long-established keyboard-related behavior is permanent, not to be altered unless seriously flawed. Otherwise, users are repeatedly thrown off-balance, for what purpose? But of course allowing new behavior to be assigned to new keys.

Please introduce new capability as added invokable-when-needed behavior, not forced default behavior.


(Meanwhile, I'm holding at .122 on my editing PC and .80 on my music playback PC.)

Logged
Managing my media with JRiver since Media Jukebox 8 (maybe earlier), currently use Media Center for Audio/Music and Photos/Videos.
My career in media spans Radio, TV, Print, Photography, Music, Film, Online, Live, Advertising, as producer, director, writer, performer, editor, engineer, executive, owner. An exhausting but amazing ride.

rick.ca

  • Citizen of the Universe
  • *****
  • Posts: 3729
Re: Poll: Action window editing behaviour
« Reply #54 on: October 18, 2010, 11:14:08 pm »

Sorry, but it seems that you lost the argument...

I don't know how I could have lost an argument I just presented. I suppose what you mean is I'm arguing a lost cause. I prefer to believe that's not necessarily so. It's clear many, myself included, have issues with the new system. I don't see how this particular change is in the right direction or will somehow transform this into something others will no longer have any concerns about. Perhaps it's not "that big of a hardship," but neither was not having the change at all. What are we doing here if not discussing how to improve the software?
Logged

rick.ca

  • Citizen of the Universe
  • *****
  • Posts: 3729
Re: Poll: Action window editing behaviour
« Reply #55 on: October 19, 2010, 12:17:15 am »

This is partly a debate about whether the new mode is default field behavior -- happens first and foremost -- or optional -- happens when the user wants it.

While options may be a good thing, they usually come with costs. Developing software like this requires the benefits of additional capability and flexibility always be weighed against the cost of additional complexity and difficulty in maintenance and use. Clearly, it's always better to provide one effective means to an end than multiple means. Imagine a new user coming to this issue. Assuming the dust has settled and there's one editing behaviour that works as well as most things work in MC, the new user will simply set about learning how to use it. They won't have to learn two alternatives and have to then decide which is best for them. Even that's a simplification. I think most users face a variety of different editing situations. That may seem to call for options, but true flexibility would be the one system that adapts in a reasonable way to whatever the situation is. It easier to learn one system, and then just use it.

We seem to agree there are some things about this new system that need to change. I certainly hope this is still a work in progress, and the needed changes will come in due course. But you seem convinced the new system cannot meet your needs. Although I understand it will be quite different, I don't really see the circumstances you might have that it would be unable to handle effectively. I can imagine you being used to selecting items from a list, for example, and a suggestion system is very different. But it seems to me the latter is better suited to keyboard entry, and much more efficient. Although the suggestion system could be tweaked and improved (and I'm sure it will), from what I can tell, this is true whether the list of possible values is long or short, nested or flat, familiar or unfamiliar.

I think it unlikely we're going to see two different editing systems, or that these changes will be abandoned. Maybe if you can explain more clearly exactly where it creates a problem for you—assuming you're willing to give it a chance. Maybe that will suggest ways it could be made to better suit your needs. And just to be clear—I'm not talking about the broken navigation. I don't think you're seriously suggesting you get an option to use a system that works, while the rest of us can use one that's broken. ;)
Logged

MusicHawk

  • Citizen of the Universe
  • *****
  • Posts: 796
Re: Poll: Action window editing behaviour
« Reply #56 on: October 19, 2010, 11:54:20 am »

I've stated several times that the new capabilities are useful tools. What they should not be is the priority/forced way to work with MC.

A typical word processor provides a spell-checker, grammar checker, thesaurus, auto-correcter (regular quotation marks into "smart" quotes), etc. Wonderful tools. But, do they constantly jump in on top of the user, changing what the user types on their own, or pushing their suggestions to the front, forcing the user to agree or take extra steps to NOT agree?

Or do these tools sit in the background, always ready to assist the user, but ONLY when the user requests assistance? That's what happens in the word processors I've used. One user might set one or more tools to run automatically in real-time, while another user might invoke a tool only when needed via hot-key or menu, and yet another user might never want any of the available "help".

That's how data-changing tools in MC should work -- available, powerful, but under total user-control.

It's simply not right to have MC software persistently try to out-guess (er, "help") the user. The problem is solved if the new capabilities can be turned on/off, or called only when wanted: "Press F3 for suggestions based on what you have typed..." is far more productive than "Press Down+Enter to tell MC to stop bothering you...until the next field when it will bother you again".

It's not "two different editing systems" -- editing is editing: type what you want, or select it from a list you want to use. Humans do editing. Having the software do something you haven't requested is not editing, it is automated interference. When I'm trying to edit some fields of my data in my database, I'm not "searching" for anything. Being forced to confront "suggestions" is a problem, not a solution.

Of course, we are all second-guessing. It would be very helpful to have JR state exactly what problem the changes are intended to address. Discarding time-tested keyboard and editing behavior is a BIG change, so there must be a really good reason. What is it?

Why not do what word processors do: Provide the new ability in every field via hot-key/right-click? In turn, this would allow reverting basic editing to its former behavior, thereby overcoming almost all objections.

The final question is whether suggestions are useful, which depends on the situation. But having suggestions available when requested can be a huge help. I welcome the new capability, I just want to be in control of it.
Logged
Managing my media with JRiver since Media Jukebox 8 (maybe earlier), currently use Media Center for Audio/Music and Photos/Videos.
My career in media spans Radio, TV, Print, Photography, Music, Film, Online, Live, Advertising, as producer, director, writer, performer, editor, engineer, executive, owner. An exhausting but amazing ride.

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Poll: Action window editing behaviour
« Reply #57 on: October 19, 2010, 02:11:20 pm »

... But, do they constantly jump in on top of the user, changing what the user types on their own, or pushing their suggestions to the front, forcing the user to agree or take extra steps to NOT agree?

Careful.  One could argue against your case.  Word, being the most popular word processor, auto-corrects by default constantly.  You either have to hit Ctrl-Z to undo the auto-correct, or disable the various features.
Logged
The opinions I express represent my own folly.

MusicHawk

  • Citizen of the Universe
  • *****
  • Posts: 796
Re: Poll: Action window editing behaviour
« Reply #58 on: October 19, 2010, 02:34:10 pm »

I know, Word and other products suffer from show-off-itis. Because a feature exists, it is enabled as a "selling point".

But I've consulted some very large organizations, and a first thing they do is disable Word's auto-correct mode because it leads to mistakes and user frustration.

As you point out, Word's "helpful" features, however they behave out-of-the-box, can be disabled as desired, and used when appropriate. I'm requesting the same for MC's new features.
Logged
Managing my media with JRiver since Media Jukebox 8 (maybe earlier), currently use Media Center for Audio/Music and Photos/Videos.
My career in media spans Radio, TV, Print, Photography, Music, Film, Online, Live, Advertising, as producer, director, writer, performer, editor, engineer, executive, owner. An exhausting but amazing ride.

MusicHawk

  • Citizen of the Universe
  • *****
  • Posts: 796
Re: Poll: Action window editing behaviour
« Reply #59 on: October 19, 2010, 03:05:24 pm »

Another example using .132 (cuz I'm really trying to find the "good" in the new features):

1. Editing a track where the Artists (a custom list-type field) name is incorrectly stated as "Jackson, Python Lee".
2. In another field I have the correct "Python Lee Jackson", so I copy that to the clipboard.
3. I click the Artists field, which immediately opens to the Add: field.
4. I paste in "Python Lee Jackson", and MC immediately changes it to "Jackson, Python Lee", the very value I'm trying to get OUT of the database!

I assume this happens because MC finds "Jackson, Python Lee" in the list of existing values (from this very record!) so "suggests" it rather firmly.

After several tries, re-entering the database record and field, and using the mouse to click here and there, I was able to get MC to accept the correct value. But not via keyboard-only.

Once I could overwrite the wrong value, MC could not longer "auto-correct" good data into bad data. BUT... if a wrong but similar value also is in other records, it will keep getting suggested. This will potentially introduce bad data to good records because suggestions pop up even when simply traversing fields, and are far too easy to accept. 

And... fight this battle dozens and hundreds of times (my library is 80 thousand tracks, almost entirely hand-typed data) and the situation gets ugly.
Logged
Managing my media with JRiver since Media Jukebox 8 (maybe earlier), currently use Media Center for Audio/Music and Photos/Videos.
My career in media spans Radio, TV, Print, Photography, Music, Film, Online, Live, Advertising, as producer, director, writer, performer, editor, engineer, executive, owner. An exhausting but amazing ride.

rjm

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 2699
Re: Poll: Action window editing behaviour
« Reply #60 on: October 19, 2010, 04:01:13 pm »

I suggest that JR treat MC like a mature product (version 15, after all), and assume that long-established keyboard-related behavior is permanent, not to be altered unless seriously flawed. Otherwise, users are repeatedly thrown off-balance, for what purpose? But of course allowing new behavior to be assigned to new keys.

Bravo!
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Poll: Action window editing behaviour
« Reply #61 on: October 19, 2010, 04:23:42 pm »

Another example using .132 (cuz I'm really trying to find the "good" in the new features):

1. Editing a track where the Artists (a custom list-type field) name is incorrectly stated as "Jackson, Python Lee".
2. In another field I have the correct "Python Lee Jackson", so I copy that to the clipboard.
3. I click the Artists field, which immediately opens to the Add: field.
4. I paste in "Python Lee Jackson", and MC immediately changes it to "Jackson, Python Lee", the very value I'm trying to get OUT of the database!

I assume this happens because MC finds "Jackson, Python Lee" in the list of existing values (from this very record!) so "suggests" it rather firmly.

This is no longer the behavior as of build 135.  No need to fight battles already won.   ;)

But, yes, that is a perfect example of what was annoying me before.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

mark_h

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1854
Re: Poll: Action window editing behaviour
« Reply #62 on: October 19, 2010, 04:30:35 pm »

Build .135 is released  ?
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Poll: Action window editing behaviour
« Reply #63 on: October 19, 2010, 05:13:07 pm »

Build .135 is released  ?

Not yet publicly, but I don't think it'll be long now.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: Poll: Action window editing behaviour
« Reply #64 on: October 19, 2010, 05:58:26 pm »

This is no longer the behavior as of build 135.  No need to fight battles already won.   ;)

But, yes, that is a perfect example of what was annoying me before.

I'm still finding things to annoy me in build 135.

I often fill out the album tag and copy it to the clipboard to be pasted back into my work name tag.  If I type the Down + enter keystrokes to accept a suggestion and then Ctrl C to copy the value to the clipboard, the Tab key will not advance to the next field however many times I press it.

The UI behavior on list fields seems bizarre to me. 

If I press enter for a empty list field or after typing a value, MC exists the list field.  However, it is not obvious where the focus is.  It does not appear to be on the field following the list field.  It appears that the focus is no longer in the tag edit window at all.

If I press Tab for an empty list field or after typing a value, nothing happens.  This is inconsistent with the way Tab works for regular single value fields.

I'm still trying to understand how keystrokes are interpreted when the focus is on a list field.  Sometimes MC will not accept a typed value if either Enter or Tab is typed.  Ctrl Tab worked in one such case.

I hope that Build 135 will not be released for general use.  It isn't ready.

Bill
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Poll: Action window editing behaviour
« Reply #65 on: October 19, 2010, 06:13:26 pm »

The UI behavior on list fields seems bizarre to me.  

Yeah, the list field UI was buggy, but 136 appears to focus on that.  That's why they make these beta for a little while, so they can avoid public shunning when changes aren't perfect the first time around.

I often fill out the album tag and copy it to the clipboard to be pasted back into my work name tag.  If I type the Down + enter keystrokes to accept a suggestion and then Ctrl C to copy the value to the clipboard, the Tab key will not advance to the next field however many times I press it.

I think this may have been fixed in 136 too.  But if not, then something else is going on.  I certainly can copy the value to the clipboard in your example.  It is even smart enough to not force you to select the text (or hit Control-A) before allowing you to copy it to the clipboard.  It Just Works (just as you described).

But, learn to use the Move/Copy Fields tool.  ;)

And that brings up something else I wanted to point out... I understand that there are UI concerns over the List Type Field editor (particularly keyboard navigation).  It looks like they've been fixed to me now, though, but either way... Those need to be fixed, for sure, and it needs to work reasonably well.  However...

Why in the name of all that is holy are you people editing list-type fields in the Tag Action Window?!?

I do that occasionally, when I just have a quick one-off that I need to tag.  Sometimes, I also use the List Type editor to define a new list entry (for fields with predefined lists)...  But if I'm doing any more than a single file, I use view schemes and Pane Tagging or Drag-and-Drop to the Tree Tagging to handle just about all of my list-type field tagging.  That's one of the most powerful features of MC!  If you use a bunch of List Type fields, and you haven't spent the time to build a couple of tagging-specific view schemes and explored the power of Pane Tagging, then...  I don't know.  Try it.  Now.  Seriously.

That feature alone (and Drag-Dropping to the tree) makes tagging hierarchies of files with a pre-defined taxonomy simple-as-pie.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Poll: Action window editing behaviour
« Reply #66 on: October 19, 2010, 07:03:53 pm »

Why in the name of all that is holy are you people editing list-type fields in the Tag Action Window?!?

In all seriousness... I'm sure there are plenty of legitimate reason to use it, but there also might be a bunch of people out there who don't realize how useful pane and drag-drop tagging can be.

Drag-dropping onto the tree in particular is fantastic for tagging whole hierarchies and multiple tags at once.  If you want to tag a set of files with a whole bunch of tags that are already in the library, it can't be beat.  Make a "tagging" view, turn on the Populate Tree setting for that view, and give it a whirl.

For keyword-like fields with a predefined taxonomy, you can't beat selecting the files and checking a few boxes in the pane.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

MusicHawk

  • Citizen of the Universe
  • *****
  • Posts: 796
Re: Poll: Action window editing behaviour
« Reply #67 on: October 19, 2010, 07:04:56 pm »

I have to disagree. Pane tagging is NOT the same as editing fields in the Tag action window, which is not the same as editing fields in a view row/column, which is not the same as pane tagging, etc. Each is useful, but none are direct substitutes for each other -- not for keyboard-centric fast data entry/editing. This was true before the current keyboard chaos, and likely will remain true because the different ways to edit fields have (appropriate, mostly) different behaviors.

Apparently, one problem with this discussion is, we're coming from different perspectives. Keyboard-centric users have a very different MC UI experience than mouse users, and it's the keyboard behavior that is quite broken.

Re the Move/Copy Fields tool, it's some steps via mouse, which I use when I need to touch lots of records, especially when the records and key fields aren't right in front of me in a view. But it is no substitute for Ctrl+C, Ctrl+V, two very fast keyboard editing actions to manipulate data that is at my fingertips. A tool and a keyboard action are different methods for different purposes, as is pane tagging.

I'm back to using .122 on my editing PC, and I just did a bunch of tagging -- a thousand files, entirely by keyboard, editing typos, adding/updating several list-type fields, and in general zipping around among records and fields quickly and smoothly. The efficiency of MC is fabulous ... or, was. It's a mind-boggling disaster that it has been discarded.
Logged
Managing my media with JRiver since Media Jukebox 8 (maybe earlier), currently use Media Center for Audio/Music and Photos/Videos.
My career in media spans Radio, TV, Print, Photography, Music, Film, Online, Live, Advertising, as producer, director, writer, performer, editor, engineer, executive, owner. An exhausting but amazing ride.

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Poll: Action window editing behaviour
« Reply #68 on: October 19, 2010, 07:17:21 pm »

I understand... Like I said, there are certainly legitimate reasons.

Still... I bet you've NEVER used drag-drop tagging in the tree.  MC's mouse-driven UI features can be incredibly efficient too.  I'm not a "mouse guy" or a "keyboard guy".  I think that's absurd.  I use the fastest, easiest, and most efficient tools I can find (and remember how to use).

With some programs, using a keyboard for just about everything possible is way faster.  But that is really a sign of the quality (or lack thereof) of the UI more than anything else.

I'm back to using .122 on my editing PC, and I just did a bunch of tagging -- a thousand files, entirely by keyboard, editing typos, adding/updating several list-type fields, and in general zipping around among records and fields quickly and smoothly. The efficiency of MC is fabulous ... or, was. It's a mind-boggling disaster that it has been discarded.

Wow with the melodrama.   ;) ;D

Patience, grasshopper.  Very rarely does J River ignore things like this.  Give them time.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

bunglemebaby

  • Galactic Citizen
  • ****
  • Posts: 469
Re: Poll: Action window editing behaviour
« Reply #69 on: October 19, 2010, 07:36:43 pm »

Why in the name of all that is holy are you people editing list-type fields in the Tag Action Window?!?
I do that occasionally, when I just have a quick one-off that I need to tag.  Sometimes, I also use the List Type editor to define a new list entry (for fields with predefined lists)...  But if I'm doing any more than a single file, I use view schemes and Pane Tagging or Drag-and-Drop to the Tree Tagging to handle just about all of my list-type field tagging.  That's one of the most powerful features of MC!  If you use a bunch of List Type fields, and you haven't spent the time to build a couple of tagging-specific view schemes and explored the power of Pane Tagging, then...  I don't know.  Try it.  Now.  Seriously.

I've actually set up a number of different pane based tagging schemes, but I find I don't use them that often for the simple fact that when I filter the files via the search box in order to narrow down to the files I want to tag, most of the list items disappear from the pane. Now I of course want this behavior in a filter/play view scheme. So, this is all to say since we're on the general topic of tagging here would adding a view scheme option to "not filter pane options" or something better-described be reasonable??

Quote
Drag-dropping onto the tree in particular is fantastic for tagging whole hierarchies and multiple tags at once.  If you want to tag a set of files with a whole bunch of tags that are already in the library, it can't be beat.  Make a "tagging" view, turn on the Populate Tree setting for that view, and give it a whirl.
TBH, I've always been very curious about this but it is so unintuitive from the starting line that I've never actually investigated it. Are strategically designed view schemes necessary to make it work well? The tree in general always puts me off as being large and unwieldy. I currently have it turned off for ALL view schemes.

Other than that, I'm just looking forward to the latest updates to all this. I was worried that everybody else loved the new tagging system and I'd be stuck with it as it is in b135.


Logged

rick.ca

  • Citizen of the Universe
  • *****
  • Posts: 3729
Re: Poll: Action window editing behaviour
« Reply #70 on: October 19, 2010, 08:01:46 pm »

Why in the name of all that is holy are you people editing list-type fields in the Tag Action Window?!?

I probably shouldn't bother, as I've explained before—and the tone of this suggests you've already decided the answer. But since this is in the name of all that is holy, I suppose I have to repeat myself... ;D

First, Pane Tagging is wonderful, and I agree that anyone who hasn't tried it should. But it's not always the most efficient way to tag. There's no question it should be used if the list of possible values is short enough they're all visible in the panes. And for nested lists, it's often possible to display the values applicable to the files being tagged by expanding only the necessary branches. That tends to work, for example, with a batch of photos that are all similar (e.g., all from the same location, day, event).

On the other hand, if there are too many possible values and/or the items being tagged are too varied, then it becomes cumbersome. The new edit system provides fast random access to any of the possible values. Instead of expanding and collapsing lists (if they're even nested) and visually searching for the desired value, it can be found with just a few keystrokes. Typing "pup" <Enter> is very much faster than finding and checking Nature\Animals\Pets\Dogs\Puppies. And, of course, it works equally well if you can't remember such a convoluted nesting structure—just type "dog" (or any of the branches) or maybe the puppy's name. If you know your own organization scheme well enough, you'll find the value instantly. If not, the suggestion system will probably still help you find it faster than navigating a tree in a pane.

I mention a nested list only as an example. I suppose many users don't use those anywhere. But the same idea applies to a simple list field. The suggestion system will find applicable values no matter where the typed value appears in the string. So for a name list, for example, that means we can find an existing value by typing any part of the name. It's not necessary to remember both first and last name, or the order in which they're presented in the list. Maybe the old system did something similar (I don't recall), but the new system is certainly not less capable in this regard.

As a completely separate matter, there's the situation where one is engaged in a broader editing exercise (e.g., adding new files) and many different types of fields are being edited. Then it's important that this editing system be able to effectively handle any list fields encountered as one is editing a sequence of fields.

Finally, although the need is debatable (I'll leave that to MusicHawk), any need for rapid, high volume data entry is not going to be met by a visual tick-the-box-with-the-mouse system. It requires the use of the keyboard, and software that responds to simple, logical and consistent keystrokes. I don't believe this should be the only criteria for deciding how this editing system should work with a keyboard, but it remains a valid benchmark. In other words, the method that is faster, more logical and involves fewer keystrokes for the most common operations is likely to be the best all around.

Quote
With some programs, using a keyboard for just about everything possible is way faster.  But that is really a sign of the quality of the UI more than anything else.

Obviously there are programs for which the keyboard is faster only because the UI sucks. To suggest that has any bearing here is spurious. A valid analogy would be an accounting system. There was a day when most would argue the only thing that mattered for any accounting system is it's ability to accept rapid data entry via the keyboard. That's no longer true, as the same software is typically used by the data entry clerks, the CFO and anyone else interacting with financial systems. Now the accounting system must be able to handle a wide range of different data entry/editing situations. The same is true for anything as broad and versatile in it's application as MC.
Logged

MusicHawk

  • Citizen of the Universe
  • *****
  • Posts: 796
Re: Poll: Action window editing behaviour
« Reply #71 on: October 19, 2010, 08:53:58 pm »

Quote
I bet you've NEVER used drag-drop tagging in the tree

You bet wrong, but it's irrelevant, not a solution to the current situation. Like Move/Copy Fields, Drag-Drop is useful for batches of records that have the same updating need. It's good to have batch tools, and no problem using a mouse to manipulate them.

But drag-drop is of zero value when adding/editing MANY fields of ONE record at a time, each record different from others. That requires the keyboard, and once the user settles into keyboard mode for data adding/editing, it's a huge help if the keyboard can also do the necessary navigation. This is why Tab and other record/field navigation behavior is equally as important as the actual field editing. Both must be smooth and consistent.

The record-field data uniqueness that leads to the keyboard perhaps is much more common with a large, varied music library then with, say, photos where dozens might be of the same people and place. That's one of the situations where I drag-drop!

So, the frustrated users might boil down to those of us managing large/growing heterogeneous music libraries, who are regularly working with individual records, AND who are fluent on the keyboard, probably touch typists. For us, MC's recent change is like having a car swap the function of gas and brake pedals depending on whether we're on a "Street" vs. "Avenue", compounded by the engine dying in every parking lot. (Sorry, I like analogies...)
Logged
Managing my media with JRiver since Media Jukebox 8 (maybe earlier), currently use Media Center for Audio/Music and Photos/Videos.
My career in media spans Radio, TV, Print, Photography, Music, Film, Online, Live, Advertising, as producer, director, writer, performer, editor, engineer, executive, owner. An exhausting but amazing ride.

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Poll: Action window editing behaviour
« Reply #72 on: October 19, 2010, 09:09:36 pm »

Look.  That's why I said this, and why posted my followup:

I understand that there are UI concerns over the List Type Field editor (particularly keyboard navigation).  It looks like they've been fixed to me now, though, but either way... Those need to be fixed, for sure, and it needs to work reasonably well.

There's no need to take anything personally, or pose it in an adversarial way.  I'm not saying what anyone is doing is stupid.  Just that maybe some people should broaden their horizons (and there absolutely are keyboard-entry fanboys in the world, who occasionally miss opportunities because of it).  I'm also a pretty big keyboard-accessible UI fan!  I run Final Cut every day, after all.

I'm just saying that some people might benefit from trying those features out if they haven't used them extensively.  Think about your views and how they can be crafted to use that system.  I'm not necessarily even saying this to anyone who posted in this thread.  There are plenty of lurkers out there.

First, Pane Tagging is wonderful, and I agree that anyone who hasn't tried it should. But it's not always the most efficient way to tag.

Thanks.  That's what I said, just in reverse.  I agree completely.

On the other hand, if there are too many possible values and/or the items being tagged are too varied, then it becomes cumbersome. The new edit system provides fast random access to any of the possible values. Instead of expanding and collapsing lists (if they're even nested) and visually searching for the desired value, it can be found with just a few keystrokes. Typing "pup" <Enter> is very much faster than finding and checking Nature\Animals\Pets\Dogs\Puppies. And, of course, it works equally well if you can't remember such a convoluted nesting structure—just type "dog" (or any of the branches) or maybe the puppy's name. If you know your own organization scheme well enough, you'll find the value instantly. If not, the suggestion system will probably still help you find it faster than navigating a tree in a pane.

That is certainly true, and there are absolutely many cases where you're right.  But, generally, you are still thinking of it a bit more limited than I mean.  Using the tree and a well structured scheme, you can apply tags 5 or 6 or 7 different fields simultaneously with one drag-drop operation.  Using Pane Tagging is often MUCH more efficient when you need to apply 18 different Keywords to a set of files, and then 7 more to a subset, and then 4 more to a sub-subset.  Typing in one (or even two or three) keyword is certainly quicker in the Tag AW.  Typing in 28 isn't.  When you count the time multiple operations take in the Tag AW, that's when the power of the other methods shines through.  There is not always just one answer to a question, and often the proper tool depends on the situation.

So for a name list, for example, that means we can find an existing value by typing any part of the name. It's not necessary to remember both first and last name, or the order in which they're presented in the list.

That is very true.  The new suggestion system is awesome.  I really like it now.  Though it still requires you to remember some piece of the taxonomy.  Sometimes things get missed.  The searching in MC is still not heavy on the synonyms (you know, mouse=mice, blue=teal, etc).  That means that if you want to properly keyword things, sometimes browsing through a taxonomy tree is the best way, when other people who don't "have a grasp on your system" might need to... You know, find something.  It might not always be the quickest, but quickest isn't always best.

Finally, although the need is debatable (I'll leave that to MusicHawk), any need for rapid, high volume data entry is not going to be met by a visual tick-the-box-with-the-mouse system.  It requires the use of the keyboard, and software that responds to simple, logical and consistent keystrokes.

But it was me that had already made up my mind?   ;D

I don't believe this should be the only criteria for deciding how this editing system should work with a keyboard, but it remains a valid benchmark. In other words, the method that is faster, more logical and involves fewer keystrokes for the most common operations is likely to be the best all around.

Obviously there are programs for which the keyboard is faster only because the UI sucks. To suggest that has any bearing here is spurious. A valid analogy would be an accounting system. There was a day when most would argue the only thing that mattered for any accounting system is it's ability to accept rapid data entry via the keyboard. That's no longer true, as the same software is typically used by the data entry clerks, the CFO and anyone else interacting with financial systems. Now the accounting system must be able to handle a wide range of different data entry/editing situations. The same is true for anything as broad and versatile in it's application as MC.

I agree, and that was my point.  I never said how a system works with a keyboard wasn't important.  It is obviously enormously important.  But it isn't always the best way.  Sometimes it is, sometimes it isn't.  That's all.  I personally find, that in many cases when working with List Type fields, it is NOT the most efficient or the best way in this application, once you are set up for some alternatives.

But drag-drop is of zero value when adding/editing MANY fields of ONE record at a time, each record different from others.

Actually, no.  That is precisely its most useful value.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Poll: Action window editing behaviour
« Reply #73 on: October 19, 2010, 10:45:21 pm »

Actually, no.  That is precisely its most useful value.

I realized upon reflection that the above statement doesn't make very much sense without further explanation.  It is precisely its most useful value because it helps to prevent the very situation you described.  It can help stop you from having to tag things one at a time, all mixed together (or keeps it to an absolute minimum).  Having to tag things by hand one at a time with no grouping or context for the "import" is the "nightmare scenario".  I strive to never let myself be in that situation.

When I'm tagging, I tend to "bubble sort" the list.  I select and subselect in the file list (usually via searches and Control-A, not the mouse, but occasionally I do it manually if it is faster), batch editing in every conceivable way possible.  I try to tag as much as is humanly possible in batches before ever entering anything manually.  Often, I batch edit the data via the Tag AW (which is why it mattered to me in this thread, obviously), but not always.  Usually, you can avoid the one-at-a-time tabbing through the files except for one or two fields ([Name] and [Description] fields end up biting me the most). But even then using the in-place editing in the Details Columns is sometimes quicker (if you have to manually set a bunch of [Name] fields, that usually works well).

Of course, I strive to extract as much metadata out of the existing filename structure as is possible.  That covers many things, but if you have a bunch of non-homogeneous filenames, you can't always get it from the filenames (though Find and Replace Expressions are powerful).  In these cases, you can use drag drop to simultaneously tag: [Artist], [Album], [Genre], [Subgenre], [Media Sub Type], and [Keywords] all at once literally with one "drop".  Need a few more keywords added?  Just take the files you already have selected, and the portion of the tree you already have open, and drop them in 4 or 5 or 6 more places (actually, I almost always have a keywords pane available, so I usually just do it there).

That is certainly not the best method for all situations, but it sure can be for a lot of them that I encounter every day.

But, of course, I also try very hard not to have a situation with a bunch of non-homogeneous files to tag, because that slows me down and makes me data enter it manually, like filling out a spreadsheet.

But again, none of that is to say that being able to, when it is needed, tab through the Tag AW isn't necessary!  Absolutely not.  And, my way may very well not be the best way for you, and the way you organize your data, and your file set or workflow (sounds likely).  Heck, if you happen to be working on laptop, then drag-dropping and point accurate mousing is NEVER going to be the most efficient way.  I change my behavior dramatically when I'm on a machine with limited (or alternative) input options.  Crafting my technique to the tool available.  Similarly, if you happen to just not be very good with a mouse, then maybe mouse-based methods would never work well for you.  Personally, I'm EXTREMELY fast, accurate, and precise with the mouse (a skill I honed over many years spent hunting headshots with a sniper rifle in the latest FPS game du jour).  I can swing my 5000dpi mouse across the pad and cross all three 1080p monitors in the blink of an eye and stop on a dime.  I often have my mouse pointer positioned and waiting for a button or checkbox or radio button to appear while waiting for the UI to bring up a dialog box.  But I also know someone at work who is a very talented designer, but he is comparatively bad with the mouse, but can type and mash the keyboard to switch all around the OSX UI like it's nobody's business.  My boss almost never touches a mouse, and does almost everything with her Wacom pen, and one hand on the keyboard.

But knowing the alternatives sure might be useful for a lot of people who don't know that there are other options.

So anyway... MusicHawk and rick.ca: We almost entirely agree on everything.  Maybe not the exact details, but pretty much we agree.

So, the frustrated users might boil down to those of us managing large/growing heterogeneous music libraries, who are regularly working with individual records, AND who are fluent on the keyboard, probably touch typists. For us, MC's recent change is like having a car swap the function of gas and brake pedals depending on whether we're on a "Street" vs. "Avenue", compounded by the engine dying in every parking lot. (Sorry, I like analogies...)

You'll probably like the next build that comes out on the public board.  Look for it.  The system in the build from last Friday is not untouched by any means.  Those J River guys get a bunch of stuff done in a couple of days.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

rick.ca

  • Citizen of the Universe
  • *****
  • Posts: 3729
Re: Poll: Action window editing behaviour
« Reply #74 on: October 19, 2010, 11:15:42 pm »

I agree, and that was my point.  I never said how a system works with a keyboard wasn't important.  It is obviously enormously important.  But it isn't always the best way.  Sometimes it is, sometimes it isn't.  That's all.  I personally find, that in many cases when working with List Type fields, it is NOT the most efficient or the best way in this application, once you are set up for some alternatives.

Hmmm. It's getting increasingly difficult to figure out what anyone agrees with or what their point is.  :-\

Maybe I haven't been clear, but I was never arguing that any one method was better than another. On the contrary, I've been trying to make the point that different methods are necessary or better in different circumstances, and therefore both need to be supported. Now by "method," I'm referring very generally to whatever a user does to get something done in a particular circumstance—not the precise methods offered by the software. The form that takes will vary. So, for example, we've been discussing how pane tagging and the edit routine can both be used for tagging. Which one is best depends on the circumstances at hand, including user preference. But I've also argued that, to the extent possible, the editing system itself should be designed to handle as wide variety of different "user methods" as possible. So I disagree there should be multiple optional editing systems, even though others might see that as a legitimate way to support alternate methods.

It seems to me many of the comments here have been along the lines of "this is how I do it, so I like/dislike these changes." I don't understand the expectation. Does anyone seriously believe that good software is designed by listening to he who complains longest and loudest? I think a sign of good software design is the ability to handle many different circumstances and methods in a way that makes each user feel it was designed just for them. It never ceases to amaze me that I can start doing something new, or even more interesting, "discover" there's a different and better way to do something—and the software already supports it. The only reason I'm commenting on this is to contribute to a discussion that hope would help the developers maintain this fine tradition.

But perhaps I should take the hint when the President of the company refers to the discussion as a "food fight." ::)
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Poll: Action window editing behaviour
« Reply #75 on: October 19, 2010, 11:17:56 pm »

Hmmm. It's getting increasingly difficult to figure out what anyone agrees with or what their point is.  :-\

Maybe I haven't been clear, but I was never arguing that any one method was better than another.

Me either.  Certainly not universally.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: Poll: Action window editing behaviour
« Reply #76 on: October 20, 2010, 12:19:52 am »

It seems to me many of the comments here have been along the lines of "this is how I do it, so I like/dislike these changes."

I state my own experience and my needs as clearly as I can and do not try to proclaim that my experience and my needs are all that matters.  I leave room for other people to state their views.

I don't understand the expectation.
Does anyone seriously believe that good software is designed by listening to he who complains longest and loudest?

I cited specific behavior in the new editing scheme that I felt was just wrong.  When I found more to report, I did.  You may think that pointing out problems is just complaining.  You are welcome to that opinion.

I think a sign of good software design is the ability to handle many different circumstances and methods in a way that makes each user feel it was designed just for them.

Input from experienced users should be quite relevant to producing such software.

Bill
Logged

rick.ca

  • Citizen of the Universe
  • *****
  • Posts: 3729
Re: Poll: Action window editing behaviour
« Reply #77 on: October 20, 2010, 01:58:03 am »

Input from experienced users should be quite relevant to producing such software.

Of course it is. But it's only effective if it's constructive. Like your post from earlier today. While I don't care if you choose to be annoyed, the information provided was otherwise factual, relevant and therefore potentially useful.

I thoroughly dislike the new editing system.  Here are some of the reasons...Thanks JRiver...You haven't done me any favors with these changes.

This was not.
Logged

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: Poll: Action window editing behaviour
« Reply #78 on: October 20, 2010, 02:31:16 am »

Of course it is. But it's only effective if it's constructive. Like your post from earlier today. While I don't care if you choose to be annoyed, the information provided was otherwise factual, relevant and therefore potentially useful.

In one of your earlier posts, you presented your opinions as unassailable facts and dismissed other points of view..  I consider that to be counter-productive.

You cited this from an earlier post I made:

"I thoroughly dislike the new editing system.  Here are some of the reasons...Thanks JRiver...You haven't done me any favors with these changes."

and you said "This was not [constructive.]"

In my post, I provided detailed reasons why I considered the changes to be a step backward.  I depend on MC and I really don't want to make it less useful to me.  Several other people have expressed similar sentiments.  I ended with a frank statement that I considered the new editing scheme a step backward.  I'd say it is a frank statement of concern.

You have done a lot of whining in this thread about the fact that other contributors did not agree with your views.  In my last post, I objected to this line in your preceding post "It seems to me many of the comments here have been along the lines of "this is how I do it, so I like/dislike these changes." 

To me, that is an attempt to diminish what other contributors have said.   Stating your own experiences and your needs is a positive contribution to this thread.  Asserting that you have superior knowledge and superior reasoning as a way to dismiss others views is not a positive contribution.

Bill




 
Logged

MarkCoutinho

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 661
Re: Poll: Action window editing behaviour
« Reply #79 on: October 20, 2010, 02:34:41 am »

Come on, you guys... This is starting to be way off topic.
The reason why I posted this poll was to question the new Action Window edit-features. And as far as I've understood from Matt these changes are history (or embedded in a less forcing way) in the next release.
Logged
Mark Coutinho
Dutch Top 40 collector of lyrics, sleeves and bios

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: Poll: Action window editing behaviour
« Reply #80 on: October 20, 2010, 02:44:13 am »

Come on, you guys... This is starting to be way off topic.
The reason why I posted this poll was to question the new Action Window edit-features. And as far as I've understood from Matt these changes are history (or embedded in a less forcing way) in the next release.

I appreciate your starting this thread.

I haven't seen a build that fixes the Tab key inconsistencies. I am hopeful.

Bill
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 41974
  • Shoes gone again!
Re: Poll: Action window editing behaviour
« Reply #81 on: October 20, 2010, 08:59:59 am »

I'm going to close this topic now.

We have tried to incorporate a lot of the feedback from this thread into build 136:
http://yabb.jriver.com/interact/index.php?topic=60079.0

If you still have issues with build 136, please start a thread with specific changes you would like.

Also, please try to keep the discussion about the popup suggestion system and the new list editor user interface separate.

Thanks for the help everyone.
Logged
Matt Ashland, JRiver Media Center
Pages: 1 [2]   Go Up