Using FileMaker 13 Themes
Prior to FileMaker 13, my interest in any of FileMaker's default themes was pretty much zero. Being that I personally enjoy the process of designing a nice user interface, I was content with creating, and hacking, whatever user interface I needed. I did this on pretty much every layout, one-by-one, using the Classic theme selected as the default.
Enter the world of FileMaker 13 and my perception of FileMaker themes has now made a full 180. You see, the advantage of custom themes, custom themed objects and the ability to have an unlimited number of these, themed objects that is, makes the process of truly theming a solution an EXTREMELY powerful proposition.
Envision this, your solution needs an update. It's looking a bit tired and some big company, like Apple, releases a new OS. This new OS starts to make your solution look even more tired and you would desperately love to update the look and feel. However, you seriously dread the prospect of walking through hundreds of layouts making individual changes to hundreds of objects - NO THANK YOU! Well, worry no more, this problem is all but solved if you really understand how FileMaker 13 implements new custom themes. If you're still wondering how powerful they are, then make sure to watch this tutorial video for a comprehensive understanding.
Comments
Blown Away by the Implementation of CSS
As it so happens, our developer's group met today and saw the power of CSS in FMP 13. I was thinking of you when I saw the how the behavior is what it should be and consistent to the way iWork functions. Then, I come home and see your email. So, I've declared today CSS in FMP day.
Byron Songer
Louisville, KY
Theming in FileMaker is finally here
Hey Byron, no joke about the 'power in CSS'. While FileMaker does have to implement rigid standards on all their objects in order to render to Web Direct, they have done so by accommodating the full CSS spec. They are doing their own rendering based on the CSS, but they implemented such that we now not only have cascading overrides, but we're able to apply solution wide! WOOOOHOOO!
This is a major benefit to any solution!
-- Matt Petrowsky - ISO FileMaker Magazine Editor
CSS impact on file size?
Thanks for this video Matt, as always it brings new insights in how to use FMP.
Will there be a lot of impact on file size when there are many deviations on CSS-defined objects. As it also seems to remember previous settings, this may blow up the size considerably.
Peter Sijmons
Szienz
Netherlands
Embedded themes are small amounts of text
The key with how themes are embedded into a FileMaker file is the following - to the best of my knowledge.
1). The first time a theme is applied to any given layout it is read into the file and saved there - just once. It can be used on any other layout but is only stored once. Any layout which uses that theme simply points to the embedded theme's settings for the purposes of defaults. Note: Embedding the theme into the file allows it to be modified. If you save changes to the theme and it was an FMI theme it will create a new one.
2). A new FileMaker 13 file starts with Enlightened theme. The key for this theme is com.filemaker.theme.enlightened. A saved copy of the theme or even saving changes to the default FileMaker theme causes it to be renamed to something like com.filemaker.theme.custom.B87EB0E9_A8A9_4B05_86FD_24491A043B8C.
Essentially, as soon as you apply a theme to a file it's embedded. If you save as a copy then it may not fully duplicate the whole theme but it will create a new custom theme if the original theme was from FileMaker. I'm not yet clear if the custom theme references the original parent and only saves CSS for modified elements but it seems like that "might" be the case.
FileMaker won't allow name collisions based on it noticing difference in theme contents. The theme is pretty much canonical in its settings. You'll always get a new theme whenever you choose the option to "Save Changes to Theme" and it came from FileMaker. If you "Save Changes to Theme" with a custom theme then it just updates it.
If you add all themes to your file by applying them then yes, you will load the file up with embedded themes which you don't need in the file. Do this in a tester file for preview when picking your starting point for a theme. Once you know which one you want then apply it and Save the theme as your own custom named theme to start tweaking.
Hope this helps.
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Great Presentation Matt
Thank you for the great overview of how themes work in fm13. I'm curious if these changes will bring about any changes to the them studio and the method used to deploy new themes? I think FileMaker has given us a great deal of power now when it comes to sharing and distribution of custom themes. Good stuff.
Keep the fm13 stuff coming!
Updated Theme Studio in the works
I am, in fact, working on an updated Theme Studio with new features and functionality. Working as quickly as I can using the new theming features in 13!
-- Matt Petrowsky - ISO FileMaker Magazine Editor
A few additional observations
Thanks, as always, for a great video, Matt.
I've done some experimentation and come up with a few additional conclusions.
First, I agree that adding a theme to a file causes it to be read into the file only once, not multiple times for each layout on which it's used (see below).
Second, I initially harbored the same suspicion as you that saving a custom theme might just save the modified CSS and rely on the FM built-in theme from which it was derived for the remainder. I'm no longer so sure of this, for a couple reasons: (1) once you save a custom theme, you can delete the original from the file, without impacting the proper rendering of the custom theme, and (2) you can import the custom theme into a new file without the original being pulled into that file.
Third, re concerns about bloat from adding too many themes, you can actually now delete, from the file itself, any themes that were added at some point to the file but are no longer used in any layout. The new Manage Themes dialog shows how many layouts each theme which has been added to the file is used in: if 0, you can completely remove the theme from the file (and recover the space, see below). Mind you, it may still be a reasonable "best practice" to create and tweak custom themes in a separate "utility" file, then just import the polished final into your production file—that's probably what I'll do—but FM's theme management is much improved in 13.
Finally, FM seems to be much better now about changing themes within a layout without accumulating crud and introducing styling artifacts. In 12, changing themes too many times in a layout often resulted in some wonkiness in the formatting. I have not been able to reproduce that in 13, having "stress tested" a practice layout by going through all 50 pre-defined themes and back. With each change, the layout seems to get completely and correctly updated to the new theme.
My observations came out of some testing I did a month or so back. I can't locate the hard numbers I recorded at the time, but fully remember the procedure and results, which I'll describe here:
1. I created a new, blank file with one (default) table, no fields, and no records. It opened, of course, into layout mode, where I immediately changed the theme to Classic (presumed to be the "lightest"). I saved the change and, in Manage Themes, deleted the "Enlightened" theme from the file. Next, I duplicated my blank layout 9 times, for a total of 10 blank layouts, all with the Classic theme. I closed the file and noted its size, using Get Info to get an exact byte count.
2. Next, I went back into layout mode and changed one layout to another theme. (I forget which one, but I picked the theme with the largest css file size: might have been "Electric.") Closed the file and noted its size: it had grown by a significant factor, as expected.
3. Next, I went back into layout mode and applied that same theme to four more layouts. Closed file and noted size: no change at all!
CONCLUSION 1: It looks like the theme is just copied once into the file and associated with each layout where used, rather than being copied into each layout. Well, that sure makes sense.
4. Now, I returned to layout mode and applied a second non-classic theme to the sixth layout. Closed file and noted size: another significant jump in file size, as there were now two non-classic themes in the file.
5. As in step 3, I next applied this second theme to layouts 7-10 (previously Classic). Closed file and noted size: as expected from my conclusion in step 3, there was no change in file size from step 4.
6. Next, I returned to layout mode and changed layouts 6-10 to the first non-classic theme, meaning that all 10 layouts were now using the same theme, but both non-classic themes were still in the file. Closed file and noted size: no change from step 5.
7. Now, I openend Manage Themes and deleted the no-longer-used theme that had been added in steps 4 and 5. Closed file and noted size: wondrously, it had returned to the one-theme size it was back in step 3! (I should note that when I say "one-theme," I'm referring to the theme added in step 2 and am not counting Classic. Classic is the only theme that, once added to a file, cannot be deleted in Manage Themes.)
CONCLUSION 2: Clearing out unused accumulated themes via Manage Themes appears to completely recover the space. Yea!
I'm sure there are nuances that my testing failed to reveal, but I tentatively interpret it as good news re the effects of changing themes and resultant accumulation of css stylesheets in the file.
Mark
Thanks
Thanks for taking the time to report on this. Very helpful!
Nice find on deleted themes
@Mark Scott, I had not tested deleting themes from the file. I had only ever applied (created) a new custom theme to my files. I knew I would almost always work with a custom theme so it didn't really occur to me to remove themes.
Thanks for the exhaustive research. I had taken a somewhat similar approach although rather than working on multiple layouts in one file I duplicated the same file multiple times within the Finder.
I got the same results, minus the deletion tests.
This is cool stuff for sure!
I'm even creating a "Developer" theme which supports the Developer Layouts discussed over here http://filemakerstandards.org/x/cYMI
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Speaking of standards...
I'm embarking on my first project taking an existing solution and applying a custom theme to all the layouts. I think there is a huge need to develop object classification naming conventions. I would hope these could line up with existing CSS conventions and help cover the specific needs of FM developers. Iv'e scanned some of the FM sample projects and I don't think that's going to cut it!