Themes Best Practices

Lounge (Discussions)
21

It is. I wonder why it is this way. Is it poor choices at the software design or genuine limitations imposed by the dual nature of FileMaker as a database AND front end building tool…

22

Would be so great if one could just define a theme or a style per file | layout, maybe via checkbox

23

Well, that already exists: it’s the theme manager. If you use a consistent naming convention and style all your objects you can do just that. If you just use the defaults, you can also do just that: this is how you switch from the themes already included in the package.

24

yes, but only kind of.

I almost gave up maintaining styles (not really...). For example, You have a naming convention like 'field.yellow.center.12' (not really the way we have it) and You want to add a right or a bold field-style, You have to choose 'rename style' (or whatever that option is called), select all the text of that name, copy it without changing something, close that dialog, choose new style, paste the text and change it to 'field.yellow.right.12' - just to make sure that You do not write 'field.right.yellow.12' - what happens here every now and then (that's me - not just my colleagues...) - because there is no handy overview and no functions like 'save as', 'duplicate', etc. Especially on a smaller monitor

Sure, You can create a process for developers that looks like

  • get the demand from the user

  • get approoval by their boss

  • make sure to understand that

  • decide what to do best in FM

  • create the structure

  • more...

  • add the object(s) respecting the UI guidlines of that customer, so users feel familiar

  • test it

  • give it over to the test-user

  • change some things

  • and now, the guidelines for styling needs to be added... for all those different customers. We do not have 'standard' solutions, all individual and we support several versions of FM...

  • etc.

I got problems with some of the interface elements anyway - The old way of having an inspector that only shows the position part would be a dream, a small floating palette.. Further on, with my older eyes, some of the numbers are not easy to read - and then, styles... more than one single popup...

25

"Themes Best Practices," as the OP has titled the thread, can get rather deep. Some of those deep thoughts may be found in a FMSoup thread from exactly two years ago...

https://the.fmsoup.org/t/what-naming-standard-you-are-using-when-you-manage-theme-and-style/366

I believe nothing has changed with the FM theme tool since.

1 Like
26

Developers and end users alike should be aware that FileMaker has been published with faulty examples of their included themes. The example files such as Contacts, etc., have unsaved theme styles and other shortcomings which can present disappointing and unsatisfactory results especially when trying to teach, learn, or demonstrate the power of themes. Altogether new and better conceived files should be created and used for such.

5 Likes
27

One of the sensible naming conventions is to name for purpose. This is the way that page layout tools and word processor styles have been doing it for a long time. This method helps us to avoid getting caught up in specific details. When you want a text object to be a field label, choose a style called "Field Label". If you want it to be a layout title, choose a style called "Layout Title."

Let the layout designer decide the font family, font size, etc. And at some time in the future when they change "Field Label" from 11px to 10px, the name stays exactly the same.

The risk with using "text.default.11" for style names is that someone may decide that "text.default.11" work for column headers just as well as they do for field labels. In the future, when the layout designer decides that column headers should be bold and field labels should be roman, you can't make one change to the Column Header Style.

4 Likes
28

All of the reasons you listed above are valid. In my opinion, the 1st will give you more efficiency because the layout will load faster. However, a big caveat is that you should not have any object using the Default option.

The 4th reason is as important because it allows you to instantly change, potentially, hundreds of elements by making a change to one of the. This includes color schema which means that you can re-skin a solution virtually instantly.

My recommendation is that you create your own custom theme; personally, I don't like or use any of the ones from Claris.

HTH

4 Likes
29

Only one caveat to this: currently, all style names must be unique in a theme. A style name can not be identical for two different classes of objects. That can limit name for purpose at times.

30

Very true. You do need to use qualifiers for different object types. For example: "Field Label" and "BtnBar Field Label."

1 Like
31

I don't have those options in my view.

32

Can you see it now?

33

Thanks for all of the feedback, everyone. For the most part, this thread reinforces what we saw as the advantages, as well as pointing out a few additional benefits. Thanks again!

1 Like
34

My favorite benefit is how stricter conventions can improve team cohesion and ultimately productivity. They take time to build up, but once the tools/conventions are comprehensive enough, they reduce the need for individual contributors to rethink things that have already been figured out, so they can focus only on the puzzles at hand.

I think this same principal applies in other dev environments too. Code linting, auto-formatting, BEM framework (css), TypeScript etc, all take away from individual autonomy in favor of group/project cohesion.

2 Likes
35

There is a graphic in one of the old books from the FTS series (hope it's the right name) that explains how the styles are applied. Its worth a thousand words. I need to find them somewhere on one of my computers :confused:.

1 Like
36

Is this it?

formattingInFMP.pdf (208.3 KB)

p.250 of the v14 FTS

5 Likes
37

Thanks @Malcolm for providing the image.