Hi Richard,
The red āFilter activeā text appears when a filter is applied to the data, which has the effect of reducing the number of results returned from a query. Thatās why itās so important to notify the user that the filter is active, otherwise he/she may wonder why results differ from those in, say, the SOTA database pages. That notification consists of two words, which take up very little screen space.
The other settings in the main page Settings dialog, on the other hand, do not reduce the number of results returned, but simply affect how data are presented graphically or in the table: so they can be considered to be of lesser importance than the filter. In any application like this - and especially a web-based application - there is often too little space available to present everything to the user. Thatās what dialog windows are for: presenting sets of additional information, or controls, to the user to enable certain additional tasks to be performed without cluttering the main view.
Good GUI design is all about elegant use of screen space without over-taxing the userās eye. So: no, Iāll keep the Settings dialog - and itsā settings - just the way they are, if you donāt mind.
Ah, would that I were able to do this! At the moment, I have no way to do so, and thatās because your (and everybody elseās) activations data are locked away in the SOTA database, to which I have no direct access. Understand that the SMP is a completely independent entity from the main SOTA sites, and runs on a completely different server, etc.
It would certainly be possible to use the new SOTA API to grab such data and thereby to tailor the display of summits in the SMP: on my side, itās no exaggeration to say that I would need just a couple of hours to create the code to make that work. Unfortunately, the person in charge of the API appears to be so snowed under with other responsibilites that he can spare no time at all to develop the necessary functions to enable such a flow of data. And thatās the state of play at the moment.
Of course, another possibility for the SMP to get relevant activations data does exist - and that is that the user him/herself upload those data to the SMP. It would then be in principle a simple matter to present ānon-completedā summits, or whatever, on the map. But then I/the SMP run the risk of being inundated with streams of data, none of which can be guaranteed to be ācleanā.
The API is definitely the way to go here: if you and others are concerned enough about this matter, I would suggest you contact the MT and make your thoughts known to them. Perhaps some action regarding further development of the API might ensue; but I would suggest you not hold out too many hopes on that particular frontā¦
Best regards and 73,
Rob