Sorting options

Coordinator
Nov 4, 2010 at 1:00 AM

Hi there, we have an issue in NuGet http://nuget.codeplex.com/workitem/179 where we want to be able to sort on the following fields from within our client:

* Highest Ranked (default)
* Most Downloads (secondary default)
* Name (ascending) (tertiary default)
* Name (descending)

If we have time
* Author (ascending) 
* Author (descending)

Does the back-end currently support us sorting on these fields?

Developer
Nov 4, 2010 at 8:04 AM

Since it's using OData, it should generally allow sorting on any field that's part of the feed.

Coordinator
Nov 4, 2010 at 3:34 PM

Yes, as soon as it is part of the field ... but for instance ranking is only relevant in case of a gallery, and the OData feed is currently completely independant from it.

I will talk with Kevin about that this morning, as this might imply some changes if you want this feature at the feed level. Though for the author and name there should not be any issue right now. I'm a little bit more concerned about downloads and ranking ...

Developer
Nov 4, 2010 at 4:18 PM

Rating and DownloadCount are things that we definitely need to have in the feed, since the VS clients will rely on that for result ordering, and will also display that information in the UI.  Check out the existing VS Extension Manager feature to see what that looks like (our UI is nearly identical to theirs).

The only difference is that those fields don't come from the package itself, and are owned by the server.  But from a feed standpoint, they are no different from all the other fields.  Same deal for things like Report Abuse URL.

David

Coordinator
Nov 4, 2010 at 4:21 PM

Agree with Ebbo. We definitely need Ratings and Download Count. The Rating should probably be an Average Rating so we can sort on it. Ideally, it's 0 until there's a set number of rating. And as David points out, these are fields that *must not* come from the package but only from the gallery.

Developer
Nov 4, 2010 at 4:27 PM

Yes, rating is an average, with a range of 0 to 5.  On the server, it should probably be stored as two fields: SumOfAllRatings and NumberOfRatings, with the rating in the feed being SumOfAllRatings/NumberOfRatings.  But that's of course an implementation detail of the server.  The client just gets the one rating from 0 to 5.

Coordinator
Nov 4, 2010 at 4:30 PM

Ideally all of those fields are in the feed. If you have 1000 packages with an average rating of 5, you’ll probably want a secondary sort on the number of ratings.

Developer
Nov 4, 2010 at 4:38 PM

Yes, that's a good point.  Well, maybe Average and NumberOfRatings.  SumOfAllRatings doesn't need to be there.

Coordinator
Nov 4, 2010 at 6:04 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Nov 4, 2010 at 8:14 PM

We are aware of the need for the feed to expose the average rating and number of ratings for each package. We haven't begun the rating/comments work on the front-end yet, but we can bump this up on the priority list a bit.

Developer
Nov 4, 2010 at 8:59 PM

Maybe as a quick first step you can just hard code those numbers in the feed?  e.g. all packages have rating=3, num=50 (or maybe get some variability bu using the length of various other strings).  This way we can start doing some client work that uses those before it's fully implemented.

Coordinator
Nov 4, 2010 at 10:17 PM

Okay, we'll look at getting some fake data in there as soon as we can.

Coordinator
Nov 4, 2010 at 10:39 PM

Here's an interesting idea for sorting by most popular. http://blog.linkibol.com/2010/05/07/how-to-build-a-popularity-algorithm-you-can-be-proud-of/

Maybe not a v1 feature, but worth considering for v2.