Jump to content

Amarok/Archives/DirectionAndSolutions

From KDE Community Wiki
Revision as of 16:57, 14 January 2013 by Mamarok (talk | contribs) (remove category from archived article)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Status of this page: March 2011

Introduction

Our vision statement: The Amarok team strives to develop a free and open music player that is innovative and powerful, yet easy to use. Amarok helps rediscover music by giving access to a vast amount of different music sources and related information. In a world where music and computing are everywhere, Amarok aims to provide the best music listening experience anywhere, any time. The Amarok team promotes free culture. Amarok makes people happy.

Target audience

Who are Our Users *now*?

  • Music lovers
  • Generic Linux users (most people listen to music)
  • We cater to geeks

Question: why do we have so few female users? Is it the wolf icon? Is our community welcoming to women? Do we have disabled users? Do we design with accessability in mind? - Valorie

Linux users

  • Present base: Linux geeks
    • The people who subscribe to our list and hang out in #amarok are Linux geeks, for the most part. They are willing to file bugs, post on the forum when they can help, may be willing to build from git. These guys love us.

Windows users

  • Right now, all geeks, because Amarok/KDE isn't installed OEM.
  • We may have a few Windows hobbyists here too. While they may be knowledgeable and adventurous, they are used to Windows ways, not Linux ways of handling issues.

Mac users

  • All geeks I suppose.

Who do we want to target in the future?

Linux users

  • Future base: Linux-using non-geeks
    • Sheila uses Amarok because her son installed Ubuntu and Amarok on her computer when he tired of cleaning up viruses and other mal-ware on her XP. She misses iTunes, and is having some difficulty getting her iPod filled with the new CDs she got for Christmas. She's never used IRC, and doesn't know what mail lists are. She might find our Forum by googling, but she is frustrated that the Help menu isn't giving her help. Sadly, we never hear from her when she runs into difficulty. If her son is very patient, she knows where her music collection is, and how to use the playlist.

Windows users

  • So far, they seem to be Linux/Amarok users who have to use Windows boxes at work, etc.
  • The profile we want to target is people who get all their friends to use Firefox.
  • one thing geeks do better is tollerate technical frustration because it a challenge to fix, we need to expand beyond those

Mac users

  • Do we want them?
  • Most importantly, do we have the will and resources to provide a high quality user experience on Mac?
  • On mac anything not using the osx look and UX guidelines will look strange.


Users on new platforms?

What kind of user would we target on tablets or handsets? Would we want that?

  • During the Vision Creation meeting it has been made clear that the market is changing and shifting towards more mobile form factors.

Target platforms

  • How many platforms can we honestly maintain?
    • Mixed answers, 1-3.
    • The consensus seems to be on pushing only Linux+Windows as far as the desktop is concerned.
  • For the brand it's better to ship a good product on one or two platforms rather than a lousy product on wherever Qt runs. --Teo

Linux (desktop)

  • Still our primary platform?
    • Yes, devs use Linux and like Linux, and this isn't changing any time soon.

Windows

  • Do we have at least one committed dev who will maintain Amarok as we know it or a future iteration of it and guarantee a quality similar to our Linux offering?
    • Mark says that he would try and contribute to improving and supporting Amarok on Windows.
    • That's as close as we got to having a Windows go-to person.
  • We need a nice installer.

Mac

  • Do we have at least one committed dev who will maintain Amarok as we know it or a future iteration of it and guarantee a quality similar to our Linux offering?
    • No.

Handsets and tablets

  • Android lacks a good *free* music player, can we take advantage of that void?
    • We can and we want to.
    • Fluid interfaces, fun, game-like.
    • WIMP is dead.
    • A lot of music listening nowadays is streaming.
  • WebOS, MeeGo? Is the latter still relevant (maybe on tablets)?
    • Both. MeeGo might be low hanging fruit.
  • Platforms:
    • Desktop Linux = wanting and running,
    • Windows = wanting and kinda able,
    • MeeGo = wanting and able,
    • Android = wanting and not really feasible *right now*,
    • WebOS = wanting but not much of a market now,
    • Maemo 6 = wanting, easily doable, not in the market yet
  • iOS and WP7 are out of the question for the time being.
  • Some say that tablets should take priority over handsets.


Technical challenges

  • Nothing of our current UI is usable on mobile devices.
  • Do we want to go full QML? Maybe, apparently yes, even on desktop eventually but not yet. On mobile yes, straight away.
    • On desktop it might be good to try and make gradual changes.
  • Is an Amarok 3 needed? Eventually, it would be a PR choice.
  • We could have a design competition, but some objected that it wouldn't produce quality entries.
  • We keep developing 2.x incrementally until such a time when a gradual and feature full port to QML is possible or required.
    • We want stability, no more features!
    • CV could go QML first, not everybody is sure about that yet.
  • We keep our current release schedule, and focus on quality.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

Features to be scaled down and *why*

  • CD playing. I want it, like it, but it doesn't work, and no one is willing to fix it. Therefore, we shouldn't offer a broken "feature". - Valorie
    • Many want it.
  • Is the same true of iPod support?
    • Work is ongoing on this.
  • Playlist sorting, including shuffle, is clumsy, it needs to be an action rather than a state.
  • Playlist layouts are very configurable, so much so that they are too hard to use for many users.
    • Note to self: Flexible code is ok, but think twice before exposing the complexity to users.
  • Dynamic Playlists: GUI is too complicated. Feature should be easier to use, and provide presets for common use cases. Markey
  • Automated Playlist Generator (APG): Could be replaced by an improved Dynamic Playlists feature? At least the naming should be rethought. What does "Automated vs Dynamic" mean? Markey

Features to be redesigned

  • Context view: it never behaved just right.

Potential new features

  • playback history for radio streams, seamlessly integrated.
  • More online radio services, because cloud-music is the new thing.