Bug 329298

Summary:	Use Context View for "Edit Track Details" dialog
Product:	[Applications] amarok	Reporter:	Jakob Petsovits <jpetso>
Component:	Metadata Editing and Reading	Assignee:	Amarok Bugs <amarok-bugs-null>
Status:	REPORTED ---
Severity:	wishlist	CC:	123kash, datafer2, thomas.pfeiffer
Priority:	NOR	Flags:	myriam: Usability-
Version First Reported In:	2.8.0
Target Milestone:	2.9
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	duplicate date in tags

Description Jakob Petsovits 2013-12-28 05:08:42 UTC

Having a separate dialog pop up to check and edit metadata just about works for a single file but gets progressively cumbersome with more files involved. There are a few pain points here:

* While the "Edit Track Details" dialog is not a modal dialog (which in itself is a good thing as you can still control playback and other stuff), it makes Alt-Tab switching a pain. This is especially important since editing tags often involves copying and pasting from a browser window, where a situation with two task bar items but three windows becomes a big mental overhead and an annoyance when you (often) hit the wrong window.

* If I want to select a different set of songs, I have to close and re-open the dialog (tree clicks alone for getting back into the dialog, not including clicks for selecting different songs). There is room for improvement here.

* To make up for inefficient re-selection of tracks, the dialog has two modes, one for jumping through the selected tracks one by one, and the other for editing all of them at the same time. Both suffer from a lack of context: For the multi-file editing mode, I have to keep the list of edited files in my head or face the threat of making edits to the wrong files; for the single-file editing mode, the edited file is delightfully dissimilar to both the currently playing track and the currently selected ones (assuming I'm editing several). I have to make that connection in my head without Amarok helping me to more context. This is especially annoying when either tags or filename are out of whack, which happens to be a main use case as to why you would like to open the dialog in the first place.

* The dialog duplicates much of the information that is already displayed in the context view.

What made the Amarok 1.x metadata editing great was that all the context from the playlist could be immediately and efficiently reused (both mentally and interaction-wise) for its in-place editing. Given Amarok 2's playlist layout, in-place editing there obviously doesn't make much sense anymore. However, I think putting the main pieces of the "Edit Track Dialog" inside the context view would be similarly capable and efficient, and make all of the above pain points disappear while the drawbacks are limited.

The main two drawbacks I can think of are:

* Currently, the context view always displays information purely about the current track. As metadata editing ought to correspond with selected tracks, there is a conceptual conflict here. This could either be ignored (I think the usefulness of not having a separate dialog greatly outweighs the inconsistency, and it's only for editing), worked around (e.g. by marking both the edit "view" and the selected files with a color, say, yellow, for the time that editing is active/possible), or the interaction concept could be changed to remove the selection on a "play" double click or Skype-style unselection, so that when users can consciously set the selection to explore the context for tracks that are not currently playing. Maybe you've got a wholly different idea as well, let me know.

* If editing is tied to the playlist selection, it won't be possible (or at least, won't make sense interaction-wise) to edit files that are not in the playlist but just in the collection. I don't think that will annoy many people as it's easy to drag files over to the playlist. Alternatively, in the vein of the above interaction concept change idea, the selection could apply to either the playlist or the collection browser but not both simultaneously, in which case an "Edit Track Details" view in the context view would make sense.

Let me know what you think!

Comment 1 Jakob Petsovits 2013-12-28 05:19:08 UTC

Editing fail (sorry):
"...so that when users can consciously set the selection to explore the context for tracks that are not currently playing." should be
"...so that users can consciously set the selection to explore the context for tracks that are not currently playing."

Comment 2 Myriam Schweingruber 2013-12-28 12:23:41 UTC

Please make suggestions like this to the amarok-devel@kde.org mailinglist, as it is not a bug, nor a feature request per se, but a usability change suggestion.

Comment 3 Myriam Schweingruber 2013-12-28 12:39:30 UTC

Using the Context View for sure is the worst idea possible, as it is not meant for editing at all, but for displaying information about the current track.

Also, Amarok 2.x has never been meant to be a mass-tagger, there are far better tools out there to do so like kid3, or easytag or picard, to only mention a few. This was a deliberate choice of the developers, to avoid making the same errors again we already did in the 1.x series. You should not use the "edit Tracks Dialog" to do mass editing at all., but use the appropriate tools.

That for sure is a clear -1 from me, adding unnecessary complexion to a code base we have to maintain.

Comment 4 Jakob Petsovits 2013-12-28 13:08:47 UTC

I understand that the Amarok team made these design choices, I'm not telling you to backtrack or compromise on those. As for the quality/usability of the other tools, that's debatable and doesn't need to be discussed in this bug; personally, I greatly appreciate having the context of my currently playing music at hand, especially since the collection concept abstracts away much of the file locations that I have to painfully provide to those other tools.

What I was trying to do is provide suggestions to improve a feature that is already in Amarok while not degrading the experience of other existing features. New features and improvements to existing functionality add more complexity all the time, and it's usually considered worthwhile if the added or changed functionality is considered desirable. It's the Amarok team's decision whether or not supporting their metadata editing functionality is desirable, and also whether my suggestion can fit into the current paradigm.

Personally, I think if you don't want people to use the feature at all then you should remove it entirely and actually reduce complexity this way rather than hiding it behind an unloved dialog. Getting rid of features that you're not interested in supporting or improving might be in everybody's best interest.

The other question, of course, is what the rationale behind the "display and never edit info only for the current track" idea is, and whether any changes to that narrow definition could still satisfy your requirements for the desired user experience. After all, that constraint doesn't stand by itself, it serves a purpose. I'm not familiar enough with Amarok development to be able to clearly state what exactly that purpose is, but I trust you to make decisions based on the underlying objective (e.g. "provide an automatic, immediately understandable UI while minimizing code complexity") rather than an arbitrary rule that was derived from those. It's sometimes possible to violate the latter while still satisfying the former.

Comment 5 Jakob Petsovits 2013-12-28 13:14:09 UTC

To make sure I expressed myself clearly, the suggestion above was to remove the "Edit Track Dialog" and replace its functionality with an applet (I think that's better than an overlay, although that might also work) in the context view. Not all of the complexity from the dialog would have to be transferred as much is available in various applets already. (For instance, the Lyrics tab could simply disappear as the Lyrics applet already has an edit mode. Which, by the way, shows that the situation is not as straightforward as a simple "no edits in the context view".)

Comment 6 Thomas Pfeiffer 2013-12-29 15:37:15 UTC

Please keep in mind that inline editing in the playlist is possible in Amarok 2.8. That may on the one hand suggest that there already is a place for editing metadata in context, but on the other hand also means that people may expect to be able to edit within the "current track" applet as well.

To me, this speaks for allowing editing within the "current track" applet in a similar fashion to editing within the playlist. However, what should _not_ be done is editing metadata for any other track than the one currently playing. For the context view, the context is always the currently playing song, not the entire playlist,and changing that would break consistency and confuse users.

Comment 7 datafer2 2021-07-29 20:40:59 UTC

Created attachment 140399 [details]
duplicate date in tags

Hi.
I receive this duplicate date in tags.
What can i do?
Thanks

Comment 8 Myriam Schweingruber 2021-07-31 07:38:02 UTC

(In reply to datafer2 from comment #7)
> Created attachment 140399 [details]
> duplicate date in tags
> 
> Hi.
> I receive this duplicate date in tags.
> What can i do?
> Thanks

sorry, but your attachment is in the wrong bug report, and it likely is not a bug  but a settings problem. Please ask in the forum and specify how you tagged your tracks: https://forum.kde.org/viewforum.php?f=115