Highway Browser Design

[michih]

• Some or all of the listing part probably can be replaced with the current region.php and system.php pages, either as-is or with some enhancements.  Interested in opinions on this. I would not miss our current ugly lists.

Replaced? Unless I'm missing something, I don't like this -- region.php and system.php are for user stats, and should remain focused on that function. Searching & filtering routes to browse should be something distinct from that.

region.php already has a "HB" column (which is called "Map" ). I think it's pretty fine to open the HB this way instead of using the superfluous HB list.

system.php opens the route in mapview and you can open the HB route. If mapview would directly be a kind of HB..... that would be pretty perfect too!

The issue is that region.php and system.php can only be opened (by clicks, not talking about url manipulation as I always do) from the user page and only for the desired region or system if you already have some mileage there. This is the only reason why one currently needs to go via HB. If this issue could be solved, so that you can even open routes without previous user selction (that means what NEW users would do), I would be very happy to get rid off the current HB section lists!

Let's get rid off:
- https://travelmapping.net/hb/
- https://travelmapping.net/hb/index.php?sys=alba

[yakra]

That would be, like, some Microsoftian kind of unnecessary change just for the sake of change.
Which would make the site less intuitive & navigable.

If we got rid of https://travelmapping.net/hb/, then what would we link to from the header panel?
Travelers are most likely used to having that link, and many probably surf straight there to start looking at routes.

Issues with region.php & system.php include how a bunch of real estate is taken up at the top of the page by the map, and there's a bunch of extraneous info about a user's stats. Why not have a clean page of just a table of routes that a user is searching for, as we have it now? The table we have now does a good job of showing what's available without too much extra cruft.

I think it's pretty fine to open the HB this way instead of

This is certainly true.
But simply because one method of opening a route works, why should we remove another, arguably better, method?

If this issue could be solved, so that you can even open routes without previous user selction (that means what NEW users would do)

Which is one thing the HB is for.

[vdeane]

Idea: perhaps we could retain the HB index but move route display to region and system?  If something like that were to be done, there could be a URL argument and/or checkbox(es) to enable/disable the map and/or stats, and the HB index could have a flag that allows one to browse by either system or region.

On another note, I think it's interesting that we're now arguing about whether to keep the HB given that the HB actually pre-dates both TM and CHM.  The entire project was originally just the HB for usai, an "interstate highway browser" that Tim posted to MTR one day.

[michih]

The table we have now does a good job of showing what's available without too much extra cruft.

I cannot open mapview for a region I've not yet traveled. That's how I plan trips in advance. It's only possible by editing the url.

[yakra]

I was referring specifically to the HB there.

[Jim]

I cannot open mapview for a region I've not yet traveled. That's how I plan trips in advance. It's only possible by editing the url.

With the change that just went live on the main site, you can get to any region in Mapview through the popup that previously only supported giving a start location.

[michih]

I cannot open mapview for a region I've not yet traveled. That's how I plan trips in advance. It's only possible by editing the url.

With the change that just went live on the main site, you can get to any region in Mapview through the popup that previously only supported giving a start location.

True! Should we add it to the TM header?

btw: I don't say that we should but only that we could eliminate the HB since the mapview popup has the very same selection option. Only system status info (active, preview, devel) is missing.

[Jim]

I've decided I can put a little time into an HB redesign this week.

One change from above, I'm making r= a required QS param, and cr an optional one.  You always would provide any TM root for r=, and if cr (no "=", like Mapview's v QS param) is also specified, the entire connected route with that (chopped) root is displayed.

I am thinking a single chopped route view will include a button or link to expand to the whole connected route (if it's more than just that one chopped route), and a connected route will have links within the page to restrict to an individual chopped route.

[yakra]

Making sure I parsed that properly...
https://travelmapping.net/hb/?r=me.me113
https://travelmapping.net/hb/?r=me.me113&cr
Yes?

[Jim]

Making sure I parsed that properly...
https://travelmapping.net/hb/?r=me.me113
https://travelmapping.net/hb/?r=me.me113&cr
Yes?

Yes.  I could also go with the original r= and cr=, one of which would be required, but this simplifies things a bit, at least from the coding side.

[yakra]

I agree that it simplifies things. No need to worry about how to handle both r= & cr= in the same URL, for example.
I have no problems with this syntax.

[vdeane]

I've noticed that now that HB windows have "mark current location", at the size I keep Chrome the top bar spills over into a second line, which is partially cut off.  It looks like there should still be room for everything without changing the map size if the text were moved up a little closer to the top.

[Jim]

I've noticed that now that HB windows have "mark current location", at the size I keep Chrome the top bar spills over into a second line, which is partially cut off.  It looks like there should still be room for everything without changing the map size if the text were moved up a little closer to the top.

I did a little tweaking of positions and font sizes on the new tmtest version.  See what you think.

[vdeane]

It still does that, but I do like the new font sizing in any case.  For what it's worth, I have Chrome at a width where the tabs are full-size only if there are three or fewer (not for that reason, just an easy way to measure for this thread) when not maximized, if that would make testing easier.

[Jim]

It still does that, but I do like the new font sizing in any case.  For what it's worth, I have Chrome at a width where the tabs are full-size only if there are three or fewer (not for that reason, just an easy way to measure for this thread) when not maximized, if that would make testing easier.

You hit on a site-wide problem, where we have long had many absolute positions and sizes for things that do not work well when pages are viewed on different size screens.