Wouldn't it be great if you could click on the headings in challenge history and sort by that column?
Then you could see the 10 ("n") highest scores, "n" highest averages, "n" highest vote counts, comment counts, etc.
This wouldn't be hard to program... maybe it just didn't come up as helpful or needed before. So if you think it's needed, cast your opinion here for the sysops!
I realized today also while looking at someone's own challenge stats that this too would be good to have column heads where you could click and resort.
Anyone else think that would be interesting (and my original suggestion, which was to make the global challenge history sortable in this manner)?
Both of these thoughts have crossed my mind at one point or another. I think it would be really cool to have a way to resort the statistics in these two areas. Since I am a fan of mathematics and statistics, I think it would be pretty fun to have up.
I'd certainly like to see it, especailly on people's profile pages - it's a bit limiting always being presented with just the same top four/five/six images
This definitely makes sense and if you are someone who is overly compulsive about things such as myself, this makes it a lot more comfortable (just dont ask). You could always resort from chronological order too. Being able to sort from lowest to highest, oldest to most recent (just some flexibility) would be nice as well.
I have been asking for this feature "on the inside" for a long time. You are right, coding it isn't that difficult. Apparently the problem is that querying the database for the Challenge History and User Profiles is very database-intensive, and making the columns clickable to allow sorting could lead to performance issues because of all the increased queries. But I haven't given up on the idea and will keep pushing for it. =]
That being said, if you select the "Challenge Entries" table in IE and then paste it in to Excel, the data is inserted very nicely and you can do all kinds of sorting/analysis/graphing quite easily...
I have been asking for this feature "on the inside" for a long time. You are right, coding it isn't that difficult. Apparently the problem is that querying the database for the Challenge History and User Profiles is very database-intensive, and making the columns clickable to allow sorting could lead to performance issues because of all the increased queries. But I haven't given up on the idea and will keep pushing for it. =]
why does this have to be dynamic? we only get new challenge results twice a week, so why not generate static pages for the stats sorted by column. They would serve up quickly and you'd only take the calculation hit once at the end of each challenge.
I have been asking for this feature "on the inside" for a long time. You are right, coding it isn't that difficult. Apparently the problem is that querying the database for the Challenge History and User Profiles is very database-intensive, and making the columns clickable to allow sorting could lead to performance issues because of all the increased queries. But I haven't given up on the idea and will keep pushing for it. =]
why does this have to be dynamic? we only get new challenge results twice a week, so why not generate static pages for the stats sorted by column. They would serve up quickly and you'd only take the calculation hit once at the end of each challenge.
Dave
Absolutely. Just 1) write the results to a MySQL table after each challenge and 2) the regular code always displays that. Childs play.
And this is how it should be coded even without the sort feature!
why does this have to be dynamic? we only get new challenge results twice a week, so why not generate static pages for the stats sorted by column.
For all I know, this may be how it is being done. I do know that the user statistics (average vote cast/received, etc.) are computed exactly like you describe.
However, one possibility is that sorting by all the other columns in the profile would result in 15 times the current amount of data (once for each column, ascending and descending, plus ascending by challenge date, since descending by challenge date is the current default). With over 19,000 users, pre-computing/storing those 15 sort orders would result in over 285,000 times the amount of data that is currently stored. That in and of itself could be enough to make that approach a bit unappealing.
Again, I'm not Drew or Langdon, but just offering one possible explanation.
Like I mentioned before, it has been an oft-requested feature, one that I'd personally like to see. If there is a way to do it that impacts system resources in a minimal fashion, and D&L have time to do it (that is the biggest issue!), we just might see it someday.
why does this have to be dynamic? we only get new challenge results twice a week, so why not generate static pages for the stats sorted by column.
For all I know, this may be how it is being done. I do know that the user statistics (average vote cast/received, etc.) are computed exactly like you describe.
However, one possibility is that sorting by all the other columns in the profile would result in 15 times the current amount of data (once for each column, ascending and descending, plus ascending by challenge date, since descending by challenge date is the current default). With over 19,000 users, pre-computing/storing those 15 sort orders would result in over 285,000 times the amount of data that is currently stored. That in and of itself could be enough to make that approach a bit unappealing.
Again, I'm not Drew or Langdon, but just offering one possible explanation.
Like I mentioned before, it has been an oft-requested feature, one that I'd personally like to see. If there is a way to do it that impacts system resources in a minimal fashion, and D&L have time to do it (that is the biggest issue!), we just might see it someday.
Eddy--given you are also a techie, I may be misunderstanding you, but if you are saying they would store a set for each sort order to be static, that's not necessary. All they have to do is take the code that generates the data, and instead of putting it out to HTML table, store it in a "stat" table. Each row of summary challenge data shown in your profile only needs to be stored once, at the end of a challenge. And at the end of a challenge, only one row needs to be added for each user participating--max 400 rows or so.
Then the UI code retrieves from that table, rather than getting raw data. When the user clicks a column, the data is simply retrieved from that table, with a different sort column (SQL order by clause).
Please forgive the explanation if you already knew all that (but someone listening may not)
All they have to do is take the code that generates the data, and instead of putting it out to HTML table, store it in a "stat" table. Each row of summary challenge data shown in your profile only needs to be stored once, at the end of a challenge. And at the end of a challenge, only one row needs to be added for each user participating--max 400 rows or so.
Definitely a good idea, but it is complicated by a couple things. First, post-challenge DQ's and the associated recalculations would need to be taken into account and all of the "pre-calcualted" data in the "stats" table updated to keep everything "in sync". (Read: more work for an already busy D&L). Second, the number of image views, comments and favorites is dynamic, even for challenge entries. So at least this data could not be "stored once and never updated again", and would still require real-time database queries for accurate data.
I'm pretty sure they're using 3.23.x with myisam tables, which is very restrictive in terms of db operations. If I want to run a long-running statistical query on table X, you can't do any updates/inserts to X (because of mysql's errant use of table locks). So, you have to do dumb things like: schedule "maintenance" time to run these queries; disallow useful features that involve slow queries (selects); make other bad design decisions to work around these mysql shortcomings.
It's possible to (re)design your table structure (and optimize your queries) to work around table-locking (and other mysql=myisam lameness), but using innodb tables in mysql is a much better solution.
