Travel Mapping

Web Design Discussion => General Web Design Discussion => Topic started by: Jim on December 30, 2020, 08:10:13 pm

Title: region.php and system.php
Post by: Jim on December 30, 2020, 08:10:13 pm
These two pages were left behind during last summer's updates to Mapview, and breakout of the HB functionality to the new showroute and findroute pages.  I'm not sure when I'll try to do so, but I'd like to update them.  Before I do so, I'd like to hear some ideas about what people think those pages should look like.  If you go to them now, you'll see some controls at the top, then a short and wide fixed-size map, followed by the tabular data about the region or system.  Thinking about the history, I recall this design being modeled after similar pages from CHM.  How would you like to see the information currently on that page displayed and organized?  Do you find the map useful?  Too big?  Too small?  I think it's annoying when I try to look at stats for a larger system or region and it's taking forever for the map to load.  Is there other information you'd want to see on those pages?
Title: Re: region.php and system.php
Post by: vdeane on December 30, 2020, 10:18:33 pm
Given your comment about waiting for the map to load, perhaps a checkbox for whether to show the map and a cookie to remember the setting?  I actually still use those pages for viewing maps sometimes, especially for larger regions and systems like usai that take forever to load in Mapview, but yeah, it can be annoying when I just want some stats.

One thing that's been mentioned on other threads is how region has the list of other travelers and system doesn't.
Title: Re: region.php and system.php
Post by: michih on December 31, 2020, 02:38:26 am
I don't like the map on those pages and think that a well visible link is enough. It's too large and at a too prominent position. When I wanna scroll down with the mouse wheel in the page, I often zoom in the map instead...

I'd like to have the very same info on the page (all data loaded) but with improved navigation on the page (hide/unhide what you currently wanna see).

I'd like to have kinda "tabs" for a quick jump to the desired table:
user/region.php: Overall region stats / stats per system | Stats by Route | Travelers in Region
user/system.php: System stats / stats per region | Stats by Route | Travelers in System (new)
user: Overall stats / Links | Travelers in continent (new) | Travelers in country (new) | Stats by region | Stats by system

The first "tab" should always be visible when the page is reloaded.

The link to the map could be on top next to user + units (+ system + region) selection which should always be visible independent of the "tab".
Title: Re: region.php and system.php
Post by: yakra on December 31, 2020, 02:56:22 am
One thing that's been mentioned on other threads is how region has the list of other travelers and system doesn't.
Per some recent discussion, I was about to dust off some long-procrastinated plans to add a list of rankings to system.php. Shouldn't be too hard.
Although, is that he best place to present that info?
I think it might be better to have it on separate pages -- CHM called them travregion.php & travsystem.php IIRC.

I'd like to hear some ideas about what people think those pages should look like.  If you go to them now, you'll see some controls at the top, then a short and wide fixed-size map, followed by the tabular data about the region or system.  Thinking about the history, I recall this design being modeled after similar pages from CHM.  How would you like to see the information currently on that page displayed and organized?  Do you find the map useful?  Too big?  Too small?
It's been enough years since I've looked at CHM that I can't remember how it was laid out. ISTR the map .gifs (generated by PHP) being 700x700 and that's about it.
I was almost thinking something along the lines of frames or iframes or divs  or however it's done, to keep the map in place while the user scrolls around the table(s), but...
Keeping the map its current height would leave little to no room below for the table.
I'm unsure how practicable displaying map & table side-by-side would be, especially for those running lower resolutions. I was at 1280x960 for many years.
I don't have a good solution to offer. Maybe CHM worked as TM does now, where we would just scroll the map off the top of the screen.

