1 2 Previous Next 27 Replies Latest reply on May 9, 2017 6:00 AM by howardh

    Themes and Styles...what road to take...

    TonyWhite

      Hi All,

      Themes and Styles are a powerful and complex feature. With great power comes great responsibility...

      Good documentation helps developers plan a roadmap through complexity. Here is a Work in Progress “FileMaker Themes history and roadmap” document that others might find useful.

      FileMaker Themes history and roadmap_2016-08-22_v5.png

      If you want a Theme family that supports FileMaker Web Direct, and is NOT deprecated, your choices are:
      * Classic Refined
      * Aspire
      * Minimalist Theme

      The Minimalist theme (introduced in FileMaker 14) has some advantages over the Classic Refined and Aspire families in that the Default Styles are NOT Layout Part dependent. Aspire and Classic Refined on the other hand have (hidden) Styles where if you put a Layout Object in a Header Part it will look different than if you put in a Body Part.

      For this and other reasons, there are advantages to using a Theme from the Minimalist Theme family.

      We, like many other outside consultants, have a variety of clients using FileMaker 13, 14, and 15

      Many of our clients use the Custom themes that we provide.

      Therefore the big question...
      Is is possible and/or is there a downside to using a Custom Theme that is based on Minimalist and deploying to a client that is currently on FileMaker 13?

      Comments and corrections welcome.

      Thanks.

      All the best,


      Tony White

        • 1. Re: Themes and Styles...what road to take...
          beverly

          Good question, Tony! I prefer Minimalist for the reason you stated, especially as a basis for custom themes (to match corporate styles). I have not tested results in FM 13 only with FM 14 & FM 15.

           

          beverly

          1 of 1 people found this helpful
          • 2. Re: Themes and Styles...what road to take...
            AllegroDataSolutions

            Surprised to see so few comments to this. We should know a lot more about themes by now. The most important question to me, and my clients, is what affect a theme will have on performance.

             

            The last I heard was that themes with unsaved styles will take longer to load. I'd like to know whether this is only true when a solution is accessed through WebDirect, or whether it also affects WAN and/or LAN performance.

             

            I've heard claims that customized themes take longer to load than unmodified ones. If true, I'm not sure how that affects custom themes made from scratch. (Is the performance hit even greater).

             

            Finally, if unmodified themes supplied with FMP always give the best performance, I can't think of a single client who would want me to use anything but one of them in their solutions. And with more of them being deprecated with each release, that potentially means less choice. (As much as all the neat UI stuff you can do with FM attracts clients, in the end, performance matters overwhelmingly more to them than anything else.)

            • 3. Re: Themes and Styles...what road to take...
              philmodjunk

              The last I heard was that themes with unsaved styles will take longer to load. I'd like to know whether this is only true when a solution is accessed through WebDirect, or whether it also affects WAN and/or LAN performance.

              IT affects WAN and LAN too, but LAN is fast enough that you can't normally perceive the difference due to this.

              • 4. Re: Themes and Styles...what road to take...
                AllegroDataSolutions

                I'd really like to know how custom and customized themes affect performance. If the prebuilt themes are always going to load faster, those are what my clients are going to want me to use. No one wants to pay more for me to design a beautiful UI, using all the new tools available in FMP, if the trade off is slower performance.

                • 5. Re: Themes and Styles...what road to take...
                  William-Porter

                  I too would like to see more discussion in this thread. Interesting and important topic!

                   

                  My ha'penny: I dislike FileMaker's "professionally designed" styles. I think they all look like they were professionally designed circa 2007. So I start with Minimalist, save as new style, and roll my own by way of modifications and additions. I can't say that my own styles are beautiful. I just find them less off-putting personally than FileMaker's.

                   

                  It seems to me that styles in FileMaker are a mixed blessing. Even in the 1980s I was a believer in paragraph styles for word processing, but word processing content is relatively simple compared to a full user-interface built in FileMaker. When I was building websites circa 2000, I was fond of CSS — but the advantage of CSS isn't just the "SS" part but (as with word processing styles at least in certain programs) the "C" part, that is, CSS allows cascading styles or for one element to inherit its formats from another. I understand that under the hood FileMaker styles are basically just CSS, but I don't see how to access the cascading part. For example I'd find it very useful to be able to create a hierarchy of UI elements where child elements are determined by parent elements or parent definitions, with a couple of distinctions.

                   

                  Another problem with FileMaker styles is that I can never use them to do 100% of my formatting. When I was in the academic world and writing books and articles, working in Word, I formatted pretty much everything using styles. I'm sure I had the odd two words of ad hoc italics here and there but my rule was everything is formatted by a style and I stuck to that rule fanatically. But even in a fairly simple FileMaker app, there are just too many types of objects required by the UI for me to format everything purely by styles. In particular, with text objects and buttons, I always start with a style but then apply an ad hoc format like center alignment (if the style's default is left-aligned) and so on. I could create a style for absolutely every distinct object type, e.g.

                   

                  • list field left aligned
                  • list field center aligned
                  • list field left aligned with bold
                  • list field right aligned (for numbers)
                  • list field italics
                  • list field smaller font

                   

                  and so on. But I'd end up with 419 styles in my stylesheet and I would go crazy trying to remember which one to use when.

                   

                  So I use styles very devotedly, but a lot of objects are formatted with a style and then tweaked with an ad hoc format.

                   

                  Finally, as to speed: I've never done any speed tests, but I can't say I notice any performance hit from using styles.

                   

                  Will

                  • 6. Re: Themes and Styles...what road to take...
                    beverly

                    ditto. Not a fan of any of the themes (past, now and future?) except the Minimalist. Bad themes is what led to ThemeCreator™ (1&2) it had Pantone color swatches and the ability to design your own much more easily. The changed the way themes are stored and with reason, these should not be manually changed. We have some control to create custom themes, but it's still not quite there...

                    beverly

                    • 7. Re: Themes and Styles...what road to take...
                      AllegroDataSolutions

                      I need is more specifics:

                       

                      - If I modify a theme, keeping the same number of styles and formatting (i.e. I change the text color or style of some elements), does that reduce performance?  (i.e. Does FMP load the full theme first, then all the changes?)

                       

                      - Is it the number of styles that matters most, or just that customized themes always perform slower?

                       

                      - If I delete styles from a them (if that's even possible) will that improve performance?

                       

                      I'll add my voice to how much I hate the themes and how they are hated by my client. (the fact that themes exist at all, as well as the artistic choices made for the themes that ship with FMP, and that FMI seems to be deprecating more of them with every release). Ditto for how unnecessarily cumbersome it is to work with them. But the real killer is the performance penalty you pay for every little thing -- and how poorly this has been documented.

                      • 8. Re: Themes and Styles...what road to take...
                        PeterDoern

                        During one of the technical sessions at DevCon last year, the engineer (sorry, can't remember his name) likened the network data transfer to a cracker with a bunch of toppings on it. The cracker is the layout/UI layer and the toppings are the data and schema. In other words, even with a bunch of custom styles and such, the amount of data transferred for layout is minimal compared to the rest of the system.

                         

                        Naturally, the more you are able to use object styles that are used across the board instead of individual styles for individual objects, the better but ultimately performance hinges more on architecture than themes and styles.

                        1 of 1 people found this helpful
                        • 9. Re: Themes and Styles...what road to take...
                          William-Porter

                          Allegro,

                           

                          First, the way I understand it — and of course I could be very wrong — a custom theme (saved with a new name) is a new theme, not simply a default theme with overrides. So a newly saved and named custom theme ought to be just as fast as a "factory" theme. Under the hood I gather it's all CSS.

                           

                          But I don't understand why you're so concerned with the question of performance in connection with themes. Have you done any tests  to document what you claim is the performance hit from themes — default or customized? My experience leads me to agree with Peter Doern's comment that "ultimately performance hinges more on architecture than themes and styles." When I feel that things are getting sluggish, it has never occurred to me to blame the styles, since I use them everywhere, and in general my FileMaker apps are satisfactorily responsive. Instead I go looking for a problem with architecture, or I consider using perform-script-on-server, or any number of other techniques for optimization.

                           

                          Will

                          • 10. Re: Themes and Styles...what road to take...
                            AllegroDataSolutions

                            I remember reading somewhere that custom themes are always slower than the originals they were based on. I'm trying to determine whether that is always the case and, if so, what is the best way to deal with it -- short of using the Minimalist theme for everything and ignoring all the neat things you can do to make the solution look nice. If a solution is too slow to fully load or allow users to work at a reasonable pace, clients simply won't use it. And they start to wonder what the benefit is from upgrading from pre fmp12 versions of FMP. On a solution with a big, complex UI (all of it necessary for the client) we are see quite a noticeable hit on performance, even on a WAN. I recently lost a client I had for nearly a decade because of this. (They went back to FMP 11 on the solutions for their regional offices and abandoned FMP altogether for their main database. So, no more development work for me from them -- and they won't be buying any future versions of FMP.)

                            • 11. Re: Themes and Styles...what road to take...
                              William-Porter

                              AllegroDataSolutions wrote:

                               

                              I remember reading somewhere that custom themes are always slower than the originals they were based on. I'm trying to determine whether that is always the case and, if so, what is the best way to deal with it

                               

                              Seems to me first thing to do is get a good answer that first question: are custom themes actually slower. I have never noticed that and I'd like to see if there's any real evidence of it. I cannot think why it would be. Again, as I understand it, these are all basically CSS stylesheets. Make a copy of one stylesheet and apply it, and it'll work like the original at least on the web. As Gertrude Stein said, a stylesheet is a stylesheet is a stylesheet. Of course both Ms Stein and I could be wrong. She's dead and doesn't care but I'd like to know.

                               

                              And I might add a second part to the preliminary question: even if custom stylesheets are slower, how much slower are they? If you have to get out scientific instruments to see the difference, then in practical terms, there's no difference. I have never detected a difference in performance.

                               

                              -- ... If a solution is too slow to fully load or allow users to work at a reasonable pace, clients simply won't use it. ... On a solution with a big, complex UI (all of it necessary for the client) we are see quite a noticeable hit on performance, even on a WAN. ..

                               

                              I agree that if the solution is too slow to be usable, clients won't use it. And I see that your experience has been different than mine. I'm just not sure that stylesheets were really the problem. We all use stylesheets and the rest of us haven't simply been lucky enough to find more patient clients. I'd wonder if something else might have been a factor.

                               

                              Also you say "even on a WAN". Was that a typo for "even on a LAN"? Or did you mean "WAN"? Of course things are almost always slower on a WAN and troubleshooting slow response times on a WAN gets tricky because there are so many other factors to consider.

                               

                              Not trying to argue with your experience here. I'm interested in it. I'm just trying to understand what's really going on.

                               

                              Will

                              • 12. Re: Themes and Styles...what road to take...
                                Mike_Mitchell

                                I think you're a little confused over the performance issues with themes and styles. It isn't custom themes that are the problem; it's the use of custom styling on a layout, independent of the theme.

                                 

                                There are three layers of styling associated with an object on a layout. The first (bottom) layer is the default. Above that is the theme style associated with that object (and state). And above that is the object-specific styling that's been applied (often referred to as "local" styling).

                                 

                                What you want to avoid for performance purposes is too much local styling. It creates another layer of information that FileMaker has to resolve in order to render the object. In addition to that, it's specific to each object, and therefore has to be downloaded and processed for every object (even if they're allegedly styled identically).

                                 

                                The solution is to save all your styling changes back to actual styles, then back to the theme. This allows FileMaker to download the styling information only once, and it can be cached to apply to multiple objects. Also, avoid copying / pasting style from object to object, especially across themes. That always involves local styling, and, in the case of copying across themes, actually flattens all the styling information to the local level on the target object.

                                 

                                (If you're curious how I know these things, they come from a DevCon 2012 session given by Andrew Paulson.)

                                 

                                If you're dealing with pre-12 conversions (which you said you were, in at least some cases), then yes, you may be seeing performance issues if you didn't reskin the application to use the themes. The old way of styling simply doesn't work well with the new layout rendering engine; 12+ winds up being faster than 11 for anything that uses themes, but does suffer somewhat when dealing with legacy solutions.

                                 

                                All that said, if your solution is suffering from performance issues, themes are not typically the first place to look. Solution architecture is usually the first issue. As an example, I'm currently working with a client who sought me out because of performance issues. They were using unstored calculation fields based on ExecuteSQL as the targets for portal filters. Three strikes.

                                 

                                So I would look first at architecture, then at reskinning the application, then making sure all my objects are styled using styles saved back to the parent theme. My experience is that this is the normal "bang for the buck"

                                1 of 1 people found this helpful
                                • 13. Re: Themes and Styles...what road to take...
                                  alquimby

                                  This is a very useful (free) tool for checking layouts: WorkflowData.com | fmXRaySpecs | Columbus Ohio | Specializing in Technology-based Services filemaker applescript data im…

                                   

                                  Once installed, you can open your FileMaker file, go to a layout, select all, and copy. Open fmXRaySpects, hit Clipboard Refresh, and you can see which objects do not conform to the theme.

                                  1 of 1 people found this helpful
                                  • 14. Re: Themes and Styles...what road to take...
                                    TonyWhite

                                    2 off-topic observations:

                                    1. The date of the OP is wrong for some reason. I posted in 2016...before Beverly commented on the post...no time machines were involved ;-)

                                    2. The date "Copyright © 1994-2016", FileMaker, Inc. at the bottom of the Jive page is wrong.

                                     

                                    Tony White

                                    1 2 Previous Next