A Google search for "filemaker wan optimization" should provide some possible solutions
e.g. avoid "wide" tables, summary fields, and unstored calcs
> When I test these layouts on my design computer they work well but when accessed remotely over the internet, these list layouts are very unresponsive when a user scrolls the list
Greg's suggestions are good. Also try to avoid sorting (because the entire found set has to be downloaded); use lightweight graphics (small size, few colors); and watch out for payload associated with the interface (like Conditional Formatting).
Regarding avoiding wide tables and unstored calcs, specifically:
For list views, scrolling requires full record caching across the WAN in large groups of records to support the scrolled screen refresh.
If you can split your table to contain only the fields which appear in the list views (plus the primary Key field), and stick the rest of the fields in a 1-to-1 related table, only the fields which actually appear will be cached.
Similarly, try to use fully-stored values. If you have unstored calcs, convert them to stored values using script triggers to update them as the data changes elsewhere, not in the list view.
That will give you a table of nothing but stored fields which is virtually limited to the fields in the list. Refreshes will be significantly faster to both LAN and WAN clients.
Have you tried a portal instead of list view to see if that either (a) is any quicker, or (b) gives you more contol options?
If you develop your solutions on the LAN and your users are all on the WAN you have no idea what their experience is. Try doing some development work on the WAN and you’ll soon think that improving UI performance has a higher priority than eye-candy gimmicks. Most importantly you’ll see where the real bottlenecks are. If you can't test the behaviour of your solution in real world conditions you can emulate them. On the mac I use a tool called “Speed Limit” which allows me to shape traffic on a port. I can drop the connection speed to 3G if I really want to suffer.
Data transfer is the killer. In list view, consider going to list view in find mode and expecting the users to search for the records that they want to use. An alternative is doing a show all, omit all to produce an empty found set.
FileMaker portals are live and continually trying to update. In some ways this is wonderful, but in other ways, it can make the user interface unresponsive, especially over the WAN. To make them more responsive, I use a global variable array that I make with ExecuteSQL and "Perform on Server". The related table is an array table with no data, only calculation fields that look at the array. Since no data is stored in FileMaker and it is all pulled by calculations from the global variable array, it is much more responsive. Additionally, it does not have to update related data because the global variable array is not changing. This is a bit of pain to implement, but really improves performance over the WAN.