Tuesday, August 2. 2005
Meta-Information, Track Infomation, Tags
For a while amaroK has used the clumsy language "View/Edit Meta-Information" for the menu items opening the "Meta-Information" dialog (where users can change the tags of track[s].) So I changed it:
For a single track, it says "Edit Track Information".
Markey suggested using "Tags" instead of "Track Information", so it would be "Edit Tags for This Track..." and "Edit Tags for %1 Tracks...". Or something like that.
Is tags more or less clear then track information? Other ideas?
For a single track, it says "Edit Track Information".
Markey suggested using "Tags" instead of "Track Information", so it would be "Edit Tags for This Track..." and "Edit Tags for %1 Tracks...". Or something like that.
Is tags more or less clear then track information? Other ideas?
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
I think "Tags" and "Information" are just as informative as each other. I find "Tags" to be more concise and more accurate than "Information", however.
To me, "track information" would be more clear to a noobie. "Tags" would be more concise for people who know a bit more.
I think the benefits of being clear to a casual user outweigh the benifits of being concise, in this case. Therefore i would with "track information."
I think the benefits of being clear to a casual user outweigh the benifits of being concise, in this case. Therefore i would with "track information."
Saying "Tracks" only makes sense if you're editing the information for a CD. OTHO, "Tags" makes sense regardless if it's a CD, OGG, MP3, etc..
Meh, I disagree. I haven't stopped calling them tracks just because the media changed.
for the uninitiated, 'information' might seem more friendly. but the more serious users know 'tags'.
how about something like 'edit tag info for 16 tracks' or 'edit tag/info for 16 tracks'?
how about something like 'edit tag info for 16 tracks' or 'edit tag/info for 16 tracks'?
Real users don't know what tags are.
People do know that 'track' refers to a song reguardless of the media.
The other major place in KDE where you see/edit the meta-info for an object is Konqueror. There it is referred to as "Properties". In Konq you can look at the properties of a file. So, "Track properties" might be what you are looking for. At least the language use matches 'standard' KDE a bit.
--
Simon
People do know that 'track' refers to a song reguardless of the media.
The other major place in KDE where you see/edit the meta-info for an object is Konqueror. There it is referred to as "Properties". In Konq you can look at the properties of a file. So, "Track properties" might be what you are looking for. At least the language use matches 'standard' KDE a bit.
--
Simon
Unfortunately I have disagree on that: Properties in Konqui are a very tecnical thing. They are something like the modification time of the file, it's size, permissions etc.. This is all information which is outside the file. This is actually tecnical meta information. Of course, the average user doesn't care if the information is from the file or the filesystem, so combining this information is a good idea. But I'm not sure if "Properties" is a good word for that.
With some filetypes (text, PDF) there is another tab in the Properties dialog called *"Meta Info"*. This tab actually contains filetype specific information from inside the file (not the filesystem). For i.e. MP3 files it shows (and lets you edit) the ID3 tag.
So we're back at "Meta Info" - which I don't like either. But if the guys are changing this in amarok - why not make it consistant within KDE. Shouldn't the styleguide take care of such things.
Maybe there's a need for clarification of the words "Property". "Information", "Meta Information". There should be good wording for that kind of stuff - what do the other desktops actually calling it? OS X is sometimes good at such things (sorry, I don't have an OS X here atm).
With some filetypes (text, PDF) there is another tab in the Properties dialog called *"Meta Info"*. This tab actually contains filetype specific information from inside the file (not the filesystem). For i.e. MP3 files it shows (and lets you edit) the ID3 tag.
So we're back at "Meta Info" - which I don't like either. But if the guys are changing this in amarok - why not make it consistant within KDE. Shouldn't the styleguide take care of such things.
Maybe there's a need for clarification of the words "Property". "Information", "Meta Information". There should be good wording for that kind of stuff - what do the other desktops actually calling it? OS X is sometimes good at such things (sorry, I don't have an OS X here atm).
Mac OSX uses the "Get Info" as its equivalent of KDE and Windows' "Edit Properties". With iTunes it took me a few minutes to realise that this is what I'd use the edit tracks. Finder (similar to Konqi) uses the same crap entry.
People who think OSX is awesome generally haven't used it. Yes it is better than Windows, and it is better than KDE in many ways, but KDE is actually awesome, and I much prefer it to the other two.
I use all three desktops every day.
People who think OSX is awesome generally haven't used it. Yes it is better than Windows, and it is better than KDE in many ways, but KDE is actually awesome, and I much prefer it to the other two.
I use all three desktops every day.
"Edit Information for x Tracks*" sounds solid. ("Information" seems more debatable.)
I have done a fair bit of writing for musicology papers, and think "Tracks" is very effective.
Here are some problems with alternatives for "Tracks":
In place of Tracks, use Songs/Works/Pieces: compositions with words are songs, but instrumental compositions (esp. classical) are often works, pieces, or the name of the form/type (e.g. sonata, symphony, or movement).
* Works or Pieces would be a happy middle between tracks and song/symphony. But, the problem is that, sometimes, a collection of tracks make a work/piece, and, in that case, identifying a track as a work becomes improper.
"Tracks" is clear, and is the least specific generally-known label. (But, wouldn't it be great if there was a way to magically determine the genre, form, and type so we could say "Edit information for this symphony," or "Edit information for x songs?" Maybe this could be done with albums when an entire album is selected, e.g. "Edit Information for Album.")
I have done a fair bit of writing for musicology papers, and think "Tracks" is very effective.
Here are some problems with alternatives for "Tracks":
In place of Tracks, use Songs/Works/Pieces: compositions with words are songs, but instrumental compositions (esp. classical) are often works, pieces, or the name of the form/type (e.g. sonata, symphony, or movement).
* Works or Pieces would be a happy middle between tracks and song/symphony. But, the problem is that, sometimes, a collection of tracks make a work/piece, and, in that case, identifying a track as a work becomes improper.
"Tracks" is clear, and is the least specific generally-known label. (But, wouldn't it be great if there was a way to magically determine the genre, form, and type so we could say "Edit information for this symphony," or "Edit information for x songs?" Maybe this could be done with albums when an entire album is selected, e.g. "Edit Information for Album.")
Edit track information.
Edit [common?] information for x tracks.
I would vote for information, as tags implies a technical limit on what type of data can be applied to the tracks. MP3 files do use tags, but others, such as ogg vorbis, just use comments. Those comments can be expanded (and hopefully will be in amarok) to include things like album art, lyrics, and other usefull information. Name/value pairs like artist, album, year can be correctly refered to as tags, but more complex information can't be.
Edit [common?] information for x tracks.
I would vote for information, as tags implies a technical limit on what type of data can be applied to the tracks. MP3 files do use tags, but others, such as ogg vorbis, just use comments. Those comments can be expanded (and hopefully will be in amarok) to include things like album art, lyrics, and other usefull information. Name/value pairs like artist, album, year can be correctly refered to as tags, but more complex information can't be.
you thought that my reinhardt color schema sux? ... ehm, dude LOOK AT YOUR ICONSET, WTF IS THIS??????
/me is dying
/me is dying
+1 for "track information." People still think of them as "tracks," and they don't associate "tags" with artist/title/album/etc information. IMHO.
I love the way you have it now - "Edit track information" and "Edit information for x tracks". I think it's clear, concise, and understandable by all.
You can edit things like score, album cover, etc. So technically tags is not complete. Also "information" is not really that great either as the information in a track would be its wiki entry or the details of its harmony and stuff like that. Technically the stuff the user is editing is meta-information, other properties and associated stuff (album cover). Better would be these I reckon:
Edit Tags and Properties
Edit Properties
Edit Meta-information
I think stating eg. Track Properties, Track Tags, etc. is redundant, it's a context menu already; and the popup has a Title.
Of course we also show track properties (the bitrate, path, etc.). So its not just a place to edit, which is why the "view" term was prepended. And yes I agree it looks silly. I think the viewing aspects can be omitted for the sake of clarity, although I wonder if it would annoy a user looking for a way to see these things. Which is why "properties" may be the best term; as people expect to see all associated meta-data/info/stuff in such a dialog.
Havving said all this, I think we can have faith in our userbase to understand what a tag is. People who cry out that all our users are stupid and don't know what a tag is, don't know our userbase. Trust me people, tags is ok. amaroK is not yet the media player for nooBs, we don't need to worry about nuances of menu item texts.
So yes I think what it has now is good enough. But the term "information" is perhaps not so great. Better than before though, yes.
mx "too much information" cl
Edit Tags and Properties
Edit Properties
Edit Meta-information
I think stating eg. Track Properties, Track Tags, etc. is redundant, it's a context menu already; and the popup has a Title.
Of course we also show track properties (the bitrate, path, etc.). So its not just a place to edit, which is why the "view" term was prepended. And yes I agree it looks silly. I think the viewing aspects can be omitted for the sake of clarity, although I wonder if it would annoy a user looking for a way to see these things. Which is why "properties" may be the best term; as people expect to see all associated meta-data/info/stuff in such a dialog.
Havving said all this, I think we can have faith in our userbase to understand what a tag is. People who cry out that all our users are stupid and don't know what a tag is, don't know our userbase. Trust me people, tags is ok. amaroK is not yet the media player for nooBs, we don't need to worry about nuances of menu item texts.
So yes I think what it has now is good enough. But the term "information" is perhaps not so great. Better than before though, yes.
mx "too much information" cl
Actually I take it back. Now it makes no sense. I look at the menu item and think "What information?"
Markey is right, it should say tags. I prefer all my previous suggestions though.
When you look at a menu item, you need a really good clue as to what clicking it will do. Often this is not the case because we try to cram an overview of a dialog that has 50 widgets into 2 words. But we must do our best. This text is too ambiguous for my tastes.
Markey is right, it should say tags. I prefer all my previous suggestions though.
When you look at a menu item, you need a really good clue as to what clicking it will do. Often this is not the case because we try to cram an overview of a dialog that has 50 widgets into 2 words. But we must do our best. This text is too ambiguous for my tastes.
Here's some suggestions for improving that context menu
Make it have a KPopupTitle of "16 Tracks"
Make it say Queue Tracks not Queue Track
* "Make Playlist" means nothing to me, I know what it does, but wouldn't if I'd never have clicked it. Be more verbose. I don't know what to suggest yet though.
I would implement this stuff but you know I only like to work on areas I'm familiar with...
Make it have a KPopupTitle of "16 Tracks"
Make it say Queue Tracks not Queue Track
* "Make Playlist" means nothing to me, I know what it does, but wouldn't if I'd never have clicked it. Be more verbose. I don't know what to suggest yet though.
I would implement this stuff but you know I only like to work on areas I'm familiar with...
personally, i think that the focus should be more on getting amarok to read meta-information (or tags) from a wider variety of file formats (like aac, etc). that it can play, but won't que into the user's collection since amarok can't read the files' tags. i think adding this level of usability should be the focus of development rather than debating whether to call them "tags" or to call them "meta-information"
Well, the problem is not that we wouldn't love to do this, the problem is that TagLib, the tagging library we use, does not read and write MP4 tags (because there is no formal description of these, Apple has never released anything official on the subject), and WMA (because, well... it's wma and should be shot ).
).
Next time how about talking about the subject rather than pushing your personal agenda and just making the conversation harder to follow? Thanks, bye.
Heh, thanks mxcl. Few things rile me more then folks dictating our priorities.
I find that "Edit Track Information" like you have it is good. Understandable for new users and it doesn't annoy me in the slightest that they are actually "tags" you're editing. Clarity > Specifics.
Information
one simple reason since 1.3 you are no longer editing the tags when you edit meta data
Score isnt part of the id3 tag in any way so
Edit Songs Tag is fairly inappropriate and misleading.
Edit Information on %x Tracks
is ideal
one simple reason since 1.3 you are no longer editing the tags when you edit meta data
Score isnt part of the id3 tag in any way so
Edit Songs Tag is fairly inappropriate and misleading.
Edit Information on %x Tracks
is ideal
Tags, but I have an ulterior motive (read: feature request) for this: I've long wanted to tag all my music-files with searchable del.icio.us-like arbitrary tags, so I could select songs on any criterium I like (assuming of course I had first tagged the songs). I would like those tags to live in the Amarok database (or another place, maybe even a web-service like del.icio.us, as long as tracks are uniquely identified) rather than the file itself. Since audioscrobbler now supports tags, this would open up even more interesting uses of Audioscrobbler's services as well.
Why do I want those tags in the first place, I hear you ask? I really like making mix-cds for friends, but I have a very large (and yes, largely legal ) collection of oggs and mp3s, that I listen to on random most of the time. Sometimes I come across a half forgotten song that would be great for a future (often highly abstractly) themed compilation cd. (say: music to drive by) I would then very much like to be able to mark the track (with say: 'driving') so that I can find back all songs which struck me as appropriate at one time when I actually get around to making the compilation.
sry for the rant, but if this gets into Amarok, it will be even greater than it already is.
Why do I want those tags in the first place, I hear you ask? I really like making mix-cds for friends, but I have a very large (and yes, largely legal
) collection of oggs and mp3s, that I listen to on random most of the time. Sometimes I come across a half forgotten song that would be great for a future (often highly abstractly) themed compilation cd. (say: music to drive by) I would then very much like to be able to mark the track (with say: 'driving') so that I can find back all songs which struck me as appropriate at one time when I actually get around to making the compilation.sry for the rant, but if this gets into Amarok, it will be even greater than it already is.
Editing Tag to me, means that you are modifying the actual mp3 file.
Adding track information, in Amarok, makes me think that I'm adding the information to Amaroks database.
shrug I have no idea what the truth is at this point.
lowlevel
Adding track information, in Amarok, makes me think that I'm adding the information to Amaroks database.
shrug I have no idea what the truth is at this point.
lowlevel
Amarok Links
Calendar
|
September '08 |
|
||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||
Quicksearch
Archives
Categories
Syndicate This Blog
Blog Administration
We Listen To...
Powered by
