If you haven’t started using themes and styles yet in your FileMaker development, you should! This article consolidates information from Andrew Paulsen, Adam Ward, and Bob Shockey, presented in sessions at the 2014 FileMaker Developer’s Conference in San Antonio, Texas.
Themes and styles are one of the most useful design tools FileMaker has provided in recent versions. By defining custom themes and styles, you have the potential to revolutionize your workflow, create a more consistent look from layout to layout, and easily change the look of individual elements across all layouts in a solution.
How themes and styles work
Every object has attributes that can be assigned to it. Some objects have many attributes, and some have fewer. For example, a line object clearly has fewer attributes than a button (which might have attributes describing the hover and in focus states as well as the normal state). For any given theme, these attributes have been predefined for each object type, as “styles.” A collection of styles make up a theme. If you don’t make any changes to the theme’s styles, then the theme’s default values are used and the objects are rendered very quickly, without additional processing.
Once you make a change to an attribute of an object on a layout, that object is considered to be “locally styled.” Local styles are specific to an object. This is important, because FileMaker has to do additional processing for each locally styled object on the layout. If you have a lot of local styles, this can negatively impact the performance of your layout.
To fix this, you can save your local styles to the theme’s style, or create a new style for that object, and save it to the theme. Now, that style is available throughout your file, and any object in the file using that style/theme will automatically update to reflect the changes. This is a huge time savings!
If you use the Format Painter or Copy Object Style/Paste Object Style (read the caveat below, though), FileMaker will transfer attributes from one object type to another, if they share common attributes. So you can select a text object and transfer those attributes (like font, font size, line and fill colour, etc.) to a field object, for instance.
You can remove any themes you’re not using in the new Manage Themes dialog, except for the default FileMaker themes, indicated by square brackets. This dialog can help you if you’re converting a file over to using a different theme, as you can easily see which layouts are using what theme.
You can also import a custom theme from the Manage Themes dialog (you can’t import one of FileMaker’s built-in themes). This is great, as you can easily update a theme in a particular file, and as long as the style names are the same, the changes will flow through to all your layouts. (Note: some caveats below.)
The real power to styles is that if you save a change to a style, it changes every object across your solution that uses that same style. This allows you to very quickly change the look of your solution with minimal effort. This can be an advantage if you’re re-skinning an existing solution with a different look, either to refresh the UI or to customize it for a different client. Or, if you just want to change one little thing, but not hunt it down all over your solution!
If multiple developers are working on the same solution, using themes and styles ensures that everyone is styling objects the same way, enforcing consistency. Even if you’re the only developer, consistency is an important principle, and themes make it that much easier!
A custom theme remembers its “base theme” (the original FileMaker theme you used to build it). Any additional options or object types that are added to FileMaker’s built-in themes in future versions of FileMaker will automatically be added to your custom theme, without changing anything you have already created. So you’ll get the benefits of updates, without losing anything you’ve customized.
Best practices and little-known bits
Do I need a style?
The rule to use is that if you have multiple objects that are identical, then you should use a custom style. This really makes you think about why you might be using a style on an object, whether you could use an existing style, or if it really needs a new one of its own.
Which style do I pick?
You’ll probably end up with a lot of styles (just look at the number of styles for one of the built-in themes), but that’s okay. It’s still better than styling each object locally. It might seem logical to name your styles according to their attributes (like, “Blue Button with Border,” for instance), but it’s better to name them according to their function, like “Continue Button.” This will help you keep track of what style is being used for what purpose, and keep the number of “exceptions” (read: local styles) down.
Style naming conventions
Bob Shockey suggested going so far as developing a formal naming convention for styles. His convention follows the format: TX_field_label (where “TX” is a two-letter code for the type of object it is—in this case, text). But, like any naming convention, the actual convention matters less than being consistent in following whatever convention you choose or develop for yourself. There are going to be a lot of styles in your theme, and you want to be able to choose the correct one quickly and easily.
Bob also suggested you create a layout with an example of all your styled objects on it. This ensures that everything looks good together, and is also a single reference point for any object you might want to use while you’re developing your solution. Taking this one step further, you could create your whole theme in a development file, and then use “Import Theme” to update any other files that use that theme.
Choosing a base theme
One of the few things you don’t have any control over is the appearance of the scrollbars in a theme, so start with a theme whose scrollbars you like (who hasn’t admired a nice scrollbar, huh?). You can customize everything else about the theme to make it look the way you want.
If you have an existing layout with locally styled objects and you want to change the layout’s underlying theme, FileMaker helps you out by giving you the chance to preserve your local styles even after you change the theme. They do this using a two-step undo. Once you change the theme, select “Undo” once, and any local styles reappear. (Hit “Undo” a second time to undo the theme change completely.) This is helpful when you want to update your Classic-themed layout to a different theme, without having to reselect all the attributes after changing the theme (you can just save an object to a new style, and make sure all similar objects have been assigned to that style).
The snapshot of the theme preview you see when you select or change a theme is exactly 736 x 612 px wide. If you develop your theme in a separate file specifically for the purpose, you can create a layout at this exact size for showcasing your theme in the preview pane.
FileMaker only loads the view of an object once it is actually requested to be drawn on the screen. So, any conditionally hidden objects, objects outside the active layout area, or objects inside tab panels, are not fully loaded unless the user requests they be drawn on the screen (by the user clicking on a tab panel or popover, for instance). You can use this to your advantage by putting “expensive,” rarely-used items inside tab panels or popovers instead of on the default view of the layout.
Finding locally styled objects
Objects that have local styles applied can be hard to find. Adam Ward suggested a trick to find them. Using FileMaker Pro Advanced, output a Database Design Report for Layouts only in XML format. Open the resulting XML data file (not the Summary.xml file). Using a text editor, look for the tag <LocalCSS> to find any locally styled objects.
Every time you style an element, it has a cost to layout performance, primarily in the form of CSS added to the page. This can really slow your layout down, especially in WebDirect solutions. There is a new Firefox Add-on that allows you to view a page in a 3D view, called Tilt. This add-on gives you a view of the relative weight of elements on your page by exploding them into a three-dimensional representation of the amount of code for each element. This can really show you how much code is being added to your page, and can help you pinpoint places you might be able to eliminate or substitute objects for better performance. You should try to follow theme and style best practices to keep this cost to a minimum.
If you have unsaved changes to a style, an asterisk will appear next to the style name in the Inspector. The disclosure triangle will also turn red, encouraging you to save the changes to the style (and thereby changing all other objects assigned to that style as well), or create a new style from that object. This is important because any changes that aren’t saved to a style are considered to be locally styled. The more locally styled objects you have, the more “weight” your layout will have, degrading performance.
Changes to a style apply only to the current layout, until you save your changes to the theme, in which case they will apply to any layouts in the file that are using that theme. FileMaker reminds you about this as you are saving the theme changes. Unsaved theme changes are also indicated with an asterisk and red disclosure triangle.
“Save Changes to Current Style” is disabled if you have multiple objects selected. To save changes to a style, ungroup objects and make sure only one object is selected.
Shadows and gradients are expensive! They require a lot of resources to render on the layout, so use them sparingly. As you add blur to a shadow, the cost goes up! This also applies to large images as well.
Be careful when using the Format Painter. FileMaker will apply the correct styles to the object(s) you select, but will make them locally styled instead of according to the theme. If you apply Format Painter to five identical objects, the CSS for each of those objects will get represented five times, even though the objects all look the same. This can potentially have significant performance costs, as already mentioned, especially if you copy/paste from one theme into another. So the objects will look okay, but behind the scenes there will be a lot of extra code. Better to define a style and then apply it to all the objects that should look the same.
The Format Painter or Copy Object Style/Paste Object Style work best when you copy/paste styles from an object that has more attributes to one that has fewer, as you’ll get more predictable results. FileMaker only transfers attributes that actually contain values from one object to another, so if the copied object has no attributes to transfer, the original values on the pasted object remain unchanged. (Having to go through all the states for an object, checking whether the values were changed to your liking, can be tedious and time-consuming—if you even remember to do it!)
When you start a new solution, don’t use the Classic Theme! The name makes it sound very innocuous, and the design is very simple—but it’s the only theme that has certain built-in actions that you can’t control embedded into it (like dimming inactive tab controls). In addition, you can’t save any changes to it, so everything on your layouts becomes locally styled (ouch!). And once you add it to your file, you can’t remove it. The recommended course is to base your custom theme off the Enlightened Theme in FileMaker 13. The exception is if you’re using Instant Web Publishing (pre-FileMaker 13): the Classic theme is the only theme that is supported in IWP.
Be careful when you import themes, the behaviour is a little different depending on the situation. This FileMaker help page is confusing. On the one hand, it says that FileMaker will prompt you on import, and ask if you want to update a theme if it finds a duplicate name…and on the other, the last paragraph says that it doesn’t prompt you. Say what?
What I found is that if you locally create a theme with a name, then import a theme with the same name, it doesn’t prompt you, it just adds a new theme with a number appended to the end (just like copy/paste theme). However, if you import a theme, then import the same theme again (with the same name), it asks whether you want to update the existing theme or create a new one. The option to update an existing theme is definitely better, because then all your styles will automagically update to the new look—as long as you haven’t changed the style names in the local file!
Themes and styles are very powerful tools, and give you a lot of control over the look of your layouts, but it pays to plan ahead! It’s a pain to have to create and apply styles to every object in a solution after all your layouts have already been created (although I still might choose to do this, just for the performance improvements). Definitely consider creating a dedicated layout or even a whole file for developing your theme. With a little forethought and know-how, you’re well on your way to creating beautiful FileMaker designs using themes and styles.
On the topic of gradients being expensive: Not only do gradients have an inherent cost, they become even more expensive under certain circumstances. Specifically, linear gradients that are not completely horizontal or vertical (0, 90, 180, 270 degrees) can have a big impact on rendering performance. So can radial gradients. Thanks for the great synopsis on themes and styles!
Thanks Bob, for sharing all your expertise with me and the FileMaker world!
Great summary of the many sessions devoted to the subject! Thanks!
Thanks Alexis. This is very helpful.
Great summary from DevCon with many of the key points all in one article. Thanks!
I was already a fan of themes before DevCon and using them, but Bob’s presentation on how to practically manage themes changed how I approached it. I’m designing three themes; “Pro”, “iOS” and “Print”, and have been implementing my version of the naming convention Bob suggested at DevCon. Basing my themes off of Enlightened.
Thanks for this writeup; this will be required reading for our developers I’m thinking. 🙂
Thanks everyone for reading!
Thank you Alexis for summarising the elements of the several DevCon presentations from 2014.
They were quite overwhelming to take in at the time. Thus I hope you can keep this blog entry prominent as it will surely help many developers, especially those of us working in-house, who don’t have to depend on a WAN for client connections and don’t therefore experience the penalty of excessive local CSS formatting.
I’m confused about Fields on my Custom Themes. I want to have the label to carry over to the Field colors or have their own colors, but when I attempted to do this, the Custom Theme does not coordinate the color of the theme or my choice of color for the Labels. Is this available?
You have to set and save styles for each type of object independently. Select a label object, set the attributes how you want them to look, then open the Styles tab in the Inspector, click the dropdown arrow next to the Style name, and choose “Save Changes to Current Style.” Then select a field object and repeat the process.
You can refer to my article on how to customize the Classic theme for more detailed instructions (the only difference being you may use some other theme as your base theme). https://www.fmdesignuniversity.com/2015/10/10/converting-from-the-classic-theme-part-1-the-guts/
Thank you for you quick reply. I was close, but misunderstand what was being effected.
Looking forward to your next edition.
“Firefox Add-on that allows you to view a page in a 3D view, called Tilt.” is gone.
What else can we use?
Unfortunately, I couldn’t find anything else comparable at the moment, sorry Peter.