Web Design Discussion > General Web Design Discussion
Proposal: Bonus systems category for making regular stats games easier to play
vdeane:
The easiest way would probably be to define disabled systems in the .list file and then compute two sets of stats for users with disabled systems, one with them not included and one normal with some new table entries for it. Maps are a more interesting question. I could see a checkbox for whether to show disabled routes (if I were disabling systems, I'd want them off the map), but that would probably be a bit more work to code.
Regarding making grab bag systems "bonus" or anything else, I don't think those necessarily work cleanly. Take usasf - it's easy to say Sugarloaf Parkway in GA should be bonus, but the New Jersey Turnpike is pretty integral to its state.
Jim:
I know I've mentioned this before, but I think it's worth mentioning here while these issues are back at the forefront.
I don't envision any implementation of filtering by systems or categories of systems being based on information in .list files (i.e., chosen by the TM participant) but based on choices on the web front end (i.e., chosen by the TM website visitor). This makes more sense to me both from the likely ability to implement it, and for maximum flexibility. So if user X is only interested in some subset of systems, they can choose to restrict what they see on the site based on that, for all TM participants (defined as those who have submitted .list files). But when user Y comes along, they will see user X's stats and maps based on what Y's browser has defined as their subset of systems of interest. I worry that some might be hoping for "since I don't care about or track travels on unsigned dirt roads of Madagascar, those should always be excluded from every possible view of my stats".
vdeane:
--- Quote from: Jim on January 04, 2022, 11:05:47 pm ---I know I've mentioned this before, but I think it's worth mentioning here while these issues are back at the forefront.
I don't envision any implementation of filtering by systems or categories of systems being based on information in .list files (i.e., chosen by the TM participant) but based on choices on the web front end (i.e., chosen by the TM website visitor). This makes more sense to me both from the likely ability to implement it, and for maximum flexibility. So if user X is only interested in some subset of systems, they can choose to restrict what they see on the site based on that, for all TM participants (defined as those who have submitted .list files). But when user Y comes along, they will see user X's stats and maps based on what Y's browser has defined as their subset of systems of interest. I worry that some might be hoping for "since I don't care about or track travels on unsigned dirt roads of Madagascar, those should always be excluded from every possible view of my stats".
--- End quote ---
That's why I suggested two sets of stats; that way one could get the % with dirt roads included (though just because something isn't tracked doesn't mean they haven't been there, so that number wouldn't be gospel) if they wanted. I do wonder - how would stats work if excluded systems were determined by user settings and not .list files? My understanding is that they're currently processed during site updates and then stored in the database. Maps would be easier on that front since they're drawn on the fly.
There's also the question of whether users could link to their page with those settings set. I have mine linked from my website, for example. I imagine someone looking to share their maps/stats would probably want what others see to be similar to what they see.
Bickendan:
A user toggle for each system could be the solution, so if I were only interested in TriMet and C-Tran lines of the Portland Metro Area, Hennepin and Ramsey County numbered county routes, Eurostar train lines, streets of Manhattan, and the AH/NH/WB network of West Bengal, India, I could toggle the flags for those specific systems and track those.
I wouldn't think this would cause much work to be done on the data side (aside from adding, validating, and maintaining such esoteric systems), if at all.
Navigation
[0] Message Index
[*] Previous page
Go to full version