I think it's annoying when I try to look at stats for a larger system or region and it's taking forever for the map to load.
Comparing loading times between region.php & mapview.php for a couple large states, the newer mapview code loads a lot faster. (More efficient SQL queries?) It'd be nice to similarly improve region.php.
Mapview does redline one CPU core on my client machine the entire time it's loading, whereas region.php just has a short burst of activity after the data comes over the network and it renders the map & table.
If we could get the faster loading times along without all the CPU use, that'd be gravy. (Or is the CPU use a necessary side effect of JSON/AJAX?) If we can't have that, then I'll take the faster load times of course.
Any performance improvement from using MySQL 8.0? (https://forum.travelmapping.net/index.php?topic=4017) Unclear. Mapview load times vary quite a bit on lab2 between successive loads.

Is there other information you'd want to see on those pages?
How about splitting tables across multiple pages for large regions? Think Kentucky, or Texas (esp. if usatxf & usatxr ever see light of day). I know CHM did this for hb/selecthwys.php, but I forget about userpages.
This is nothing I care about much one way or the other, but maybe other have an opinion on this.

Jim, ISTR you posted in the last couple days about changing some MySQL settings and getting faster load times (on findroute?) but I can't find the thread. Got a link? What did you change?
Title: Re: region.php and system.php
Post by: michih on December 31, 2020, 03:10:38 am
I think it might be better to have it on separate pages -- CHM called them travregion.php & travsystem.php IIRC.

That's basically the very same idea I mentioned. You can load the pages in different browser tabs. Less comfortable but simpler to implement.
Title: Re: region.php and system.php
Post by: bejacob on December 31, 2020, 10:02:41 am
I tend to ignore the map when looking at the region.php page. I use all the existing tables depending on what info I'm seeking at any given time, but will open a separate mapview.php tab for the same region and switch back and forth as needed. On the system.php page, I tend to look at the map a little more, but since there is an option to click "View Larger Map" at the top of the page, I think it may better to ignore the map at the top of the page too. The wait time to load a large system or region in mapview isn't really a concern for me. It takes as long as it takes (which so far hasn't been too long). Having a link that will open the mapview with the system or region would be good enough for me instead of having the map load in the frame a the top. That would save a few steps to open another browser tab and find the region/system map I want (which is what I usually do now anyway).

In both the region and system pages, the most important thing for me is to find out which routes I'm closest to clinching or haven't driven at all. The map at the top of the page doesn't help much with that.

I'll have to give a bit more thought as to whether there is additional info that might be useful on either page. Nothing immediately comes to mind.
Title: Re: region.php and system.php
Post by: Jim on December 31, 2020, 10:52:32 am
Jim, ISTR you posted in the last couple days about changing some MySQL settings and getting faster load times (on findroute?) but I can't find the thread. Got a link? What did you change?

Within the last month, I turned off some logging that was resulting in a large DB table I was never going to look at and taking up valuable space on the /var partition.
Title: Re: region.php and system.php
Post by: yakra on December 31, 2020, 12:08:26 pm
Within the last month, I turned off some logging that was resulting in a large DB table I was never going to look at and taking up valuable space on the /var partition.
It's probably something I don't need either. What setting was it?
Title: Re: region.php and system.php
Post by: Jim on December 31, 2020, 06:08:57 pm
Within the last month, I turned off some logging that was resulting in a large DB table I was never going to look at and taking up valuable space on the /var partition.
It's probably something I don't need either. What setting was it?

I set slow-query-log to 0 in my.cnf.  The table it created was several GB in size.

There are probably other settings to be optimized in there based on TM's usage patterns.
Title: Re: region.php and system.php
Post by: vdeane on December 31, 2020, 09:41:10 pm
It's been enough years since I've looked at CHM that I can't remember how it was laid out. ISTR the map .gifs (generated by PHP) being 700x700 and that's about it.
I was almost thinking something along the lines of frames or iframes or divs  or however it's done, to keep the map in place while the user scrolls around the table(s), but...
Keeping the map its current height would leave little to no room below for the table.
I'm unsure how practicable displaying map & table side-by-side would be, especially for those running lower resolutions. I was at 1280x960 for many years.
I don't have a good solution to offer. Maybe CHM worked as TM does now, where we would just scroll the map off the top of the screen.
CHM only required the map to be scrolled past once it was displayed.  There was a drop-down for which map to display (as the CHM maps couldn't be zoomed in or out, one had to select between the statewide map and closer-in maps from around the region).

I like the idea of using a check-box to show/hide the map, but maybe that's a bit much?  When michih proposed his tabs, I was originally thinking switching what was displayed with JavaScript, but it seems that he's actually envisioning separate pages.

Yeah, displaying it sideways wouldn't work, unless the CSS was responsive enough to be able to switch to the current view if there isn't a certain width available (FYI, the resolution on my desktop (Antares) is "only" 1600 x 900, and I don't keep Chrome maximized, either; my laptop (Vista) has more room with 1920 x 1080).

Quote
Comparing loading times between region.php & mapview.php for a couple large states, the newer mapview code loads a lot faster. (More efficient SQL queries?) It'd be nice to similarly improve region.php.
Mapview does redline one CPU core on my client machine the entire time it's loading, whereas region.php just has a short burst of activity after the data comes over the network and it renders the map & table.
If we could get the faster loading times along without all the CPU use, that'd be gravy. (Or is the CPU use a necessary side effect of JSON/AJAX?) If we can't have that, then I'll take the faster load times of course.
Any performance improvement from using MySQL 8.0? (https://forum.travelmapping.net/index.php?topic=4017) Unclear. Mapview load times vary quite a bit on lab2 between successive loads.
Interesting.  I wonder when that happened.  I remember Mapview taking a significantly longer time than region/system for everything, so I've been avoiding unless I wanted to use the color by traveler count feature or the scrollable version.  I did some tests today for various regions/systems and put the results below (the results are the same for both Antares and Vista, at least for NY; I didn't feel the need to re-run everything, and quite frankly, I have no desire to ever load usaus in mapview ever again).

Code: [Select]
KY R - 1m 15s
KY M - 31s
NY R - 17s
NY M - 10s
DC R - 2s
DC M - 1s

usaus S - 15s
usaus M - 8m 18s
usai S - 10s
usai M - 50s
usaky S - 2s
usaky M - 20s
usany S - 2s
usany M - 5s
canqca S - 0s
canqca M - 1s

Looks like region is now significantly faster in mapview, but system is still significantly slower.  Given how long it takes to load usai and especially usaus (which resulted in multiple Chrome popups asking me to kill the page (!)), I do not think it would be a good idea to remove maps from system at this time.

I also decided to do a test on my phone.  NY took 1m 45s to load with Mapview and only 24s to load with region.  Given this, and that Mapview isn't exactly phone accessible (not that TM as a whole is, but Mapview is especially bad), it would be a good idea for the maps to remain in region as well.
Title: Re: region.php and system.php
Post by: SSOWorld on January 01, 2021, 10:42:33 am
I agree on phone accessibility of MapView - yet it turned out handy in phone Chrome so I could "hover" on it to see where I am with the route (without killing myself that is ;) )
Title: Re: region.php and system.php
Post by: yakra on January 01, 2021, 11:41:59 am
Odd that there would be such a time difference on a phone. Different browsers' JSON implementations, or something?

Interesting.  I wonder when that happened.
Surely with the scrollable version.

Looks like region is now significantly faster in mapview, but system is still significantly slower.
Never thought to check system. Interesting. I only had the patience to try to duplicate your results with usai, but indeed I did.

With system so much faster than mapview, this suggests there are still some more efficiency gains to be had.

Longer term, maybe some new database tables could speed up loading times, and cut down on the # of JOINs.
Or maybe indexes to speed things up; aren't some of those used already?
Title: Re: region.php and system.php
Post by: Jim on January 01, 2021, 11:50:38 am
I think there is a lot of room for DB improvements, in the design of the tables, adding things like more indexes, configuration and hardware improvements on the server, and rewriting queries to run more efficiently.  I keep hoping someone with more expertise than me in databases will take interest in the project and tell us what we're doing poorly, or better yet, implement some fixes!
Title: Re: region.php and system.php
Post by: osu-lsu on January 01, 2021, 02:21:37 pm
I know of a "roadgeek" that works for Google (or Alphabet) out in California. Jimmy (James) Lin has been part of the crew assembling the digital Lincoln Highway map, for the LHA, over the last decade. I'd be willing to reach out and see if he be interesting in helping out here.
Title: Re: region.php and system.php
Post by: vdeane on January 02, 2021, 05:54:07 pm
Interesting.  I wonder when that happened.
Surely with the scrollable version.
I think Mapview was comparable to region/system before the scrollable version, which initially slowed things way down, but there might have been efficiency improvements since then.
Title: Re: region.php and system.php
Post by: vdeane on February 07, 2021, 06:10:52 pm
Given the recent change to top stats, perhaps another idea would be to add shields to region and system like CHM had?
Title: Re: region.php and system.php
Post by: Jim on February 07, 2021, 10:05:18 pm
Given the recent change to top stats, perhaps another idea would be to add shields to region and system like CHM had?

Yes, that would be good.  Those pages need some work, so I've added this idea to an existing Issue: https://github.com/TravelMapping/Web/issues/574
Title: Re: region.php and system.php
Post by: formulanone on June 18, 2021, 10:01:10 am
Would it be possible to create an anchor at the statistics, so that when one clicks/selects the "Overall ___ Region Statistics", it will go right to the "Travelers in Region ___" section?
Title: Re: region.php and system.php
Post by: Jim on June 18, 2021, 10:36:12 am
Would it be possible to create an anchor at the statistics, so that when one clicks/selects the "Overall ___ Region Statistics", it will go right to the "Travelers in Region ___" section?

Sounds easy enough.  I want to make sure I'm understanding what you're suggesting.  What page would have the link and where, and what page would have the anchor/target?
Title: Re: region.php and system.php
Post by: michih on June 18, 2021, 01:19:57 pm
Would it be possible to create an anchor at the statistics, so that when one clicks/selects the "Overall ___ Region Statistics", it will go right to the "Travelers in Region ___" section?

Sounds easy enough.  I want to make sure I'm understanding what you're suggesting.  What page would have the link and where, and what page would have the anchor/target?

region.php has five paragraphs:
- Region map
- Overall Region Stats
- Stats by System
- Stats by Route
- Travelers in Region

I think @formulanone is talking about a direct link from https://travelmapping.net/user/ "Stats by Region" table to "Travelers in Region" of region.php.

I'd prefer an index on top of region.php with direct links to the paragraphs or a reorganization of region.php + system.php as suggested upthread.

For instance:

I'd like to have kinda "tabs" for a quick jump to the desired table:
user/region.php: Overall region stats / stats per system | Stats by Route | Travelers in Region
user/system.php: System stats / stats per region | Stats by Route | Travelers in System (new)
user: Overall stats / Links | Travelers in continent (new) | Travelers in country (new) | Stats by region | Stats by system

The first "tab" should always be visible when the page is reloaded.

The link to the map could be on top next to user + units (+ system + region) selection which should always be visible independent of the "tab".

The "tab" is just a more complicated way to implement an index on top but it can also be used to jump back.

Note that the Travelers by System table is still missing. I think it is the most wanted feature....

My top priority for web front end is:

#97

It was mentioned earlier in the thread that rankings by system don't exist. Is this new? If so, it would be nice to see the individuals listed at the end of the page similar to the rankings by region. Or is this a programming/display issue?

It is a programming issue. The table was never implemented. There is already an issue in the backlog: Web #97 List of travelers who have traveled a system (https://github.com/TravelMapping/Web/issues/97).

If we really wanna improve anything for travelers by region, we should do the very same for travelers by system. Just my 2ct.
Title: Re: region.php and system.php
Post by: Jim on June 18, 2021, 01:55:09 pm
If any of the specific ideas here aren't already in GitHub Issues in the TravelMapping/Web repository, it would be very helpful to get them in.  That's where I'll most easily find them.
Title: Re: region.php and system.php
Post by: michih on June 18, 2021, 03:20:20 pm
If any of the specific ideas here aren't already in GitHub Issues in the TravelMapping/Web repository, it would be very helpful to get them in.  That's where I'll most easily find them.

I think that the basic issue is #574 Update region.php and system.php (https://github.com/TravelMapping/Web/issues/574)

Related to some extent:
- #97 List of travelers who have traveled a system (https://github.com/TravelMapping/Web/issues/97)
- #54 multi-region countries and continents stats (https://github.com/TravelMapping/Web/issues/54)

@ALL: Feel free to add ideas and suggestions.
Title: Re: region.php and system.php
Post by: theFXexpert on June 20, 2021, 10:34:46 am
Would it make sense for the links in the route table for system.php to go to the showroute page of the connected route instead of mapview so it's consistent with region.php behavior?
Title: Re: region.php and system.php
Post by: yakra on June 20, 2021, 07:37:01 pm
Would it make sense for the links in the route table for system.php to go to the showroute page of the connected route instead of mapview so it's consistent with region.php behavior?
I think so, yeah. Maybe system.php links to mapview because that was implemented before ConnectedRoutes in the HB were?
Title: Re: region.php and system.php
Post by: yakra on June 20, 2021, 11:33:59 pm
Note that the Travelers by System table is still missing. I think it is the most wanted feature....

My top priority for web front end is:

#97

It was mentioned earlier in the thread that rankings by system don't exist. Is this new? If so, it would be nice to see the individuals listed at the end of the page similar to the rankings by region. Or is this a programming/display issue?

It is a programming issue. The table was never implemented. There is already an issue in the backlog: Web #97 List of travelers who have traveled a system (https://github.com/TravelMapping/Web/issues/97).
The programming issue being that the programmers never got around to programming it. ;) Rectified:
https://tmstage.teresco.org/user/region.php?u=formulanone&rg=ME
https://tmstage.teresco.org/user/system.php?u=formulanone&sys=usame

Also included:
• anchor as requested by formulanone
• rank numbers like CHM used to have (http://web.archive.org/web/20160422033800/http://cmap.m-plex.com/stat/travsystem.php?sys=deua)

Comments, thoughts?

I like the idea of having separate "travregion" & "travsystem" pages like CHM used to. Open to discussion there; this was just quick to get going by adapting the code region.php already had.
Title: Re: region.php and system.php
Post by: michih on June 21, 2021, 11:38:51 am
Comments, thoughts?

Well, fine. The anchor is just an anchor (you can specific #rankings in the url) but it is not yet called, no index etc. No need for thoughts. The new table is great :)

I found a little misbehavior with the new system traveler ranking table: https://github.com/TravelMapping/Web/issues/97#issuecomment-865131575
Title: Re: region.php and system.php
Post by: yakra on June 21, 2021, 12:23:00 pm
The link to the anchor is in the header of the anchor is the first table, which I believe is what formulanone asked for.
May not be the most intuitive or best from a UI standpoint, the the philosophy was get-something-better-than-nothing-in-there, and think about more streamlined longer-term options in the future. :)

• rank numbers like CHM used to have (http://web.archive.org/web/20160422033800/http://cmap.m-plex.com/stat/travsystem.php?sys=deua)
http://tmstage.teresco.org/user/system.php?u=froggie&sys=usame&rg=NH#rankings
https://tmstage.teresco.org/user/region.php?u=froggie&rg=DC#rankings
In case of ties, Rank numbers don't match what's in the first table up top. Should be an easy fix.
Edit: Fix is live on lab2.
Title: Re: region.php and system.php
Post by: formulanone on June 21, 2021, 05:32:49 pm
Would it be possible to create an anchor at the statistics, so that when one clicks/selects the "Overall ___ Region Statistics", it will go right to the "Travelers in Region ___" section?

Sounds easy enough.  I want to make sure I'm understanding what you're suggesting.  What page would have the link and where, and what page would have the anchor/target?

I think yakra figured out what I meant - I can't find the thread, but CharlotteAllisonCDTG was looking for a way to quickly get to "all user's stats in that region", and I figured a link to the bottom of the page would be a nice feature. Sort of like an anchor tag within a webpage; click it, and it jumps past all of the routes, and right to the stats on the same loaded page. 

The header seemed to be the most intuitive place to put it, since the other two options link to a clinched route page or an in-system route page.
Title: Re: region.php and system.php
Post by: yakra on June 21, 2021, 08:02:37 pm
I believe your post was moved from here (https://forum.travelmapping.net/index.php?topic=4407.msg24322#msg24322) to here (https://forum.travelmapping.net/index.php?topic=4019.msg24319#msg24319).
Title: Re: region.php and system.php
Post by: michih on June 25, 2021, 12:01:58 pm
http://tmstage.teresco.org/user/system.php?u=froggie&sys=usame&rg=NH#rankings
https://tmstage.teresco.org/user/region.php?u=froggie&rg=DC#rankings

Live on the production server now:
Example: https://travelmapping.net/user/system.php?u=froggie&sys=usame&rg=NH#rankings