TfW Rail web site doesn't like being resized

[AdamWW]

I was buying a ticket on the TfW Rail web site this morning and just before paying I resized my browser window - at which point I discovered that doing this wipes out all the progress and sends you back to the search screen.

I experimented with two different browsers and they both did this, and checked on a couple of other train company sites that they didn't do this, so it's not obviously some pathology at my end.

It's not something I've been aware of on any other web site.

I don't do web programming - does anyone know what the advantages are of having it work like this? I found it a bit annoying.

 

[gazthomas]

I originally read this as "TfW doesn't like being used". That's my experience, buggy and often won't process card payments.

 

[Lewisham2221]

I was buying a ticket on the TfW Rail web site this morning and just before paying I resized my browser window - at which point I discovered that doing this wipes out all the progress and sends you back to the search screen.

I experimented with two different browsers and they both did this, and checked on a couple of other train company sites that they didn't do this, so it's not obviously some pathology at my end.

It's not something I've been aware of on any other web site.

I don't do web programming - does anyone know what the advantages are of having it work like this? I found it a bit annoying.

Yeah, that's not great!

Looks like the journey planner is a separate application, embedded in the web page, rather than being part of the page itself, if that makes sense. The app appears to load and fit to the available space, rather than being dynamically resizable in the way that a normal web page is. Changing the size of the window forces the embedded journey planner to reload to fit the new available space. Very annoying! No idea what the advantages are, especially if nobody else is doing it. Possibly just allows them to have one journey planner application that can be embedded anywhere (more techy types, does that even make sense?). I note that if you resize the window to the right proportions, the website journey planner appears almost identical to the TfW app

 

[AdamWW]

Looks like the journey planner is a separate application, embedded in the web page, rather than being part of the page itself, if that makes sense. The app appears to load and fit to the available space, rather than being dynamically resizable in the way that a normal web page is. Changing the size of the window forces the embedded journey planner to reload to fit the new available space.

It does, and that does make sense.

I can imagine someone not thinking to specify "Doesn't break if someone resizes the screen at the wrong time" (I doubt I would).

And then it would presumably not look good to warn people when using it that they must keep the window the same size until they're done.

I note that if you resize the window to the right proportions, the website journey planner appears almost identical to the TfW app

It certainly gives me the impression that it's designed to be used on a phone.

 

[Stephen42]

I don't do web programming - does anyone know what the advantages are of having it work like this? I found it a bit annoying.

There are two basic approaches to sizing content, styled and scripted. Styled or stylesheets is where the developer provides style rules which the browser applies to fit content into the space. Scripted is where code written by the developer locally runs in the browser decides the size and positioning based on the size available. A combination of the two can also be used. Most websites these days predominately use stylesheets for the appearance of content.

Styled will respond immediately and naturally to resizing a browser refitting as the size changes, possibly with some content reformatting/appearing/disappearing at certain sizes. Scripting for sizing will often have a brief period of looking wrong until the script runs to resize and reformat the content to the new size.

Scripting is sometimes essential, if a button changes what content is to be shown that either is going to a new web page or a script running. A flow on a small screen might prefer multiple steps rather than one step involving a lot of scrolling. On the flip side it's then on the developer to work out what and how to carry across what was previously entered if size changes. Troubleshooting issues can also be more complicated as different scripts might have run for what appears to be similar activity. Stylesheets on the other hand are more predictable as will always be the same for the same content, though can be fiddly as different browsers can interpret rules a bit differently.

The TfW website looks unusually bad. Even when into the ticket flow proper and out of the embedded frame the site appears to significantly reload on resize. Many websites can have slightly odd behaviour when menus/navigation are open while resizing as most will use both styling and scripting. e.g. For me on National Rail Enquiries starting wide, resizing to be narrow and opening the navigation menu top left, then resizing larger will restore what was previously shown. However, the ability to scroll down is lost and requires a refresh or sizing smaller then exiting the menu before resizing.

 

[AdamWW]

