Hi, I am curious what naming standards are using by other developers when they manage the theme and styles?
For example, field_f18_b_ac where f for font, b for bold, ac for align centre…
Welcome to any ideas.
at the moment, it is not easy to deal with styles/themes. There are some features missing regarding organizing
We try to find a clear naming, that helps dealing with styles - but almost every time I’m working with styles/themes, I’m asking myself if it’s the way to go…
The naming goes like this (just as an example): label.small.center.black
1 Like
Hi @samfmp,
Themes get the solution/module name. I work with 1 Theme per file. This may vary with your design needs. For styles, a naming convention like ‘purpose[_characteristics]’ is convenient. 'Purpose comes first because it allows grouping of styles for similar use.
Examples:
Portals:
ListStd
ListReadOnly
Fields:
TxtStd
TxtStd_G:white_T:Arial,12p_P:L,C
TextUpperL_G_white_T:Arial,12p_P:L,U
PortalTxt_G:none,L:none_T:Arial,10p_P:L,C
Be consistent with shorthand names (style segments like Graphic=G, parameters like alignment upper=U ) throughout a theme.
Unfortunately, FMPA does not present styles alphabetically sorted in the selection list. The MBS plugin does the job, which is a tremendous help.
Beyond that, dedicated layouts for style definition can be helpful.
1 Like
Thank you. Could you brief explain how the MBS plugin help under this situation?
The MBS plugin presents styles alphabetically sorted (in Object Style selector), which speeds up layout work.
If the layout is for printing, will you separate into different theme?
We discussed this a short while ago. You’ll find some discussion about theme naming in this thread: UI/UX person and UX/developer person collaboration
4 Likes
Recently I tried using this convention, it’s working well so far.
Font | Size Position Color ObjectType
For example,
Menlo | 09 Left Middle White Text
Menlo | 12 Left Bottom Blue Edit
1 Like
Does this convention not break whenever one would want to re-style any of those attributes except the last, ObjectType?
2 Likes
Not sure what you mean.
It ends up looking like this in the Style window:
Menlo | 09 Center Middle White Text
Menlo | 09 Left Middle White Text
Menlo | 09 Right Middle White Text
Menlo | 12 Center Middle White Text
Menlo | 12 Left Middle White Text
Menlo | 12 Right Middle White Text
Menlo | 14 Center Middle White Text
Menlo | 14 Left Middle White Text
Menlo | 14 Right Middle White Text
It becomes a fairly standard set of styles. The font range is kind of tight when you start using a grid to design. I typically end up with around 50 or so styles for each object type. The object type at the end just lets me use the same name for multiple object types, and it’s usually off screen anyway.
For example; If one wanted to re-style field labels of "Menlo | 09 Left Middle White Text" to Arial, 10pt, Right, Bold, Gray." The original style name would no longer be valid.
2 Likes
Couple options:
- Rename the style.
- Duplicate and change the font and style name.
I do have a couple themes that have multiple font styles. The nice part of this, everything gets grouped together. So it’s easy to manage.
Unfortunately, renaming individual styles defeats an important and powerful feature of styles in regards to their portability.
An example of a good style sheet would be to create styles for a light, blue and white, high-key theme called “SalesPorch” and then modify and rename the same theme to use “DarkForce” colors, text, etc. without renaming any styles at all.
A simple convention of “text01” could mean any style of text and valid across different solutions. The number in the style name provides a grouping element.
1 Like
So when looking at the below, how do you decide what to use?
text01
text02
text03
text04
text05
text06
text07
text08
text09
text10
text100
text11
Don’t get me wrong, I don’t actually manually edit the style names. I’d pull everything to the clipboard and manipulate all the objects there. Paste them back and save. Though I don’t have to do that often in my situation.
In practice, very few styles are typically used and are rather easy to remember something such as "text01" is meant primarily for field labels, etc., "text05" could be H5 headers or mastheads, etc.
Again, in practice, let's say everyone on the team knows "text01" is primarily a field label for the entire solution that is currently left-justified but a directive comes down to change all the field labels to be right-justified for a new version or refresh of the solution. One could change all the attributes of the style without changing the name at all. The important aspect to remember as far as text is the new style must fit its confines of size.
Also, just by clicking on an existing object should reveal its style.
I think it was Apple who said people tend to grasp lists of 7 and I tend to agree. I have anticipated up to 32 places for certain lists but have not reached the necessity yet although I work on rather complex solutions.
1 Like
I neglected to make mention of a layout for the style guide in the solution for reference by developers. (I haven’t referenced it myself in a long while.)
Yeah, I could see if you are spinning themes to use for multiple clients, and easily customize them why you do it that way. I started with something similar. And would probably use a slightly modified approach for fresh projects.
Even with the complex stuff I worked on before the place I’m at now, nothing prepared me for what I see here. It’s a 13 year old legacy system that has been constantly added to for 13 years ( 2 full time devs work on it constantly ). It has 30-40 files per server, 7,000+ layouts, and I think we are sitting about 200k layout objects, x3 production servers that each house an almost identical but customized version.
We kind of went to themes to define what was being done with it. While there are 50 styles per object, typically we only work with a few of them. The others are for things like report headers, etc. And because the reporting layouts are so varied, we needed a way to just pick the size we needed for that report. So “print” reports have a theme. Newer user-facing UI has a theme. Older user-facing UI has classic theme, but we are slowly converting them. Dev-facing UI has a separate theme ( affectionately named Homebrew ).
I’m with you on this @FMUSER01. I prefer to name styles for their function. I want to see
ColHeader - ListView
ColHeader - Portal
FldLabel - LA
FldLabel - RA
I’m not interested in the Font. I’m not choosing a font. I’m choosing a style.
1 Like
Thank you. What about background color and combination of boarder(for example, top and bottom boarder)?
To be sure, the convention of “text01” is arcane. Only because very few styles, in what could be a very long list, are actually used regularly make the method feasible. It would be helpful if Filemaker could move the styles pane over to where the Fields and Objects pane is and include the option for style commenting.
1 Like