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,