1 2 Previous Next 17 Replies Latest reply on May 12, 2014 7:58 AM by MHaskins

    FM 13 UI/Themes Best Practices


      Hello! I am working on redesigning the interface for an FM12 solution in FM13. My background is UI/graphics and before the major programming begins I was hoping to get feedback from people on best practices as far as layout creation, themes and file performance goes. Im sure each of these below could be their own thread, but if its possible to let me know if I generally “have it right,” that would be great…


      Recreate layout objects in FM 13 for better efficiency.

      Its better to recreate objects rather than convert from FM 12 because lots of baggage will come along with a conversion.


      Manually editing theme css could decrease file size.

      Some developers are editing css via text editors, however its not supported so probably not the best thing to do.


      The theme you start with to customize will affect final file size.

      Avoid Classic/Basic theme, but the others are about the same in terms of file size (Luminous is a tad bigger).


      Create and use saved styles for all layout objects for better efficiency.

      Local styles take longer to process/render while saved theme styles are quicker.


      TIA! And please feel free to add to my list.

        • 1. Re: FM 13 UI/Themes Best Practices

          In response to your thoughts:


          "Recreate layout objects in FM 13 for better efficiency." From what I understand, this would have more emotional than technical value. You can apply new styles to the existing objects and still reap the performance benefit from the styles.


          "Manually editing theme css could decrease file size." Maybe; but, as you guessed, whether or not you should do it is as much a question of how daring you are as what you hope to accomplish. I'd start by opening Manage Themes and removing the ones that aren't being used.


          "The theme you start with to customize will affect final file size." Yes, but creating and using saved styles for any formatting you apply to more than one object is going to accomplish MUCH more for you. I wouldn't worry about it.


          "Create and use saved styles for all layout objects for better efficiency." It isn't that the saved styles render any faster, but that they only have to be sent over the network once per layout or theme, rather than once per layout object.


          To add one more thing that helps make navigating the styles in a theme much easier for other developers, name your styles according to what information the formatting is supposed to represent rather than what the formatting is, i.e. "Caution Button", not "Red Button With White Text".

          • 2. Re: FM 13 UI/Themes Best Practices

            Love that, j! however it might be for other buttons (red-type theme) and not just "caution". But I get what you mean. And is this a function of conditional formatting, rather than "theme"?



            • 3. Re: FM 13 UI/Themes Best Practices

              Thanks for the reply, jbante. And that's a great tip for naming styles-- will definitely remember that since I am working with a number of developers.

              • 4. Re: FM 13 UI/Themes Best Practices

                And is this a function of conditional formatting, rather than "theme"?


                I'm definitely not talking about something that would be a function of conditional formatting, and your counter-point actually helps illustrate my case. Perhaps I should have explicated my example more.


                Suppose we have a layout with 2 buttons: "Delete Record" and "Revert Record", for the sake of argument. For both, we want the user to think twice before performing those actions. We can script some behavior to make sure the user is forced to think about it at least twice, but the visual cue is still worth it. "Caution Button" makes a better label for these than "Red Button With White Text".


                Now suppose most of the rest of our theme is Red anyway, and we have a "Play Cat Video" button on the layout for some action with less severe consequences, and this button has exactly the same formatting as the "Delete Record" and "Revert Record" buttons. Yet the "Play Cat Video" button should still be a separate style, perhaps "Innocuous Button". When we want to change the formatting on all Caution Buttons at once, we probably don't want the Innocuous Buttons to change with them, and vice versa.


                If a developer is thinking about styles in terms of formatting without thinking in terms of what meaning and affordances that formatting should represent, they should probably spend some time learning to be a more thoughtful designer.

                • 5. Re: FM 13 UI/Themes Best Practices

                  I did say I understood but thanks for expounding for those whom might not.


                  -- sent from my iPhone4 --

                  Beverly Voth


                  • 6. Re: FM 13 UI/Themes Best Practices

                    Be very mindful of using the "Format Painter". It tends to create additional custom styles.


                    This video is mainly aimed at WebDirect, however has very important info for general usage of FM as well. https://www.youtube.com/watch?v=zS_8z9B95ic

                    • 7. Re: FM 13 UI/Themes Best Practices

                      Joshua, thanks for the video link and the heads up about Format Painter.

                      • 8. Re: FM 13 UI/Themes Best Practices

                        When using theme styles, I'm of the opinion right now that every element on the layout should be styled, that is, assigned a style.


                        I see a few benefits to this:

                        1. Everything is styled. No local CSS (except for conditional formatting )

                        2. It forces developers to be as concise with our styles as possible on a layout. Does a layout really need 10 different text syles on it? 

                        3. Related to 2, it forces us to use the same styles over and over, giving further consistency to our designs.

                        4. One change to rule them all (all of that style, that is).


                        Now I realize that it may be overkill to create a style for one element that is bold text. I guess maybe a good rule is that if the style is used 2 or more times in the entire solution, go ahead and create a style for it. One bold text element seems okay.


                        I really think #2 and #3 on the above list are the big keys: It really forces us to limit our work to the bare-bones of what will be acceptable by the client. There's no need for 15 different colors on a layout or 12 different sizes of text.


                        I love that we can use styles now like other programs such as word or indesign.  In the latter app, a long document would rarely be written without every piece of text (and picture and graphic) being assigned a style. Filemaker should be the same.

                        • 9. Re: FM 13 UI/Themes Best Practices

                          Jeremy, if we had the "cascading" in CSS, then one would think that the database has a style which applies to the layouts. the layout has a 'style' which applies to objects as well (cascades to them). Then fields could be assigned additional style and/or override the layout style. All objects of the same type should have the same style, but allow conditional formatting styling as needed. "Buttons" could have a style for the Button ( invisible except in layout mode but have the action applied to the object ), a style for the graphic, & a style for the text. Trying to use "local" styles (one per object) is what gets us into trouble with bloat.


                          So, I suppose you're saying the same thing about multiple usage of a 'style' warrants a "saved style" whereas a single usage is ok to not make it part of your "theme".


                          be as concise with our styles as possible





                          • 10. Re: FM 13 UI/Themes Best Practices
                            Mike Duncan

                            It would be helpful if we could have an inspector to see where the styles were applied from. Since you can't assign more than one style, it doesn't make sense to create styles for ALL the different possibilities you might have in a theme (right align, bold; left align, bold; center, bold; etc, etc etc) and it would be just as hard to select that the correct style from a huge list. Much more usable to create your base style and make slight adjustments to it as needed, and only the differences from the base style will be "local" to the object.


                            It is important to understand what part of your style is local, and what part is inherited from the selected style, and it's not apparent in the inspector, but if you assign an object a style, and then (for example) adjust the font size, only the difference in the styling becomes "local".


                            Similarly, styles created from the default style will inherit changes made to the default. I guess you could say that it "cascades" at least some.


                            What I've found is you need to strike a balance between your styles and making slight adjustments to them as needed.

                            • 11. Re: FM 13 UI/Themes Best Practices

                              Jeremy Brown wrote:


                              I love that we can use styles now like other programs such as word or indesign.  In the latter app, a long document would rarely be written without every piece of text (and picture and graphic) being assigned a style. Filemaker should be the same.


                              Great points, Jeremy!

                              As someone who spends more time in InDesign than in FileMaker right now, I'm loving that styles are here. I really hope the next step (v14?) is "nested" styles, like in InDesign, where you can have one main style, then others that are "based on" the first. That would make creating multiple variants much easier. If you want to make a change that is common to a bunch of styles, you just change the "parent" style and all of the "child" styles inherit the changes, yet keep their variations.

                              Great input by many here! Thanks!


                              • 12. Re: FM 13 UI/Themes Best Practices

                                Hello mhaskins


                                My advice is to get your default styles right first in the Style Inspector and then build on that.


                                I would suggest that you should first bear these four points in mind:


                                (1) There are some elements in a .fmp12 layout over which we do not yet have control from the Style Inspector;


                                (2) The WebDirect implimentation under FMS13v2 is a significant step forward from v1;


                                (3) The big step with managing themes effectively is to first get the defaults for your choosen theme correct - so they are pleasing to you;


                                (4) The good advice is to ensure that everything on a layout is defined by the Theme applied to that layout - i.e. no "local" styles - those which cause the red asterick to appear in the Style Inspector - as these will slow the rendering of your layout. Thus you need to bear in mind that there are elements in the current FileMaker Ui which do add local styles to your layout/file - unasked by you. These are remnants of the intial development of styles through FMPv12 - and will no doubt be sorted out in the future. The ones I have found, there may be more, are:


                                i.     when you add a field with either the field insert dialogue or field picker the field name - if inserted - bears a local style that is not part of your theme - the two dialogues produce field names with different local styles;


                                ii.    when you add a layout _and_ select the type - as opposed to not doing so - the appropriate Enlightened Theme is used - otherwise the behaviour you would expect - use of the Theme of the Layout you are currently on occurs.


                                NB: I am assuming that you will prefer to develop your own custom Theme as opposed to using one of the built-in themes _unaltered_.


                                Here is how I have resolved these sort of issues:


                                (a) Create a sample layout - applying the built-in Theme you prefer - onto which you place all the possible types of layout object using their default style in each case - this includes layout parts as well;


                                (b) Now rename the Theme to your own Custom theme name and then adjust all the object's default styles to suit your own design - then delete all the named styles from the Theme so that just the defaults remain;


                                (c) Now review this layout in iOS and WebDirect and adjust your default objects to render identically in all formats - top left alignment is always a good starting point as that is what WebDirect prefers;


                                (d) Next consider how to name your none default styles so that they consistently and concisely describe their format - I prefer to name styles this way as opposed to naming styles after objects they are used for - I find it easier to use in practice - by getting your defaults right first you reduce the complexity level for naming new styles considerably;


                                (e) Then delete all the other unused Themes from your file with Theme Inspector - you should be left with just your single Custom Theme.


                                You should now have a consistent Theme populated only with a set of default objects - pleasing to your eye - which works when applied to other layouts - because when the style names of the layout don't match styles named in the newly applied Theme the default style in the new Theme for that object is used - which is one of several reasons why getting the defaults right first will save you a lot of time latter on.


                                When things go a little wrong you can always go back to your default styles - check how they appear - adjust any that are now incorrect - save to the Theme and continue in good order.


                                There is some work involved in getting to grips with Themes in 13 - but approached in the manner I have described a few hours work will give you a solid base for all your future development work.


                                I look forward hearing how others can improve on this approach - as ever this just from my own experience and you may have differing views which I would be delighted to hear,


                                Cheers, Nick

                                • 13. Re: FM 13 UI/Themes Best Practices

                                  Thanks Egbert - I look forward to checking out your file - but that url doesn't seem to connect - have you got another one?

                                  Cheers, Nick

                                  • 14. Re: FM 13 UI/Themes Best Practices

                                    URL worked fine for me. Note that it goes straight to a download, not a web page.

                                    1 2 Previous Next