Leaderboard

Unfortunately this is a bit more complicated than the discussion would lead you to believe. Because of the fact that a user may have many logbooks for many different callsigns, statistics on the site are very "callsign based". This means that, using AA3B as an example from the screenshot a couple posts up, that the CALLSIGN AA3B has 827K+ confirmed contacts (at the time of the image). The user AA3B however has a helluva lot more than that total because he manages a number of different logbooks for a number of different callsigns. In the list however, these alternate callsigns would be listed separately.

That being the case, one consideration becomes a bit more subjective: Is it, how many OPERATORS am I competing against? That would be Total Logbook Users. Or is it, how many CALLSIGNS am I competing against? That would be CLOSER TO Total Logbooks, but even that's not accurate. Some operators have multiple logbooks for the same callsign with different date ranges. I specifically fielded a support ticket recently for an operator that opens a new logbook PER YEAR for his callsign and he's been doing it for approaching ten years now, so there's even some distortion in the ability to compare Total Logbooks because of that. I believe (but I'd have to review code to double check) that such cases of multiple logbooks for one callsign are combined for the purposes of ranking, which of course, further confounds an accurate total number to compare to.

Total Logbooks: 337,284
Total Logbook Users: 276,379

As for the specific ranking in each category: Each category is run against all logbooks and thus, the size of the "population" as it was termed in one post above is the same for each category, and is CLOSE TO Total Logbooks (Callsigns), but again, not identical to that number because of the logbook variations discussed above. I'm sure that related to the query that's run to determine the statistics published and shown in the leaderboard list, it would be possible to determine the accurate "total callsigns" population, but I'm pretty sure that's not currently available outside the query itself. Further, if it is, code changes would be needed to make it available in the user interface somewhere. I'm going to add it to my list for the team to consider for future code revisions.

Regarding the question of combining logbooks to see the standing by operator: This is a very difficult consideration for QRZ because of the nuances in the ways operators use QRZ and the variations in how each operator wants to utilize the callsigns attached to their user accounts. Where this is most visible currently is in the awards section, where a user needs to select what logbooks they manage should be applied to an award they want to apply for. Users managing club and special event callsigns often don't want those logbooks attached to a personal award, and may even want them to have their own awards. They may or may not want the managed call awards to show on their personal QRZ page. I've even recently seen cases where an operator wanted to distinguish his awards between his current callsign and his past callsign.

Thus, how do we decide which of the user's logbooks to combine if we want to compare operator to operator for stats? I'm sure opinions are going to vary on this. This question actually came up recently in a support ticket from a user that wanted to do the same thing. The query to do this would be quite a bit more complicated than what's being done currently and would likely require the addition of a logbook setting for something like "include this logbook in ranking stats for me". It's potentially do-able, but it would require a fair amount of logistics and it's potential value as a feature would need to be weighed against other development priorities.

Clear as mud?

73, Steve

 

I knew someone would ask about a scroll feature. I just couldn't think of a good way to address it in my last post. I'm not going to say it's out of the question, but the problem with a scroll bar is that it puts a MASSIVE burden on the server, either in the form of having to run the query and provide ALL of the records each time the page is loaded (or cache them, but still lots of records) OR by interacting with the server again every time the scroll bar is moved to get whatever range should be displayed at the time.

Consider the scrollbar option for a moment: since each of the three categories is different in the ranking, that's three sets of data for the entire range. If, from my post above, Total Logbooks is roughly equal to the total number of callsigns in the list (allowing for the discussed variations), that means 337K+ entries in EACH CATEGORY. That's pretty close to a million records to provide to the page just so someone can scroll through them. That's an unreasonable load.

Using a concept like the up 12, down 12 buttons you proposed would function similar to the query that shows you where you are in the list, so that would be less of a burden, but I'm not sure I see the value in that in terms of cost of implementation vs use of feature. It doesn't seem likely to me that anyone is really going to spend time going up and down the list. I think it's far more realistic to keep the existing functionality, but provide the addition info that you're #5510 out of 337284 or whatever the actual number is; perhaps in the form of a line entry below the list that says something like "Out of xxxxxx callsigns and yyyyyy confirmed QSOs."

In any case as I said above, I've added it to my list for the team to consider as new development occurs.