Web Design Discussion > General Web Design Discussion

region.php and system.php

(1/6) > >>

Jim:
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?

vdeane:
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.

michih:
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".

yakra:

--- Quote from: vdeane on December 30, 2020, 10:18:33 pm ---One thing that's been mentioned on other threads is how region has the list of other travelers and system doesn't.

--- End quote ---
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.


--- Quote from: Jim on December 30, 2020, 08:10:13 pm ---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?

--- End quote ---
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.


--- Quote from: Jim on December 30, 2020, 08:10:13 pm ---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.

--- End 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? Unclear. Mapview load times vary quite a bit on lab2 between successive loads.


--- Quote from: Jim on December 30, 2020, 08:10:13 pm ---Is there other information you'd want to see on those pages?

--- End quote ---
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?

michih:

--- Quote from: yakra on December 31, 2020, 02:56:22 am ---I think it might be better to have it on separate pages -- CHM called them travregion.php & travsystem.php IIRC.
--- End quote ---

That's basically the very same idea I mentioned. You can load the pages in different browser tabs. Less comfortable but simpler to implement.

Navigation

[0] Message Index

[#] Next page

Go to full version