Wednesday, August 8. 2007
to all the self-described critics
so my last entry got quite a number of comments, mostly negative, some based on incorrect assumptions or understandings, etc. I want to take the time to explain the design decisions and lay down the facts.
first of all, the major complaint seems to be that the contextview takes up too much room, and makes the playlist too small. the size of the contextview/playlist is configurable. yes, you can drag the barrier to decide how large you want it. guess what, you can even make it take up the complete contextview space, hiding the plasma panel! there will be no barrier to you using the whole window for playlist management if you wish. of course, then you will miss out on any info displayed in the contextview, but that is your choice.
the next big complaint that i have seen is that the playlist items are too "big", not allowing for a lot of items on the screen at once, making it hard to manage them. as we are using the Qt model/view architecture for out playlist items, it will not be too hard to implement an amarok-1.x style playlist as an option for simply managing your music. that is under discussion, and might be the final solution. either way, we envision a way to use amarok that will make it easier to manage music than the narrow playlist.
for those who, understandable, point out that the large contextview makes dragging from the collectionbrowser to the playlist very very hard, we understand you. we are not going to force users to drag anything all across the contextview. our plan is currently to implement a sort of popup drop-box over the contextview when a drag is initiated, with icons or some sort of visual indication for where to drop the selected tracks in order to achieve certain actions. that way the user will not have to drag-n-drop any tracks more than is reasonable.
for those who say they just want amarok to play a large (1000+ tracks) playlist of music, and that they don't care about all the bells-n-whistles like context info, etc, well, i don't know what to say except you might be better off with xmms. if all you want is to hear your music, amarok is probably not the player for you---and has never been. we want to bring the user more context information, in a prettier way, while not hampering his ability to play/manage music. not the other way around.
a few are worried about the potentially wasted space in the contextview as applets can be positioned, and sized, differently. well, applets are not going to be user-placeable except for in a very limited manner. this is where we differ from plasma---the user will not resize applets to her liking, putting them where she wants. instead, amarok will take care of the layout management of the contextview, ensuring that the full width of the view is used, resizing and placing applets where needed to maximise the screen real estate. we will not waste any screen real estate
to conclude, please keep in mind that this is a very early screenshot. the work on the contextview is nowhere near finished, polished, or perfected. the playlist is still in the middle of being redone, and improves every week. we do have usability people who are working with us, and we are not just trying to innovate for the sake of innovation. we are all amarok users before amarok developers, and we want the best possible music player as well.
first of all, the major complaint seems to be that the contextview takes up too much room, and makes the playlist too small. the size of the contextview/playlist is configurable. yes, you can drag the barrier to decide how large you want it. guess what, you can even make it take up the complete contextview space, hiding the plasma panel! there will be no barrier to you using the whole window for playlist management if you wish. of course, then you will miss out on any info displayed in the contextview, but that is your choice.
the next big complaint that i have seen is that the playlist items are too "big", not allowing for a lot of items on the screen at once, making it hard to manage them. as we are using the Qt model/view architecture for out playlist items, it will not be too hard to implement an amarok-1.x style playlist as an option for simply managing your music. that is under discussion, and might be the final solution. either way, we envision a way to use amarok that will make it easier to manage music than the narrow playlist.
for those who, understandable, point out that the large contextview makes dragging from the collectionbrowser to the playlist very very hard, we understand you. we are not going to force users to drag anything all across the contextview. our plan is currently to implement a sort of popup drop-box over the contextview when a drag is initiated, with icons or some sort of visual indication for where to drop the selected tracks in order to achieve certain actions. that way the user will not have to drag-n-drop any tracks more than is reasonable.
for those who say they just want amarok to play a large (1000+ tracks) playlist of music, and that they don't care about all the bells-n-whistles like context info, etc, well, i don't know what to say except you might be better off with xmms. if all you want is to hear your music, amarok is probably not the player for you---and has never been. we want to bring the user more context information, in a prettier way, while not hampering his ability to play/manage music. not the other way around.
a few are worried about the potentially wasted space in the contextview as applets can be positioned, and sized, differently. well, applets are not going to be user-placeable except for in a very limited manner. this is where we differ from plasma---the user will not resize applets to her liking, putting them where she wants. instead, amarok will take care of the layout management of the contextview, ensuring that the full width of the view is used, resizing and placing applets where needed to maximise the screen real estate. we will not waste any screen real estate
to conclude, please keep in mind that this is a very early screenshot. the work on the contextview is nowhere near finished, polished, or perfected. the playlist is still in the middle of being redone, and improves every week. we do have usability people who are working with us, and we are not just trying to innovate for the sake of innovation. we are all amarok users before amarok developers, and we want the best possible music player as well.
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Suggesting people use XMMS is stupid. Is that an official developer response? If so it is idiotic.
I know a number of people who are considering forking Amarok because they are so displeased with some of the new interface changes.
Amarok IS the best player for 1000+ playlists and has been the whole 3 years I've been running Linux on my desktop. I can name at least 3 other people I know in real life that use Amarok in the same way.
If you want to just say we should go use another program then fine, someone will fork Amarok and make it better.
You are talking about trying to make a music player really pretty etc. It plays music. I'm willing to bet for most people 99% of the time they are using Amarok (i.e. to play music) it is minimised and they can't see all the bling you are adding.
Development should be at least partly responsive to user opinions as there are lots of different use cases for this application. Simply developing for how you'd like it ignores this simple fact.
That said I haven't written Amarok 2.0 off yet. I'll wait and see. May I suggest instead of saying people are wrong and should use another music player that you perhaps post screenshots doing what they seem to want and see if that makes them happy instead of being confrontational and alienating some of your userbase.
I know a number of people who are considering forking Amarok because they are so displeased with some of the new interface changes.
Amarok IS the best player for 1000+ playlists and has been the whole 3 years I've been running Linux on my desktop. I can name at least 3 other people I know in real life that use Amarok in the same way.
If you want to just say we should go use another program then fine, someone will fork Amarok and make it better.
You are talking about trying to make a music player really pretty etc. It plays music. I'm willing to bet for most people 99% of the time they are using Amarok (i.e. to play music) it is minimised and they can't see all the bling you are adding.
Development should be at least partly responsive to user opinions as there are lots of different use cases for this application. Simply developing for how you'd like it ignores this simple fact.
That said I haven't written Amarok 2.0 off yet. I'll wait and see. May I suggest instead of saying people are wrong and should use another music player that you perhaps post screenshots doing what they seem to want and see if that makes them happy instead of being confrontational and alienating some of your userbase.
For heaven's sake, can't you just wait until KDE 4/Amarok 2 are out before you start talking about forking anything? I have been talking to the Amarok developers and seen how they work, and I am conviced they can and will create something amazing. And configurable for those who want it the old way.
And no matter how configurable it is, I'm sure people will soon figure out the changes are actually improvements and they will use the new Amarok.
And no matter how configurable it is, I'm sure people will soon figure out the changes are actually improvements and they will use the new Amarok.
"Suggesting people use XMMS is stupid. Is that an official developer response? If so it is idiotic."
Why, if XMMS truly is a better fit for the usecase some people are describing?
"Development should be at least partly responsive to user opinions as there are lots of different use cases for this application. Simply developing for how you'd like it ignores this simple fact."
True, but you also have to have a consistent vision within the development team. By definition you cannot make everybody happy, and if you try, then you will end up with a bloated piece of crapware that does a lot of things, but none of them really well.
For Amarok2, the development team has decided to try something completely new and push the envelope a little. Will this alienate some users? Of course it will, as does every major change to every software application, but hopefully it will also attract new ones. It is a risk, but it is what is keeping the development team motivated and moving ahead at an incredible pace.
Also, nothing is keeping users from using the 1.4.x branch, even under KDE4, and this branch will likely receive fixes and updates for some time to come.
Why, if XMMS truly is a better fit for the usecase some people are describing?
"Development should be at least partly responsive to user opinions as there are lots of different use cases for this application. Simply developing for how you'd like it ignores this simple fact."
True, but you also have to have a consistent vision within the development team. By definition you cannot make everybody happy, and if you try, then you will end up with a bloated piece of crapware that does a lot of things, but none of them really well.
For Amarok2, the development team has decided to try something completely new and push the envelope a little. Will this alienate some users? Of course it will, as does every major change to every software application, but hopefully it will also attract new ones. It is a risk, but it is what is keeping the development team motivated and moving ahead at an incredible pace.
Also, nothing is keeping users from using the 1.4.x branch, even under KDE4, and this branch will likely receive fixes and updates for some time to come.
Well, being pedantic, XMMS is unmaintained.
I just think if Amarok worked well for people in 1.4 then alienating a bunch of people and saying that they should just use another player is a bit shortsighted.
You don't choose your users, they choose you and therefore it is unwise to assume alienating some is ok because you'll just attract a bunch of different ones.
The 1.4 branch hasn't been ported to Qt4 and won't be able to make use of KDE4's ioslaves and will be lacking in other integration areas, unless I'm mistaken.
I just think if Amarok worked well for people in 1.4 then alienating a bunch of people and saying that they should just use another player is a bit shortsighted.
You don't choose your users, they choose you and therefore it is unwise to assume alienating some is ok because you'll just attract a bunch of different ones.
The 1.4 branch hasn't been ported to Qt4 and won't be able to make use of KDE4's ioslaves and will be lacking in other integration areas, unless I'm mistaken.
The cool thing about FOSS is, that in most cases developers are only users too who just try to improve the product they use. Also everybody is free to join a project (coding is only a small part of the whole work btw), participate and build up some more in-deep knowledge that goes beyond some short looks at screenshots. You can be pretty sure that such kind of design-decisions arn't made within an evening and you can be pretty sure that n of the developers may have n*2+m different opinions on that subject and they all where discused in the one or another way. To provide here a probably better sample;
Let's assume you like to build a house, collected the money for it last 20 years and spend a damn long time to plan every detail. Now it's the case you don't build that house alone and therefore you had to spend even more time with your "partners" to find the solution. But what happens the first time you show some pictures of the just started process of building that house? Your neighbors are coming around, take a look at the thing just started 2 days before and start to complaining that the house has no roof yet. Wouldn't you ask them to either look at the other houses you build before (and they all had roofs) or just wait till it's finished or at least take a look at the plan and talk with you and your mates before?
So, lot of text with a short message; participate or wait, just complaining doesn't change anything
Let's assume you like to build a house, collected the money for it last 20 years and spend a damn long time to plan every detail. Now it's the case you don't build that house alone and therefore you had to spend even more time with your "partners" to find the solution. But what happens the first time you show some pictures of the just started process of building that house? Your neighbors are coming around, take a look at the thing just started 2 days before and start to complaining that the house has no roof yet. Wouldn't you ask them to either look at the other houses you build before (and they all had roofs) or just wait till it's finished or at least take a look at the plan and talk with you and your mates before?
So, lot of text with a short message; participate or wait, just complaining doesn't change anything
And in the end no one is forced to upgrade to Amarok2. People who do not need new features, new eye-candy rather stay with Amarok 1.4 which is already nice and stable.
We've always told people to use another player when they come in and start making demands that don't make too much sense to us. Like some folks want a jukebox-style player, why not use Juk? etc.
This is only going to be even more of the case when we move to Windows. Being a Winamp or iTunes lookalike or workalike is not only pointless, its damaging. Its going to be increasingly important that Amarok creates its own identity.
This is only going to be even more of the case when we move to Windows. Being a Winamp or iTunes lookalike or workalike is not only pointless, its damaging. Its going to be increasingly important that Amarok creates its own identity.
""Suggesting people use XMMS is stupid. Is that an official developer response? If so it is idiotic.""
"Why, if XMMS truly is a better fit for the usecase some people are describing?"
Actually yes, but for another reason. For the use case of huge playlist JuK is a better fit, and it's a KDE application. It's even located in kde-multimedia, one of the main KDE modules.
So that should be the official developer response. Rather than suggesting a unmaintained 3rd party applications, they should point to the correct KDE tool for the job.
"Why, if XMMS truly is a better fit for the usecase some people are describing?"
Actually yes, but for another reason. For the use case of huge playlist JuK is a better fit, and it's a KDE application. It's even located in kde-multimedia, one of the main KDE modules.
So that should be the official developer response. Rather than suggesting a unmaintained 3rd party applications, they should point to the correct KDE tool for the job.
Fair enough, I have not used xmms for ages so I actually don't know jack about it. The point I was trying to make was not really about xmms, but rather against the notion that recommending another piece of software fort he job is not a valid response if peoples usecases and expectations are completely out of sync with the focus of Amarok. One tool does not work for every job.
Almost all those problems could be solved with tabs...
http://amarok.kde.org/forum/index.php/topic,14319.0.html
http://amarok.kde.org/forum/index.php/topic,14319.0.html
Tabs in a music player makes no sense and won't help anything. It will just make everything super cluttered for nothing.
Honestly, it would be the only thing that would make the current look be any worse. Yes, I know it's early but I'm not going to wait until 4.0 to complain.
If all of KDE is going to get this "We wanna be Apple" look and flash... I think I'll be staying with KDE 3 + Amarok 1.4.6.
Honestly, it would be the only thing that would make the current look be any worse. Yes, I know it's early but I'm not going to wait until 4.0 to complain.
If all of KDE is going to get this "We wanna be Apple" look and flash... I think I'll be staying with KDE 3 + Amarok 1.4.6.
Is that why Foobar has quickly become the most popular player on windows? Ask Foobar users, they love tabs and would wholeheartedly disagree with your opinion!
(shit, sorry for the double-post)
(shit, sorry for the double-post)
Honestly, foobar is not the most popular player on Windows. iTunes is, followed by Winamp, then Windows media player, then foobar.
Using Last.fm data.
Using Last.fm data.
I doubt winamp is second out of all users. Last.fm users probably don't represent the average in that respect. I reckon it is probably: Windows media player, iTunes, winamp, then I have no idea.
Yeah, I'd agree, but I work there and saw the data, so I can't refute it.
We reckon the reason is because our users would rather use decent players to the stock option.
We reckon the reason is because our users would rather use decent players to the stock option.
Oh I see. Yes indeed, Last.fm data doesn't necessarily correlate with the entire music-player userbase and agree with your assessment.
Absolutely. While I don't have access to this data, I would imagine that foobar is far, far behind the top three players on windows. I would be seriously surprised if it had more than about 5% share.
I don't know anyone that uses Foobar, and it's not for lack of knowing about it. I, as well as some of my more technically inclined friends have tried it, but it's so needlessly complicated that we didn't find it worth using. Just look at the top features advertised on the foobar homepage.
Unicode support, transcoding files, replaygain support, customizable keyboard shortcuts?? Unless you're a geek, none of these features are going to be even remotely useful or interesting to you. Actually, even as a geek I couldn't care less about those features.
I don't know anyone that uses Foobar, and it's not for lack of knowing about it. I, as well as some of my more technically inclined friends have tried it, but it's so needlessly complicated that we didn't find it worth using. Just look at the top features advertised on the foobar homepage.
Unicode support, transcoding files, replaygain support, customizable keyboard shortcuts?? Unless you're a geek, none of these features are going to be even remotely useful or interesting to you. Actually, even as a geek I couldn't care less about those features.
That's the issue here; Just YOU could care less about those features.
Remember what Aaron once quoted, we all use 20% of the features in most programs, yet everyone uses a different 20%.
There is no reason why Amarok cannot have every single FEATURE that Foobar has without adding clutter. Foobar is very simple and not 'complicated' as you say with it's default installation... yet you can do much more with it if you want to due to its plugin system.
Remember what Aaron once quoted, we all use 20% of the features in most programs, yet everyone uses a different 20%.
There is no reason why Amarok cannot have every single FEATURE that Foobar has without adding clutter. Foobar is very simple and not 'complicated' as you say with it's default installation... yet you can do much more with it if you want to due to its plugin system.
Sure, not every user uses the same 20%. And foobar being scriptable is great. But Amarok is scriptable as well, so it has as potentially all the features foobar has.
Anyway, out of the box, Amarok is a far superior player, and I hope it'll do a nice job on the windows platform.
Anyway, out of the box, Amarok is a far superior player, and I hope it'll do a nice job on the windows platform.
Foobar is for geeks only... a program... well, a music player that needs a plugin even to show it's main UI is for geeks only. And moreover, not for every geek. I, for one, am another geek who tried foobar in its earliest days and ran away from it as quick as possible
How resizeable is amarok 2 going to be?
I've been using VirtualBox to check out the KDE4-Live CDs, unsing a resolution of 1280x1024, and Amarok is too wide. When I try to resize it, it can't get any smaller. The minimum sizes for the panes were also larger than I'd like.
For some reason, it was also very CPU hungry, probably because of the 3D effects.
I hope you developers don't forget the users with lower resolutions (and those who don't like maximized windows).
I've been using VirtualBox to check out the KDE4-Live CDs, unsing a resolution of 1280x1024, and Amarok is too wide. When I try to resize it, it can't get any smaller. The minimum sizes for the panes were also larger than I'd like.
For some reason, it was also very CPU hungry, probably because of the 3D effects.
I hope you developers don't forget the users with lower resolutions (and those who don't like maximized windows).
I was hoping there would be a way of disabling the context view but I guess hiding it will have to do. Also if I could reduce the tabs to the useful ones (e.g. Devices, Playlist and collection) you will be on to a winner. I don't want to offend but at that risk Amarok has been getting more and more cluttered for some time and bloat isn't a needed feature. You suggest Xmms as a good replacement but unfortunately that is at the wrong end of the feature spectrum, I think the perfect player for most is Juk (whoever suggested creating a fork - I think Juk would be a good place to start with a sprinkling of Amarok / although there are clunky GTK alternatives) but unfortunately the Kubuntu packages are quite broken. Anyhow I shouldn't criticize when I could do no better and I should wait for the finished article before considering a switch.
Grouped Information in the Playlist
The context-browser can be a good idea. We will see.
And the playlist does not necessarily need all the full-width of our wide-screens.
But the missing ressource on "modern" screens is horizontal space, to have a big overview of the playlist. Human brains are good at understanding the big picture.
The problem I have with the new playlist is that each entry is too tall.
And more importantly: most entries share common information. If we play entire artists or albums (which I think is quite common), Artist, Album, Year, Cover Art are common to nearly 10 songs. They are repeated information. BTW, the cover art must be small to keep the playlist items smalls, so it reduce the usefulness of the cover arts in the playlist.
My proposition: gather common information. The album art, artist, album name, year... must span all the rows that have common information ("rowspan" for people knowing HTML tables). And all items are heigh of one line.
Here are screenshots of how it's made in Windows Media Player 11:
http://img218.imageshack.us/img218/2126/wmp112qz.jpg
http://www.blogeek.ch/images/news/wmp11.JPG
http://static.flickr.com/105/286158112_596334fc8d.jpg
This is also done by iTunes 7:
http://www.majid.info/mylos/weblog/2006/09/itunes_album.gif
Puting the artist/album names below the cover is more clever than Windows Media Player, to save horizontal space, but most columns shown in that screenshot are useless/repeatitives, at least for Amarok needs.
The context-browser can be a good idea. We will see.
And the playlist does not necessarily need all the full-width of our wide-screens.
But the missing ressource on "modern" screens is horizontal space, to have a big overview of the playlist. Human brains are good at understanding the big picture.
The problem I have with the new playlist is that each entry is too tall.
And more importantly: most entries share common information. If we play entire artists or albums (which I think is quite common), Artist, Album, Year, Cover Art are common to nearly 10 songs. They are repeated information. BTW, the cover art must be small to keep the playlist items smalls, so it reduce the usefulness of the cover arts in the playlist.
My proposition: gather common information. The album art, artist, album name, year... must span all the rows that have common information ("rowspan" for people knowing HTML tables). And all items are heigh of one line.
Here are screenshots of how it's made in Windows Media Player 11:
http://img218.imageshack.us/img218/2126/wmp112qz.jpg
http://www.blogeek.ch/images/news/wmp11.JPG
http://static.flickr.com/105/286158112_596334fc8d.jpg
This is also done by iTunes 7:
http://www.majid.info/mylos/weblog/2006/09/itunes_album.gif
Puting the artist/album names below the cover is more clever than Windows Media Player, to save horizontal space, but most columns shown in that screenshot are useless/repeatitives, at least for Amarok needs.
I made a proposal along these lines many months ago (with screenshot) at the amarok wiki. Nobody seemed to notice:
http://amarok.kde.org/wiki/Alternative_Playlist_View
http://amarok.kde.org/wiki/Alternative_Playlist_View
Didn't see your post until now and I made a mockup of something similar as well (which I posted about further down here as well).
Unfortunately, that mockup seems to have been removed from kde-look for some weird reason.
Small picture on the link though, http://img379.imageshack.us/img379/4/smallti3.jpg
Unfortunately, that mockup seems to have been removed from kde-look for some weird reason.
Small picture on the link though, http://img379.imageshack.us/img379/4/smallti3.jpg
And what happened with inline edit of id3tags and co? I use a lot this feature as I am still arranged my song collection and don't see how can we use it with the new layout.
But I only can thanks you for all your great work.
But I only can thanks you for all your great work.
That is still entirely as possible, just because tab will now work in a table rather than in a single row does not mean that it won't work as well as it did before wrt metadata editing
I understand people are very anxious about what direction their favourite audio player/manager is going. I have a few minor solutions than can maybe save a lot of concerns:
1. Make it possible to switch the context view and the playlist. Why?: If you want to drag items from your collection to your playlist you can drop it in the context view if I'm understand correctly? For a bunch of people that is not visually clear. So maybe it's better to have an option to have the playlist in the middle or even better; let it be the default.
2. Give the user the option to disable the context view or even the playlist (some people maybe want it the way around).
Hopefully these ideas can be easy implemented.
Cheers,
Jeroen
1. Make it possible to switch the context view and the playlist. Why?: If you want to drag items from your collection to your playlist you can drop it in the context view if I'm understand correctly? For a bunch of people that is not visually clear. So maybe it's better to have an option to have the playlist in the middle or even better; let it be the default.
2. Give the user the option to disable the context view or even the playlist (some people maybe want it the way around).
Hopefully these ideas can be easy implemented.
Cheers,
Jeroen
regarding your #1, when a user starts a drag there will be stuff drawn on top of the current contextview, so it will be very obvious what one is supposed to do.
regarding #2, i already addressed the first part---just hide the CV. and for the second part, it is already possible to hide the playlist (CV just gets wider).
regarding #2, i already addressed the first part---just hide the CV. and for the second part, it is already possible to hide the playlist (CV just gets wider).
>regarding your #1, when a user starts a drag there will be stuff drawn on top of the current contextview, so it will be very obvious what one is supposed to do.
I guess that just to drag items into playlist is much simple, understandable and reasonable for everyone. So why do you need to have something to be drown on top of context view. This something them will need to interact with playlist adding new items to the list. Is this complexity (even of implementation) just to have context view in the middle? Maybe I don't understand this but I see no other explanation. What is wrong with context view from the right side of the window but not in the center?
I quite agree with people who say that most of time you will not stare on your player. It will be minimized into system tray (please don't say that in this case people use Amarok incorrectly and they should use something different). They will open Amarok window to manage their playlists. And they want to be able to do this in an easy, convenient and understandable way.
You wrote that
--
it will not be too hard to implement an amarok-1.x style playlist as an option for simply managing your music. that is under discussion, and might be the final solution.
--
ok that's good. But how this can bee seen from the screenshot. I mean people don't know that there might be (or might not) such an option. That is why they write so much about old format. Besides you wrote that Amarok 2.x will be something that "look no further" from your screenshot. This is why you have all the fuss about. Nevertheless it is an "very early" screenshot you definitely wrote that the concept or vision is represented by your screenshot.
To those who say that people just afraid innovations and that Amarok team already created a good player so Amarok 2.x will be great because it just will. And all we need is just to wait. Just think why iTunes in the most popular player in the world (I bet you won't object this statement). Maybe because it is really good. Don't you think so? And what is the central point in iTunes? Yes this is playlist. The playlist which is very similar to the playlist of Amarok 1.4.x
I guess that just to drag items into playlist is much simple, understandable and reasonable for everyone. So why do you need to have something to be drown on top of context view. This something them will need to interact with playlist adding new items to the list. Is this complexity (even of implementation) just to have context view in the middle? Maybe I don't understand this but I see no other explanation. What is wrong with context view from the right side of the window but not in the center?
I quite agree with people who say that most of time you will not stare on your player. It will be minimized into system tray (please don't say that in this case people use Amarok incorrectly and they should use something different). They will open Amarok window to manage their playlists. And they want to be able to do this in an easy, convenient and understandable way.
You wrote that
--
it will not be too hard to implement an amarok-1.x style playlist as an option for simply managing your music. that is under discussion, and might be the final solution.
--
ok that's good. But how this can bee seen from the screenshot. I mean people don't know that there might be (or might not) such an option. That is why they write so much about old format. Besides you wrote that Amarok 2.x will be something that "look no further" from your screenshot. This is why you have all the fuss about. Nevertheless it is an "very early" screenshot you definitely wrote that the concept or vision is represented by your screenshot.
To those who say that people just afraid innovations and that Amarok team already created a good player so Amarok 2.x will be great because it just will. And all we need is just to wait. Just think why iTunes in the most popular player in the world (I bet you won't object this statement). Maybe because it is really good. Don't you think so? And what is the central point in iTunes? Yes this is playlist. The playlist which is very similar to the playlist of Amarok 1.4.x
Sorry Leo,
I must object here again, it might be "*very* clear" when something probably animated pops up with options like "Drop here to append after current track" or "Drop here to append to playlist" but that does not make it necessarily usable or appealing.
It is not the same as having the regular drag & drop action where you may even put the song 10 items before the track currently playing.
And still there is no reasonable explanation why the context view on the right would be inferior.
I only can assume that the developers are nowadays only listen to last.fm and streams and have no strong urge to use the playlist at all - hence they seem to ignore a use case that is very regular as you can conclude from the huge amount of posts....
Amarok 1.x is playlist centric (it may not handle very huge playlists efficiently) and IMHO in a much better way than iTunes.
So, please try to listen to the objections of your users and try to contact the community usability projects, I bet they will tell you similar things as I did.
Ignoring simple "facts" is a huge mistake!
Please - reconsider this! Or give at least a reasonable explanation (USABILITY WISE!) that the playlist and the collection even if (semantically) coupled are in such a spatial distance!
And also keep my other advise in mind: Appealing screenshots are indeed important for the reputation of a project - even if it's in an early development state.
For example: Simply removing this gradient on the top would highly improve the look.
Remember: KDE4 beta1 is out - Magazines are writing about it and making screenshots. Besides the community not happy with it (even if they "should" understand the difference between the MVC parts) new users will might be disgusted by the current state.... (again not knowig what is going on)... but this point is not as important as the design descisions currently on stage.
So either you make Amarok 2 for Amarok developers only or you make Amarok 2 as brilliant and attractive to end-users as Amarok 1 was.
Both is up to you - but please make clear what you want!
I must object here again, it might be "*very* clear" when something probably animated pops up with options like "Drop here to append after current track" or "Drop here to append to playlist" but that does not make it necessarily usable or appealing.
It is not the same as having the regular drag & drop action where you may even put the song 10 items before the track currently playing.
And still there is no reasonable explanation why the context view on the right would be inferior.
I only can assume that the developers are nowadays only listen to last.fm and streams and have no strong urge to use the playlist at all - hence they seem to ignore a use case that is very regular as you can conclude from the huge amount of posts....
Amarok 1.x is playlist centric (it may not handle very huge playlists efficiently) and IMHO in a much better way than iTunes.
So, please try to listen to the objections of your users and try to contact the community usability projects, I bet they will tell you similar things as I did.
Ignoring simple "facts" is a huge mistake!
Please - reconsider this! Or give at least a reasonable explanation (USABILITY WISE!) that the playlist and the collection even if (semantically) coupled are in such a spatial distance!
And also keep my other advise in mind: Appealing screenshots are indeed important for the reputation of a project - even if it's in an early development state.
For example: Simply removing this gradient on the top would highly improve the look.
Remember: KDE4 beta1 is out - Magazines are writing about it and making screenshots. Besides the community not happy with it (even if they "should" understand the difference between the MVC parts) new users will might be disgusted by the current state.... (again not knowig what is going on)... but this point is not as important as the design descisions currently on stage.
So either you make Amarok 2 for Amarok developers only or you make Amarok 2 as brilliant and attractive to end-users as Amarok 1 was.
Both is up to you - but please make clear what you want!
you must also understand that i posted this screenshot to try to "open" development a little---the whole point is we don't want to spring amarok 2.0 into the wild from a black box.
FWIW i heavily use playlists and local files, so that use case is definitely being taken care of. and note that the current state of amarok 2.0 does not allow for much functionality---we are very early in the final process and still ironing out ideas as we go. so what you see is not the final version, and in fact is nowhere near the final version. much work has yet to be done.
and we do have some usability people that we are working with. do not assume that just because you think that the screenshot that you see doesn't agree with your concept of what you want amarok to be we ignore all expert opinions and code something for ourselves only. all the design decisions made to date have been made as a team collaborating with artists, coders, and usability people.
FWIW i heavily use playlists and local files, so that use case is definitely being taken care of. and note that the current state of amarok 2.0 does not allow for much functionality---we are very early in the final process and still ironing out ideas as we go. so what you see is not the final version, and in fact is nowhere near the final version. much work has yet to be done.
and we do have some usability people that we are working with. do not assume that just because you think that the screenshot that you see doesn't agree with your concept of what you want amarok to be we ignore all expert opinions and code something for ourselves only. all the design decisions made to date have been made as a team collaborating with artists, coders, and usability people.
I appreciate that you publish the screenshots. I also keep track of the SVN version from time to time.
Anyway, you also write that the current concept seems to be the way to go without ever giving a reason - yet again you go into self-defense instead of just arguing why the break with obvious patterns is so attractive that by all means you try to leave it this way. ("you" is plural here...)
It is clear that this is not the final version - hence it makes even more sense to try to convince you that (not only) in my opinion the current concept does not seem to be satisfactory. Thus you could just try to see this as constructive criticism as I always try to offer an alternative and bring up at least arguments.
Even removing the gradient on top was just an simple proposal to improve the attraction.
So again - I may ask - when this "design decision" was made, what where the persuasive arguments of your usability people to do it this way (please note that the current general layout has not been touched for month).
I appreciate your work - and as I said Amarok 1.x was a huge success. And that is the reason why people like me and many other posting here and other places try to improve the next generation of Amarok by some sort of "external view" giving some remarks of what might be done better.
You see - this is instant "feedback" and just seeing it this way will bring Amarok 2 hopefully the same success as the 1.x versions did.
Anyway, you also write that the current concept seems to be the way to go without ever giving a reason - yet again you go into self-defense instead of just arguing why the break with obvious patterns is so attractive that by all means you try to leave it this way. ("you" is plural here...)
It is clear that this is not the final version - hence it makes even more sense to try to convince you that (not only) in my opinion the current concept does not seem to be satisfactory. Thus you could just try to see this as constructive criticism as I always try to offer an alternative and bring up at least arguments.
Even removing the gradient on top was just an simple proposal to improve the attraction.
So again - I may ask - when this "design decision" was made, what where the persuasive arguments of your usability people to do it this way (please note that the current general layout has not been touched for month).
I appreciate your work - and as I said Amarok 1.x was a huge success. And that is the reason why people like me and many other posting here and other places try to improve the next generation of Amarok by some sort of "external view" giving some remarks of what might be done better.
You see - this is instant "feedback" and just seeing it this way will bring Amarok 2 hopefully the same success as the 1.x versions did.
Just wanted to add.
I guess everybody understand that this is early work and a lot to be done. And that the final version can be different. But we don't talk here about complete list of features or the minor problems with layout of components which definitely will be fixed when there will be 2.0 final. We are talking about general concepts. Plylist oriented player or applet viewer oriented player (which gives more "context"). We are talking about the preferred use cases and what people (I mean users) actually want to have.
This is software of early stage. Yes, but someone already made a decision to change the layout in the way we can see it on your screenshot. And I doubt that it will be easily changed. Or am I wrong? And if you already have a decision to change design of the application in some way it is the right time to express you critique. Because it is in early stage. It will be to late to critique when we will have 2.0 final. I can bet that after final release there will be no major ui changes.
I can't understand why in most of your responses all you answer to the critiques is that it is in early stage and you do have usability people working on it. Does this mean that design will be definitely changed in the way users want? No, I don't think so. So if you really had usability experts working on this design why don't you post what was the motivation of changing design into the way it looks now. What benefits except of having some applet viewer in the middle of the music player (I don't think this is reasonable explanation for users) users will get.
Please understand that words that this was a team decision, we do have usability people and it is in early stage doesn't really explain anything. For the users it is the same as "we just changed it". Please give reasonable explanation (if you have it).
I guess everybody understand that this is early work and a lot to be done. And that the final version can be different. But we don't talk here about complete list of features or the minor problems with layout of components which definitely will be fixed when there will be 2.0 final. We are talking about general concepts. Plylist oriented player or applet viewer oriented player (which gives more "context"). We are talking about the preferred use cases and what people (I mean users) actually want to have.
This is software of early stage. Yes, but someone already made a decision to change the layout in the way we can see it on your screenshot. And I doubt that it will be easily changed. Or am I wrong? And if you already have a decision to change design of the application in some way it is the right time to express you critique. Because it is in early stage. It will be to late to critique when we will have 2.0 final. I can bet that after final release there will be no major ui changes.
I can't understand why in most of your responses all you answer to the critiques is that it is in early stage and you do have usability people working on it. Does this mean that design will be definitely changed in the way users want? No, I don't think so. So if you really had usability experts working on this design why don't you post what was the motivation of changing design into the way it looks now. What benefits except of having some applet viewer in the middle of the music player (I don't think this is reasonable explanation for users) users will get.
Please understand that words that this was a team decision, we do have usability people and it is in early stage doesn't really explain anything. For the users it is the same as "we just changed it". Please give reasonable explanation (if you have it).
http://en.wikipedia.org/wiki/KISS_principle
Hi Guys,
I have absolute faith in the Amarok design team. Why? Simple: The gave us the kick-ass player we all use and love.
To some of the more vocal critics: Instead of bitching about some feature that is important to *you*. Have you tried considering the fact that the developers may have thought this one through?
Peace...
And to the Amarok team: Ignore the trolls and forge ahead! Fast Forward
I have absolute faith in the Amarok design team. Why? Simple: The gave us the kick-ass player we all use and love.
To some of the more vocal critics: Instead of bitching about some feature that is important to *you*. Have you tried considering the fact that the developers may have thought this one through?
Peace...
And to the Amarok team: Ignore the trolls and forge ahead! Fast Forward
Don't worry about the noise much. Every time someone changes anything, there is friction. You may loose some people, but you gain a whole bunch of other users, equally prickly, and demanding but totally in love with Amarok.
I for one absolutely hate the mess you guys called a user interface in the previous versions and camped out at Kaffeine, Juke area. Now, I sitting on the edge of the seat waiting for the "un-geekified" Amarok.
With a project like this, you will always have fans.
I for one absolutely hate the mess you guys called a user interface in the previous versions and camped out at Kaffeine, Juke area. Now, I sitting on the edge of the seat waiting for the "un-geekified" Amarok.
With a project like this, you will always have fans.
Please wait the first released version before talking about forking etc.
I think sometime that forking is a weak of time just for few disagreement.
After, if you don't like it, you can use another software or you can fork it, but yet it's too early...
I think sometime that forking is a weak of time just for few disagreement.
After, if you don't like it, you can use another software or you can fork it, but yet it's too early...
I hope this isn't lost among all the rage, but while I certainly don't think that Amarok 2 is turning into the WORST PLAYER EVAR, I do feel there are some practical concerns with the current design.
First and foremost, the prominent contextbrowser makes things easy for people who like it open all the time, or none of the time, but not those who only like it open some of the time. I don't want to advocate pref-bloat, but I think a toggle between a context-oriented view and a playlist-oriented view would be a very good idea.
- A single-line playlist view like in 1.x is, IMHO, much better suited for managing music, since it displays the most information at once.
- The context-oriented view seems better for playing music, a la WMP's "Now Playing" view, only better.
I, for one, would probably use both of these views at different times, so an easily-accessible toggle would be best for me. Besides, there's plenty of room on that toolbar.
Which brings me to my second concern -- damn, that toolbar is huge. It also looks highly out of place with its custom background. The only practical reason I can see for doing it this way is the large position slider, but I wonder if there's a better way to do it. Then there's the holy war of whether to place the controls at the top or the bottom. iTunes and Songbird (which is highly derivative of iTunes layout-wise) are the only players I know of off the top of my head to have the controls on top (by default).
As far as people asserting what "most people" prefer, has there yet been an OpenUsability-type study of media player interfaces? I think that would be helpful somewhere down the line.
First and foremost, the prominent contextbrowser makes things easy for people who like it open all the time, or none of the time, but not those who only like it open some of the time. I don't want to advocate pref-bloat, but I think a toggle between a context-oriented view and a playlist-oriented view would be a very good idea.
- A single-line playlist view like in 1.x is, IMHO, much better suited for managing music, since it displays the most information at once.
- The context-oriented view seems better for playing music, a la WMP's "Now Playing" view, only better.
I, for one, would probably use both of these views at different times, so an easily-accessible toggle would be best for me. Besides, there's plenty of room on that toolbar.
Which brings me to my second concern -- damn, that toolbar is huge. It also looks highly out of place with its custom background. The only practical reason I can see for doing it this way is the large position slider, but I wonder if there's a better way to do it. Then there's the holy war of whether to place the controls at the top or the bottom. iTunes and Songbird (which is highly derivative of iTunes layout-wise) are the only players I know of off the top of my head to have the controls on top (by default).
As far as people asserting what "most people" prefer, has there yet been an OpenUsability-type study of media player interfaces? I think that would be helpful somewhere down the line.
I also think the toolbar is a bit big. Really I'd except big changes between now and 2.0 and probably for about a year after it as we get the new design nailed down.
As far as performance, we are replacing the current Context Browser which must generate a HTML page and then render it in HTML. String processsing is very expensive actually. So after the dust settles, I'd except Amarok 2 to be about as intensive a process as 1.4, if not less.
As far as performance, we are replacing the current Context Browser which must generate a HTML page and then render it in HTML. String processsing is very expensive actually. So after the dust settles, I'd except Amarok 2 to be about as intensive a process as 1.4, if not less.
First of all, I'm glad to hear about how Amarok is attempting to innovate, something which isn't always at the forefront of open-source developement.
With that said, I'm sure I feel the same as many other: nervous to see one of my favourite and most-used applications shaping into an uncertain form which I can not at this stage be sure I will be pleased with. The issue I'm worried about most, however, is whether or not Amarok will still actually fit into the KDE environment, especially the KDE environment if one happens to not be using the default settings. I have heard a quite a bit about Amarok 'manipulating' Qt in weird and wonderful ways, then I see screenshots like that which show an awful-looking custom background in the panel with the media buttons (I have little doubt that it is something which is being worked on, however).
I don't mind bells-and-whistles, in fact I'm really quite interested in a number of them, but please, please, remember that at the end of the day, Amarok is an application in a wider environment, and should fit in with that environment.
The other worry I have is the potential performance hit of such bells-and-whistles. At the end of the day, the function of a music player is to play music; I don't really want to sacrifice significant amounts of CPU power and RAM usage to the task. I would really appreciate any features with a potential performance hit to be optional.
And lastly... good work, and good luck. I might not like everything I see, but I know how much work you guys are putting into this, and I can certainly appreciate it
With that said, I'm sure I feel the same as many other: nervous to see one of my favourite and most-used applications shaping into an uncertain form which I can not at this stage be sure I will be pleased with. The issue I'm worried about most, however, is whether or not Amarok will still actually fit into the KDE environment, especially the KDE environment if one happens to not be using the default settings. I have heard a quite a bit about Amarok 'manipulating' Qt in weird and wonderful ways, then I see screenshots like that which show an awful-looking custom background in the panel with the media buttons (I have little doubt that it is something which is being worked on, however).
I don't mind bells-and-whistles, in fact I'm really quite interested in a number of them, but please, please, remember that at the end of the day, Amarok is an application in a wider environment, and should fit in with that environment.
The other worry I have is the potential performance hit of such bells-and-whistles. At the end of the day, the function of a music player is to play music; I don't really want to sacrifice significant amounts of CPU power and RAM usage to the task. I would really appreciate any features with a potential performance hit to be optional.
And lastly... good work, and good luck. I might not like everything I see, but I know how much work you guys are putting into this, and I can certainly appreciate it
Heh got confused. The comment:
"As far as performance, we are replacing the current Context Browser which must generate a HTML page and then render it in HTML. String processsing is very expensive actually. So after the dust settles, I'd except Amarok 2 to be about as intensive a process as 1.4, if not less."
"As far as performance, we are replacing the current Context Browser which must generate a HTML page and then render it in HTML. String processsing is very expensive actually. So after the dust settles, I'd except Amarok 2 to be about as intensive a process as 1.4, if not less."
I was probably one of those who have complained of the new design as I have all my songs loaded in the playlist at once, using shuffle sometimes but mostly listening to albums instead of songs. I never use the collection browser on the left side of Amarok 1.x unless I want to hear for example post rock and only post rock for a while, using the excellent sorting system according to Genre/Artist/Album and so forth.
If I could choose I'd scrap the "playlist" altogether (as I (almost) never make up lists with music I want to hear!) and instead put the collection browser in the big "playlist window".
Of course, sometimes I make up a list of music, for example if I've got a party or something here. But then I'm using the excellent queue function. Amarok of today is pretty redundant in certain aspects and from what I've seen and heard, Amarok2 is taking away all the good ways of managing music that Amarok1.x was about to start.
However, with the collection browser in the "playlist area" I could easily sort the music in, according to me, the perfect way. Kind of like the current collection browser works today, but instead of choosing music i'd like to hear and having to reload the playlist I could just start to play it.
As a person who's mostly not listening to songs, but albums, I could also make my "playlist" much easier to scroll through, only showing the artists (instead of every individual song!) and by clicking on a artist, showing the albums from that specific artist. A further click on the album would bring up the songs from that album. Double click on either the artist, album or a single click on a song would start to play either all the songs from that artist, the specific album or, obviously, just one song.
It could look pretty much like the "Favourite album" or "Newest albums" viewer in todays context browser.
That way, the "playlist area" wouldnt have to be so big due to the artist-album-title-and so on info is shown not vertically but horizontally.
GMPC, a client for MPD, is one step closer to that with the metadata browser function. It's not exactly how i want it, but it's pretty close. (screenshot on the link below)
http://img393.imageshack.us/img393/5658/skrmbildik0.png
I also use mysql as a database and even if the playlist is much faster with all songs loaded (about 16,000) using mysql the collection browser is soooo much faster in sorting the music and showing what's new or from a specific genre.
I figure that when you've got such a great function, why limiting it to such a tiny space? Let it have the big playlist area instead!
If I could choose I'd scrap the "playlist" altogether (as I (almost) never make up lists with music I want to hear!) and instead put the collection browser in the big "playlist window".
Of course, sometimes I make up a list of music, for example if I've got a party or something here. But then I'm using the excellent queue function. Amarok of today is pretty redundant in certain aspects and from what I've seen and heard, Amarok2 is taking away all the good ways of managing music that Amarok1.x was about to start.
However, with the collection browser in the "playlist area" I could easily sort the music in, according to me, the perfect way. Kind of like the current collection browser works today, but instead of choosing music i'd like to hear and having to reload the playlist I could just start to play it.
As a person who's mostly not listening to songs, but albums, I could also make my "playlist" much easier to scroll through, only showing the artists (instead of every individual song!) and by clicking on a artist, showing the albums from that specific artist. A further click on the album would bring up the songs from that album. Double click on either the artist, album or a single click on a song would start to play either all the songs from that artist, the specific album or, obviously, just one song.
It could look pretty much like the "Favourite album" or "Newest albums" viewer in todays context browser.
That way, the "playlist area" wouldnt have to be so big due to the artist-album-title-and so on info is shown not vertically but horizontally.
GMPC, a client for MPD, is one step closer to that with the metadata browser function. It's not exactly how i want it, but it's pretty close. (screenshot on the link below)
http://img393.imageshack.us/img393/5658/skrmbildik0.png
I also use mysql as a database and even if the playlist is much faster with all songs loaded (about 16,000) using mysql the collection browser is soooo much faster in sorting the music and showing what's new or from a specific genre.
I figure that when you've got such a great function, why limiting it to such a tiny space? Let it have the big playlist area instead!
Amarok Links
Calendar
Quicksearch
Categories
Syndicate This Blog
Blog Administration
We Listen To...
Powered by
