Hello Soupers!
The dev team that I'm part of is trying to come up with some convincing arguments for why we should use only theme styles on layout objects in our application. All of us are relatively new to using themes, but what we understand is this:
Using only theme styles reduces the amount of custom CSS for a layout, marginally reducing file size and increasing performance since a theme style only needs to load once per file.
Using only theme styles lends itself to developer efficiency, since the dev only needs to choose a style from a list, versus choosing a type and then applying individual style changes.
Using only theme styles lends itself to UI consistency, since all of the styles are pre-defined.
Using only theme styles makes changing a theme easier in that any changes to theme style apply to all instances of that theme style throughout the file.
Does anyone have any links to white papers or other documentation that goes into any more detail? We're specifically looking for anything that would show expected performance gains by sticking to theme styles, versus starting with a theme style and then manually modifying.
I reached out to someone who may have researched the topic of themes and performance in FileMaker. I will get back if / when he gets back to me.
In the meantime… may I suggest you look beyond your development team when considering themes? A UX/UI specialist would be a better resource to help you with theme design. Theme design requires first and foremost a holistic approach to UI design – how to display what and where. The result of these design decisions dictate the needs of theme design. PM me If you are looking for such a specialist and I will forward you names.
There will also be many elements in themes. A naming convention for the theme would be really useful. A theme designer should be able to help here too.
Thanks!
For further background, we already have a theme that's in use. What we're trying to convince management of is that we should only theme styles, instead of the current usage of the theme being the "starting point" for styling, and then many layout objects having additional styling applied to them manually. Management is concerned about the theme's style list becoming unwieldy and not seeing a benefit to using only theme styles.
potential for faster UI development, if you're diligent about updating the theme, maintain rigid naming, and have enough styles to cover all that you need.
Since you already follow a convention this might not apply but:
I think naming is going to be the biggest challenge and it's worth writing as detailed a spec as you can. Personally I'd stay away from naming colors and specific font sizes. Instead describe the function: text.label.left, text.subheader.left, text.label.right, button.primary, button.secondary, panel.card etc... instead of text.12.black
Yes your style list will get long, but I think that can also be a good thing in terms of better planning and making do with fewer variations.
FileMaker doesn't make theming easy, because we only have one level of "cascade", based on the Default style for each object type. For every variation, we have to define every attribute, so it's easy to end up with tons of one-off styles if you aren't careful. I'd say management's concern is very warranted in that regard.
Another thing I've learned is that different types of layouts can have their own individual styles to keep themes slimmer. E.g. you might have a "Picker Card" theme, a "Print" theme, and a "Utility Layout" theme. all with very short lists of styles. That reduces some of the cognitive load when working on different parts of the solution.
A long list of theme styles will be manageable if you have a good naming convention. I echo some of what @jwilling said. Avoid the use of most style attributes in style names. You are best served by using multiple themes in a solution. For example, print and on-screen styles are vastly different, offer few style overlaps but can benefit from style name re-use.
As to the benefits of using theme styles… it's not just consistency, performance improvements or faster UI development. It's also modification. For example, want to change a style's font that is used in multiple layouts? Change it in one object, save it in the style, save the style change in the theme… and presto… all objects that use the same style in all the layouts that use the same theme will automatically update.
It's not only faster. It also ensures no object is missed when you change a style.
Objects with local styles cannot be modified by changes to the theme. If you allow developers to use the theme as a starting point and let them use local styles to add font size, weight, colour, etc. then they immediately lose the benefits of a theme.
This is one aspect of themes that respects the original CSS conventions. If your developers start styling a text object with Default and reduce the font size they should save that as a new style "Default - small" and save that back to the theme. Now it can be used everywhere. What is more, a change to Default will flow through to "Default - small."
Maybe an analogy would help you convince them. Would they be happy, for example, in some other area of their operation—setting fees? invoicing terms? wages?—for business rules to be kept to a deliberately short list (to avoid becoming unwieldy) and allow staff to make up their own rules on the fly.
What you need is a design system. There is a huge difference between a theme and a design system. What I have been working on since last year is a Design System compatible with FileMaker UI tools, including the theme.
Example of solid design systems:
Atlassian Design System (Atlassian)
Polaris (Shopify)
Carbon (IBM)
Lightening (Salesforce)
Primer (Github)
Spectrum (Adobe)
There are several SAaS which purpose is to offer a platform to create share and collaborate on the construction of a design system. Figma is one of those. Several open source design systems are listed on their page:
@Cecile, UI design is my weak spot as a developer. The challenge is that many customers do not want to invest larger sums in UI design. That leaves me working with my limited resources and knowledge of design. What could be a way forward in these cases FM-specific? Could that be something that we can buy like a plug-in?
That is basically what I am in the process of creating: a framework with instructions how to use it, which would be customizable, using tools such as SimpleKolorswap and bds_themeditor, to your company's or product branding, or your client's.
@ByteTheBullet a side benefit to using themes is that it should reduce the size of your DDR and make it shorter to process with your preferred DDR utility.
On the performance side of things, I would expect your results to vary. If you are using WebDirect or accessing over WAN, I would expect you could feel the difference. On a LAN, I would assume it is less perceptible.
All in all, I do not see performance as the primary motivation to use styles for, but everyone has a different value system, so it is for you to figure that part out. For myself, I will say that anyone who is not using themes & styles is missing out.
I recall a Sofa meeting where @vmenanno was doing a presentation. He stressed out the performance gain from using styles instead of local formatting.
Another thing to keep in mind is that FileMaker optimizes styles only the first time when creating a child from a default style. So it pays to create new styles from the original if there are several parameters touched. Otherwise you get a long series of parameters that just litter the style which FileMaker reads. Remember Word Perfect tags?
Since themes are subject of change as well (deprecated themes...), older white papers might not serve well in general.
When switching a big app from V11 to 15, we did quite a lot of testing, measuring. It appeared as proper themes were 2-3 times faster for calculating, but slower to display. Calculating was milliseconds, but displaying/rendering was about seconds or half a second.
So, the point is: Is something 'measurable' or 'feelable'.. (I did not measure much since V18 - there are other more important problems with/after 18, ie the need of adding 'pause script-steps every here and there)
Dealing with themes is still somewhat strange (at least) - neither intuitive nor a usable user interface. Here, often the various developers can deal with 'normal' guidelines but not so so good with themes - often, small changes to a field (whatever has styles) is done without respect to styles/themes - guidlines
Themes/styles are important here anyway - working with icons becomes much easier. But for using themes/styles in daily dev'-life, there might be some enhancements needed....
They may need some tested examples or recipes for how to achieve the look and feel. A useful addition is a layout that displays all the theme elements.
“Under the Hood with the RCC FileMaker Layout Optimizer” is one of a few videos which measured actual performance of certain FileMaker themes using a certain tool… https://www.youtube.com/watch?v=EP1wEofc9x8
Management should understand if you're not using the power of the computer to perform some tasks which could be automated, they're wasting time. The sooner one invests the costs of creating themes, the sooner the dividends.
Sorry not on here that much... Tony mentioned this post to to me. I haven't looked at the video posted by RCC ... I'll look at it at some point... and can't figure out how to include a image here in my reply.
But InspectorPro has a view to all your styles at the layout level and how many objects are styled by the theme, how many are the default style, how many are local to the layout and how many are custom styles. and the count of how many care using conditional formatting.
It's very comprehensive and it also has some numbers in terms of number of bytes needed in summary. So you can see how much of a savings you might end up getting.
