Stats restricted to systems/regions/etc of interest

[yakra]

"they" meaning the "someone coming to TM", I presume?

[Jim]

"they" meaning the "someone coming to TM", I presume?

Yes, as I envision it, anyone browsing the site could view anyone's stats and maps with any subset of data they wish.

[vdeane]

I suppose a question is, how useful is it to view another person's page with systems they are not tracking?  Presumably they wouldn't be marking travels on them, so any stats including them wouldn't necessarily be representative of their travels regardless.  It's not like people are installing GPS devices in their car to log whenever they clinch something.  All the data is self-reported.  We already have this now - there are people who only track certain things (I know of at least one person who didn't track state highways for the longest time, and the only state routes that showed up on his page were those that overlapped with interstates and maybe US routes), and people who haven't updated their page since more systems have been added.

Perhaps a compromise, one that allows the site to avoid user account hassle?
-Users could define in their .list file or in a configuration file the "default" configuration for their page.  This would be used for any visitor who doesn't have their own configuration set or flagged in the URL for external links.
-Users could open a control panel letting them configure things like colors, included/excluded systems, etc. and these settings would be saved in a cookie and would override both site-wide and user defaults.  They could be site for site-wide browsing, for browsing a given user's page, for the current session, or as a default whenever they come back to the site.
-There would also be buttons for reverting both to a user's defaults and the website defaults.
-Users could export configurations to a text file that could then be imported at any time, either for a pre-set view or because something happened to the cookie.

I'm not sure how compatible the rank statistic is with this, but maybe it's not needed?  I think there was someone lamenting the view of the site as a competition in one of the threads.

[si404]

An issue with some of the systems proposed/implemented on TM is that some people have no interest in clinching them and feel that they get in the way of their game of clinching all the routes they want to clinch in a region (normally Interstate, US, state and bannered variants thereof) and want a filtering system to remove them.

In order to filter these systems out simply, I propose a new categories for systems, alongside the existing active, preview and devel - 'bonus' (not-yet ready bonus systems would remain plain 'preview' or 'devel'). 'active' might want renaming 'regular' or something similar.

Bonus systems would be the freeway grab-bags, tourist routes, city routes, etc that are nice to have in the database, but aren't everyone's cup of tea. It would also allow the creation of grabbag-style systems that cover unsigned routes and/or major local/private roads that don't fit into the freeway grab bags (eg the entirety of the Sugarloaf Parkway could be in the database, etc) without having the statistics issue.

Stats, would - instead of 'active-only' and 'active & preview', would be 'active-only', 'active & bonus', and 'active, bonus & preview'. I imagine that would add quite a lot of time to the update process to create the 3rd set of statistics and this is the big problem I can see with my proposal.

Thoughts?

[si404]

Putting it in web design though it's more a data/data processing proposal, because the Highway Data boards are too narrow - feel free to move if you think there's a better home for the discussion.

But there are web design issues

• what colour would bonus systems be displayed as (some sort of light blue, or an orange, are two options I've thought of and think might work)
• would the table be too wide with three sets of statistics columns?

[mapcat]

I like the general idea but fear that arguments will continue, as users debate which systems qualify as active. How well would this work for a user who, for example, wants to track named freeways but not historic highways? Would this be easier to code than the previous suggestion of providing users with the ability to select all sets of interest to them?

[si404]

Would this be easier to code than the previous suggestion of providing users with the ability to select all sets of interest to them?

I'm definitely not a coder, but I reckon even I would be able to do it with the tools of copy-paste! As far as I can see, it wouldn't be adding anything new, just doing the same stuff an extra time.

The selection is much more complex as it's a whole new function. It also seems much more intensive as the server would have to calculate bespoke stats.


And, yes, there would be the issue of what's bonus and what's not - it's not a flexible solution that can be tailored to individual users. Someone wanting to track named freeways would look at active stats and then the stats for the bonus system (should those named freeways be in bonus systems*).

*usasf would likely be considered bonus, but would, say, usakyp?

[michih]

And, yes, there would be the issue of what's bonus and what's not - it's not a flexible solution that can be tailored to individual users.

Yep, that's why the proposal has more disadvantages than advantages IMO. Solve a problem but open another one.

[Jim]

I prefer the more general solution we had been discussing earlier about supporting views of the maps/stats based on whatever subsets of systems that someone is interested in working with at any given time.

[Markkos1992]

Yeah, I am with Jim on this one.

[si404]

Fair enough, everybody.

I too prefer the general option for more control, but saw a possibility for something easier and quicker to implement and so wanted to see if it might be a solution we could make happen quickly.

[Duke87]

I do share the concern that this shifts the arguments to what should count as a core system versus an extra or "bonus" one. There will, after all, be varying opinions on this.

However I do see one benefit to this method: it would allow users to still show clinches in their stats of systems they aren't interested in finishing, but have nonetheless driven some of.

Perhaps it would be a good idea to borrow a concept here and, while still developing a user toggle, showing toggled off systems in a separate column on stats tables rather than hiding them outright.

So you'd have three columns: "active", "active + preview", and "disabled". With everything the user has placed in the third category shown there and excluded from the other two columns.

[Jim]

If we were to go down the path of one or more new "level" values to augment our current "active", "preview", and "devel", we could consider breaking down by what are verified as complete and well-defined systems, the more "grab bag" systems, and maybe other kinds of categories.  I am still not thinking it's the way to go, but just thinking about something other than the name "bonus".

[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".