Forward: This is a repost of the article which I wrote for a recent commit digest report by Danny Allen. Since February, Amarok 2.1 has continued improvement, so don’t take the following content as “exhaustive”.
Amarok 2 marked the first release of the newest generation of Amarok. This marked over two years of very hard work by our entire development team was greeted with great relief by all contributors to the project for a number of important reasons. As developers, we were keen to get our software out the door to users on a larger scale than simply beta quality software. We craved the feedback from the masses to improve Amarok and to get out the feature freeze that seemed to never end. More than that, all developers had great plans for implementing new features and reviving loved functionality that was temporarily removed during the overhaul.
One of the most challenging parts of the transition to Amarok 2 was refactoring the innards of the application to make it more scalable, robust and flexible for future improvements. In many ways, this was one of the biggest technical problems of the 1.4 series — it did not scale well to new features.
Following the release of Amarok 2.0, we received mixed reviews from critics and users alike. Many writers praised the user interface overhaul and infrastructure changes, such as Ryan Paul in his article over at Ars Technica:
“After extensive testing, I’m convinced that Amarok 2 is a major improvement.”
Jeremy LaCroix of linux.com reported a fair review and noted many aspects of Amarok 2.0 that left much improvement to be desired. As a team, we’ve concentrated on many of the concerns that have been raised in reviews and in forum posts by evaluating importance and relative cost of implementation. Examples of requests which we have brought back for the 2.1 release of Amarok include: track queueing, replay gain support, playlist searching and playlist layouts.
We were well aware that with the release of Amarok 2.0, it would be impossible to match the feature set precedent that had been set so high by us in previous releases. To put it simply, we felt that Amarok as a project would have been detrimentally affected by indefinitely waiting to reach feature parity with the 1.4 releases. We were forced to take a stand and simply tell ourselves to wait to implement them. Trying to incorporate the features that are the most useful and important is a difficult task when there are often twelve different responses between five people in a discussion — one man’s garbage is another man’s treasure. That said, we did elect to remove some features from Amarok entirely – mainly for technical reasons (multiple database support for example), some for lack of developer resources (moodbar), and also some for usability reasons (such as tabular playlist design – remember, we’re the experts!).
Initially, the responses to the announcements of dropping features was exactly what we expected — there would be outcry. We expected this for a number of reasons: only the disgruntled speak up, and most readers wouldn’t initially understand how they could adapt to new paradigms. We dealt with this by trying the best we could to deal with the fallout by responding to each individual complaint or worry, but obviously we couldn’t get to all of them (and some were not worth wasting time on). I feel that we’ve managed the community quite well, and that the community has been good to us too by mostly understanding our position and being patient with the developments. Honest communication through blogs of missing features that would return was appreciated by users, and we’ve done our best to bring back the most requested for 2.1.
Many users have decided to stick with Amarok 1.4 for the time being until they see a better set of features implemented. And quite frankly, that’s okay with us. On the otherside, there are users who are keen to try out newer development features but are uncomfortable messing with their system compiling unstable development versions. Neon, our nightly build package service has been praised and exceptionally useful to give users cutting edge builds with no hassle.
Finally, it seems to us that most of our users have noticed the rough edges of the graphics which are being used in the application (specifically the context view). We realise that this does need some work and are trying hard to work with artists develop some great visuals. Also we’ve tried to improve the usability and performance of the context view by providing only a single containment rather than four, and better widgets to use.
If you’re interested in seeing a tour of some of the new (and revisited) features which are coming to Amarok 2.1, take a look at this great overview.
But Amarok lacks nearly all of my use cases.
One is described here: http://amarok.kde.org/blog/archives/559-Dynamic-Playlist-niftiness.html
Next is support for podcast with my iPod (automatic delete of fully listened ones).
And last is, that I want to fill my iPod with 5-star-rated songs, and some random 4-star-rated songs.
But I’m confident, that Amarok 2.2 will be usable for me again. Keep up your good work!
Personally, although I have other outstanding annoyances/issues, running Jaunty/KDE4.2 right now on my laptop I only have two main issues with Amarok 2 . . . but they’re dealbreakers, unfortunately.
(1) Podcast episode info: In 1.4, you could see the episode info when you clicked on an episode of a podcast; this greatly helps with things like say Hacker Public Radio where the podcast is by different people every time and often with titles that aren’t elaborate enough on their own. Without being able to see the info (which Amarok is downloading already anyways if it’s downloading the podcast’s feed), 2 becomes quite inferior to 1.4 as a podcast aggregator.
(2) Being able to drag and drop from playlists or podcast-lists/collection into a file browser like Dolphin or Konqueror. This is how I do it 99% of the time with KDE3/Amarok1.4….being a die-hard Linux user I’ve always had UMS music players that support ogg and FLAC (hey, they tend to be the best ones anyways) so I’ve never needed anything fancy like MTP/iPod support or transcoding, just let me drag and drop files and let me see the info of my podcast episodes and I’m a happy camper
I should be clear, I have nothing but respect for all the Amarok devs, and I’m trying as hard as I can to use Amarok 2 on my Jaunty laptop (at the moment I have no landline, so I’ve been using my laptop as my window into the internet and as an experiment in using KDE4 all the time)….just that so far I really can’t justify switching from 1.4 and I’ve yet to hear for sure that the two sticking issues will be addressed
(But Amarok rules!)
2.1 does feel like a big improvement however there’s one dealbreaker for me and that is IPod write support. I have tried other players such as Songbird (getting pretty close to taking on Amarok) but I think 1.4 is still the best purely because of the dealbreaker.
The rest of the issues are more minor but I would like to see them again.
1. Less gray please, it looks like Miami.
2. I would like too see the return of the last.fm upcoming concerts widget please. It was in 2.0 but I haven’t had it since and that was my fave plugin.
3. I would like to be able to search through my playlists (different from the playlist).
4. I would like somewhere to store radio streams (I had created a folder in the playlists and then added them in to that – back on 1.4 since).
5. I know scrobbling is available but have never had it work from 1.4 onwards.
6. I would like to be able to download podcasts before I play them so that I know how long the podcast is, there are no buffering issues etc…
Great work though, with just the IPod support I should be able to happily join the 2.* fold and the rest are minor issues (the concert viewer is a biggy, I never even knew I would want that until I used it in 2.0 and infact I still have concerts to attend suggested from that!)
Providing NEON only for Kubuntu is the worst thing you’ve ever done. Everybody knows that Kubuntu is the worst KDE distro in existence.
I have no idea why you didn’t just use openSUSE Build Service — it can generate packages for many distros. Instead you advertise that Kubuntu crap.
Removed (I was being an insensitive fool)
Personally I’m loving Amarok 2. I mainly use Amarok Nightly. It’s a bit like those games where you have to find the differences between two images… every time it updates you get to try and find the improvements!
The only thing I’m really missing is that Amarok doesn’t seem to see my Creative Zen Mosaic making me use the incredibly ugly but functional Gnomad2.
What exactly is moronic with Markus’ behaviour? I support his statement 100%. To me it as a complete miracle as well why you guys don’t use the openSUSE Build Service to create packages for more distros than just Kubuntu…
Seb, are personal attacks the only means you can defend your behavior?
1.) Harald Sitter himself posted a few days ago how Canonical sabotages Kubuntu: http://apachelog.blogspot.com/2009/04/facts-about-rosetta-and-kubuntu-l10n.html
2.) Build Service allows automatic building of packages for various versions of SUSE, Fedora, Mandriva, Debian, Red Hat / CentOS, and (K)Ubuntu.
Why didn’t you choose Build Service and instead opted for a closed-source single-vendor solution? (Launchpad is not Free Software.)
Okay, apologies, perhaps I got out of hand
. Let me cut straight to the point – the only reason we don’t support OpenSUSE build service is because we don’t have any volunteers writing packages for it. The corollary is: the only reason we support Neon is because Harald Sitter has been very active in creating the packages. (Neon is his brain child).
Pingback: markey's status on Wednesday, 29-Apr-09 11:26:39 UTC - Identi.ca