6 Replies Latest reply on Jun 12, 2014 10:02 PM by taylorsharpe

    What's the best cure for unresponsive lists

    jmci

      Every project on which I've worked over the last two years has been required to be accessed remotely. I often have to design list layouts that contain one or more fields from related tables. 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. The user will often have to sit for several seconds watching a beachball after every attempt to scroll. I have come up with several work-arounds for this problem but I'm not happy with any of them. What's the best solution?

       

      jmci

        • 1. Re: What's the best cure for unresponsive lists
          gdurniak

          A Google search for "filemaker wan optimization" should provide some possible solutions

           

          e.g. avoid "wide" tables, summary fields, and unstored calcs

           

          greg

           

          > 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

          • 2. Re: What's the best cure for unresponsive lists
            Mike_Mitchell

            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).

            • 3. Re: What's the best cure for unresponsive lists
              Stephen Huston

              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.

              • 4. Re: What's the best cure for unresponsive lists
                keywords

                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?

                • 5. Re: What's the best cure for unresponsive lists
                  Malcolm

                  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.

                  • 6. Re: What's the best cure for unresponsive lists
                    taylorsharpe

                    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.