This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Rating-System: Some ideas for improvement

Tags: None
(comma "," separated)
elfstone
Registered Member
Posts
4
Karma
0
Rating-Feature

Ok, i thougt a little about a rating system, and how to implement it, I cant code QT or good c++, so some of the technical stuff might be wrong. Tho text is quite long, but i tried to think about this feature before posting a short featurerequest.

Why:
====

There are many reasons, why the scoring-system is not the best possible solution. First, normally i just listen to musik. I use a random playlist and play songs, or i use a use one of my handmade playlists. So normally i dont skip songs, so all songs will get same percantage while listenig, the score will tend to get 100 after some time. So, all i can use is the number of times i played a song, which is quite interesting, but it would me more interesting, to know which songs i enjoyed the most. Something the score cant tell me.
Sometimes im looking for a certain song, or for songs fitting into a certain playlist. Then i just jump through tracks, till i find something. With the score-system all the songs i looked at will get a worse rating, since i only listened to a few seconds.

So, the score-system can give you some interesting input, but its not a real rating, something i would really love in amarok.

What:
=====

What i would really like, is an active rating system. When i listen to my tracks, sometimes i think: \"hm, cool song!\". My idea is, that you press a global shortcut when you found a good/bad track (Windows-Up/Windows-Down maybe (short Ups/Downs)) to rate it. Amarok would note how often you rated a song good or bad, and calculates a rating. The rating-scale could be totally free, what counts is the average good-ratings / per number of times the song was rated. So if you really like a song, you can press Up-Up-Up, then the song gets three good ratings. Everyone could use his own scale, i.e. i could say 3 ups for a extremly good song, while others could use 10 Ups for the best possible songs to get a finer grained system.
The rating should only change, when the song is rate. I, and i guess many others, just listen to musik while working, sleeping, cooking etc and no interaction should mean nothing. So, what counts is # of Ups/# of ratings for that song.
Then this rating could be displayed the same way as the score is now, and it should be possible to change it manually.

This rating would reflect how much you enjoy a song, not how often you heared it, as the score does now.

How:
====
Ok, i looked at the code, and since i cant code good i will take some guesses:
Adding another global shortcut+dcop shouldnt be too hard if you can code.
The rating could be stored in the statistice-table, there are two columns you need: Number of total Ups (negative for bad ratings), and number of times the song has been rated (which is not #of times played, as mentioned above)

1. There are two ways to do this: You can store the number of ups while the song is being played, if the song is over, or the song is skipped #of total ups, and #of times rated is increased. I guess this could be done, where the score is adjusted, since the score-adjusting is done everytime a song stops playing, for every reason.

skip this, if 1. is possible
// 2. If 1. needs a lot of codechange, there is an uglie way to do it: Three new columns, #total_ups, #total_ratings, #last_rated_at
//
//
// If a song is rated, it checks the variable #of_times_played which is already an the database.
// If #of_times_played #last_rated_at the song is rated for the first time while playing now. #total_ups++, #total_ratings++, #last_rated_at=#of_times_played
// else #total_ups++
// This would be ugly, but it would work if the function is only called when a rating-key is pressed, while in 1. the function would have to be callde everytime the score-function is called.



I dont know, if there is a way to handle changes in the database from version to version, but maybe a the database should be checked for the additional columns everytime amarok is started and the additional columns should be added.

Im not quite sure, how it would be possible, to the rating could be edited manually, maybe this can be done later, a first idea would be, to change the #total_ups so the average rating would be what was entered, so the manual rating could still change when the song is rated again.



Conclusion:
===========

What do you think of the idea? Any ideas? Somebody wants to code that? I can try to do some of those things, but i would need helb with dcop and some qt-stuff i think.

Thx
elfstone
lfranchi
KDE Developer
Posts
77
Karma
0
it sounds like a very interesting proposal. very much like the itunes star rating system, only instead of setting stars, you increase/decrease the songs counter.

i think that if this is implemented, it should not just replace the current system. if you do not skip songs that you do like, the current system works pretty well at ranking some songs, and the knowledge that i can lower a songs score by skipping it is useful.

on the other hand, it would also be cool to be able to have a manually ranked list of songs. so one possibility would be to have them in parallel, with two different columns, score and ranking (or whatever it will be called). the good thing about this method is that you leave the choice to the user - if he/she just wants to use one of the systems, he just includes one column in the playlist browser. at the same time, this brings about some confusion, since we would have two completely different systems for achieving the same goal.

another option would be to somehow merge the two. the current system could be left intact, and the new one added. the addition of one rating could in effect \'bias\' the score to one or another side, so maybe if a song is highly rated skipping it loses less score. or something like that, i\'m not quite sure. this could also get incredibly confusing, if a use did not know how it worked.

i hope something useful came out of these $.02 :)


Amarok developer.

lfranchi, proud to be a member of KDE forums since 2008-Oct.
elfstone
Registered Member
Posts
4
Karma
0
I think it would be best to have them both in parallel. Both systems have theire pro/cons and work different. Also, the current system isnt explained, and i didnt know what it does before looking at the code to disable it :)
lfranchi
KDE Developer
Posts
77
Karma
0
i agree, i was just playing devil\'s advocate and proposing possible alternatives.

but i definately think that two separate columns would be best.


Amarok developer.

lfranchi, proud to be a member of KDE forums since 2008-Oct.
additionally...
Karma
0
I was looking for somewhere to put in my thought about the rating system, and here is as good a place as any, I guess...

I would find the current rating system useful were it not for one thing I consider a bug, or at least a fault in the reasoning that went into the rating system: namely, having it so that stopping amarok lowers the current song rating. It is correct that when I skip a song it deserves a lower rating, but I often have to stop listening to music because I am leaving my apartment, or something comes up, etc, and putting it on pause all day seems like a misuse of the concept of \"pausing.\" I often have to stop a good song for situational causes, and it seems like this would be the case for the majority of circumstances for which you use \"stop.\" In other words, given you want to listen to music, there should be a rating system applied. \"stop\" to me inherently means you no longer want to listen to music, and therefore the song on which the player is stopped should not be altered in rating.

Thanks.
ItsCosmo
Karma
0
There is a song in my collection that my 3-year-old boys are always asking me to play. They especially like the intro to the song, so I end up restarting the song several times before letting it play through. So even though this is by far the most played and enjoyed song in my collection, it has a very low rating. Sure, I can live with it, but I\'d at least like to be able to \"reset\" the rating from time to time.
User avatar
eean
KDE Developer
Posts
1016
Karma
0
OS


Bookmarks



Who is online

Registered users: bartoloni, Bing [Bot], Evergrowing, Google [Bot], ourcraft