The TfW website looks unusually bad. Even when into the ticket flow proper and out of the embedded frame the site appears to significantly reload on resize. Many websites can have slightly odd behaviour when menus/navigation are open while resizing as most will use both styling and scripting. e.g. For me on National Rail Enquiries starting wide, resizing to be narrow and opening the navigation menu top left, then resizing larger will restore what was previously shown. However, the ability to scroll down is lost and requires a refresh or sizing smaller then exiting the menu before resizing.

Informative. Thanks.

The impression I've got is that even when using it on a large window, it looks as if it's designed to be used conveniently on a phone screen.

== Doublepost prevention - post automatically merged: 15 Mar 2026 ==

e.g. For me on National Rail Enquiries starting wide, resizing to be narrow and opening the navigation menu top left, then resizing larger will restore what was previously shown. However, the ability to scroll down is lost and requires a refresh or sizing smaller then exiting the menu before resizing.

I find the NRE web site somewhat buggy, for example breaking if I use page back, unlike most modern web sites.

 

[Stephen42]

Informative. Thanks.

The impression I've got is that even when using it on a large window, it looks as if it's designed to be used conveniently on a phone screen.

Most websites will track (for those who consent) what type of device, browser and screen resolutions of the user. It's common for people to use websites on phones even if a company offers an app.

The large share of mobile often leads to "mobile first" design. The mobile screens are worked out first as that's where screen real estate is most constrained. Then separately the designer produces a desktop version or multiple larger sizes. The share of device use, budget available and relative priorities will make a big difference how well the desktop experience is crafted to take advantage of the larger space. Tablets can have high resolutions but have lower touch accuracy than a mouse plus accessibility concerns can also end up with buttons feeling bigger than they need to be. It can be the case that the concerns around that led to poor design or accessibility for other reasons.

I find the NRE web site somewhat buggy, for example breaking if I use page back, unlike most modern web sites.

Will generally be the more buggy ones with issues on resize. Most of the issues are usually not that difficult to fix. The TfW example might be harder if it's two different versions of the site picked between with a script at an early stage.

 

[cats_five]

Most websites will track (for those who consent) what type of device, browser and screen resolutions of the user. It's common for people to use websites on phones even if a company offers an app.

The large share of mobile often leads to "mobile first" design. The mobile screens are worked out first as that's where screen real estate is most constrained. Then separately the designer produces a desktop version or multiple larger sizes. The share of device use, budget available and relative priorities will make a big difference how well the desktop experience is crafted to take advantage of the larger space. Tablets can have high resolutions but have lower touch accuracy than a mouse plus accessibility concerns can also end up with buttons feeling bigger than they need to be. It can be the case that the concerns around that led to poor design or accessibility for other reasons.

Will generally be the more buggy ones with issues on resize. Most of the issues are usually not that difficult to fix. The TfW example might be harder if it's two different versions of the site picked between with a script at an early stage.

A lot of websites work on a phone without an app - and the proliferation of apps drives me mad. A program on the radio invented a word for it - 'appnausea'. It leads to a huge proliferation of icons on the phone's screen. With the browser typing the first letter or three takes me to the site.

Agree that mobile-first design tends to come first these days. And whilst I don't like the very cramped 'hobby site' layouts from years ago, a lot of sites these days have an awful lot of white space which can be a pain on my laptop. My desktop has larger screens, not sure I use them on my phone or tablet.

 

[AdamWW]

Most websites will track (for those who consent) what type of device, browser and screen resolutions of the user. It's common for people to use websites on phones even if a company offers an app.

The large share of mobile often leads to "mobile first" design. The mobile screens are worked out first as that's where screen real estate is most constrained. Then separately the designer produces a desktop version or multiple larger sizes. The share of device use, budget available and relative priorities will make a big difference how well the desktop experience is crafted to take advantage of the larger space.

In places the TfW web site on a computer feels to me more like "mobile only" than "mobile first".

TfW make a lot of decisions which no doubt have their reasons but which I cannot understand.