Ok, since this has come up before, let me address this in more depth for the "lurker's benefit", also.
The current layout *was* updated in version 2.20. Not so much visibly updated much to most user's eyes, but much of the underlying code was updated considerably to allow easier maintenance and make it easier to add features in the future.
At its core, FreeToastHost was designed as and is essentially a desktop based system. That means that much of the layout is a fixed layout. "Mobile first" design was not in vogue back when the system was created and I was not involved at that time.
I *am* interested in updating the layout to be more adaptable, but based on what I know about the underlying code, it is going to be a good chunk of my time to get it right. Frequently, it has been a case with the FreeToastHost code that I have had to go back and gut the underlying code that is the weak foundation of the system to enable me to make the system more stable and viable for the long run (and also allow adding features). It is like trying to add another room to a house when the foundation is weak. This is another reason it is taking so long to get certain things added.
The system will never be WordPress or a bootstrap based system (for those that are familiar with bootstrap), because FreeToastHost is intended to be much more than just a page layout system. (layout + agendas, email, dues, etc.)
However, we can learn things from responsive layout based systems that can be applied to FreeToastHost in many cases. We can do some screen tweaking for different screen widths, for example. (I am reviewing a style sheet for responsive layouts called skeleton.css.)
Here is the caveat, though. What is fundamentally different about FreeToastHost from many of the other systems that people will cite as examples is that FreeToastHost is essentially a
content management system targeted to be useful to users with little or no website development experience. Because of this, while I may be able to make a template screen layout that will adjust to varying screen widths, I cannot expect most user's content to fall in line with that. That means that while I can make the template adjust to varying screen sizes, users will frequently use fixed pixel sizes for images in their content which will prevent said adjustment, because the third party editor we use defaults to fixed pixel sizes. Thus, even if I set the % width of the big content area on the right, if users put a full width picture in the content sized in pixels, then the width
will not adjust. I could just push responsibility for this back on users to fix, but many users will not want to fiddle with it. What I will probably do in the future is create a class name ("fluid" or "responsive") that users can apply to their content as a way to "opt in" to having my code massage their content to force it to adjust for varying screen widths. However, that code has yet to be created.
Nothing worthwhile is ever easy.

I would like to be able to say, "Oh yeah, I will have that done next week.", but hopefully, you can understand some of the issues that I will need to address to get this right.