Hi, could you describe what will you do when there are many styles in your theme?
I have many styles in themes. I've reserved 32 list items for some object types such as text and edit boxes. However, I'm not near that 32 limit just yet after years of designs.
There is a layout of styles to be used by developers as a guide. There is a printable PDF guide used as a hardcopy. There is also a spreadsheet-type reference used as a guide.
Shapes can be considered in slices of top, ctr, and base.
Example;
shape01_base
shape01_ctr
shape01_top
This will lend itself to either rounded corners or sharp corners, colors, and borders and even invisible.
1 Like
How do you make use of the default style?
With dev we made progresses to our strategy and although it is not fully explored and defined yet, here’s what we came up with.
Given that each layout can have its own theme:
1- Create as many themes as types of layout you will have. To figure out how many you will need, first consider the solution UI constant categories of layouts that are used. Here are a few examples of layouts that your solution could have.
Main section page (top level of navigation) List View
Main section page (top level of navigation) Form View
Sub/dependent page List View
Sub/dependent page Form view
“Wizard like” dialogues
Cards dialogues
Picking cards
Settings and parameters page Form View
Settings and parameters page List View
Documentation page
2- (for already existing solution) Assess which objects are likely to be used in each and the ones that should be the default, if you use more than one of the same object, ideally, to save time make for each theme a layout template so you can copy paste.
For example: in my main section page List View, I know that most fields will be for display so I will modify and save the edit box default style to be as i want those fields However for my main section page FormView, i might want most edit fields to be fillable so in that theme the edit box style “default” will be set to the characteristics wanted for fillable
(For new solution) start from a template file which has a list of style names for each object type. Styles’ names are for function. 5 top functions: Fillable, Display, Label, Heading. Example of function qualifiers (body, header, footer, portal, everywhere, merge, required, dominant, ancillary, EN, FR…)
Note that all text-type objects are styled and named to have their equivalent in the other type. So you want your style “Display” in edit box, dropdown, pop-up even a segment of button bar should that be used to display information.
You may also want check boxes and radio buttons in editable or for display variant. We don’t use check boxes: we simulate them with buttons so make sure you have a template layout with such button so that the icons used are present in the fmpa instance that opens it.
3- Objects names: xx_xx_meta where meta informs on function for example (avoids having to open the inspector to check if browse is checked for example). Some meta: fillable, isSelected isSelectedNot (replace Selected by boolean value such as isActive isActiveNot), required, disabled, enabled, disablableNot(enabledLocked, enablableNot(disabledLocked), warning, devComment, testComment. These meta have their logical counterpart in styles. Ex: hasProperty wantsProperty (or hasPropertyNot)
3 Likes
In order to come up with good Style building and naming conventions, you have to first determine the different meanings you need to communicate to the user…and based on that determine the library of Styles that you will need for each type of object.
Using Layout_Fields, here are some of the various meanings the you might want to convey to the user…and possibly incorporate into the name:
- Open/closed for editing
- Fast/Slow to find on
- Open/closed for copying data
- Left/Center/Right Aligned
- Local/Related Field
- Data/Calculation/Global Field
- Fields on List View and Portals should look different than fields on data entry screens
- Required/Optional data
The challenge is to come up with a relatively complete list of Styles to fit possible combinations and give Styles names that embed the associated information outlined above.
Name should also:
- Fit the width of the Inspector window
- Be visual scannable (be nice to dev!)
- Fit the height of the Inspector window (if possible)
We avoid including formatting information (with the exception of Left/Center/Right) as this might change, for example to introduce dark mode, or to swap the font face.
Whatever you do…do it with Style!
Finally, this post and associated video might help:
http://www.twdesigns.com/filemaker-classic-theme-to-custom-theme/
7 Likes
Thank you. is there any new link for the deacon 2014 videos?
Welcome Tony.
If anyone is needing guidance for anything relating to styles, read as much as you can that has been published by this man.
4 Likes
Hi samfmp,
It seems that link to…
DevCon 2014: Real World Theme & Style Planning - Bob Shockey https://community.filemaker.com/videos/1516 (edited)
…is broken.
Hopefully it is fixed at some point and publicly available.
1 Like
Not that the video is there but here is the new link: https://community.filemaker.com/en/s/article/devcon-2014--real-world-theme--amp--style-planning---bob-shockey
2 Likes
Using the Filemaker-provided Contacts database template, at first blush, it seems the provided styles of Enlightened and Tranquil work as expected as far as Text styles are concerned (the only group I tested) when re-themeing a Detail layout. I did notice, however, other inconsistencies among the two themes and the fact some styles remain unsaved. The text styles use the same common names between the two. Of the 20 individual text style names, some don’t really change any attributes from one another.
Noticing various style naming conventions as found on the web, as soon as one names an attribute such as “grad” or “multigrad” or “pill,” the style may become limited and problematic.
If a style name contains the word “grad,” what if one desires to change the object’s fill to a solid?
If a style name contains the word “pill,” what if one desires to change the object’s shape to rectangular?
Numbers in style names for grouping purposes are useful just as they are for grouping categories in ubiquitous Value Lists in a solution, grouping field names, etc.
A springboard…
field.01.Live.Ctr.Base
field.01.Live.Ctr.Mid
field.01.Live.Ctr.Top
field.01.Live.Left.Base
field.01.Live.Left.Mid
field.01.Live.Left.Top
field.01.Live.Right.Base
field.01.Live.Right.Mid
field.01.Live.Right.Top
field.01.Live.Solo.Ctr
field.01.Live.Solo.Left
field.01.Live.Solo.Right
field.02.Dim.Ctr.Base
field.02.Dim.Ctr.Mid
field.02.Dim.Ctr.Top
field.02.Dim.Left.Base
field.02.Dim.Left.Mid
field.02.Dim.Left.Top
field.02.Dim.Right.Base
field.02.Dim.Right.Mid
field.02.Dim.Right.Top
field.03.Dim.Solo.Ctr
field.03.Dim.Solo.Left
field.03.Dim.Solo.Right
field.04.Sans.Ctr
field.04.Sans.Left
field.04.Sans.Right
field.05.Hero.Dim.Left
field.05.Hero.Live.Left
field.06.QuickFind
field.07.Accent.1.Right
field.07.Accent.2.Right
field.07.Accent.3.Right
field.07.Accent.4.Right
Takes a lot of organising to start with using themes and styles.
For fields displayed as edit box I tend to start naming with a indicating where it is used:
Form
List
Portal
Label
or how it is used:
Button
Then a letter for left, center or right aligned:
L
C
R
Followed by brackets to indicate the use of left and/or right borders:
[
]
[]
or rounded:
(
)
()
I do not use a lot of different sizes or colours in one layout, so normally it is enough to add:
Grey to denote a non-editable field
and
Big or
Small
when an edit field has such importance that it has to be displayed with a larger font size, or smaller when being used -for example- as a footnote.
7 Likes
Hi, a bit late reply, is there any performance issue for your approach? I haven’t used that before.
It is a organized method I think and we could just import a theme we need when that kind of layouts are needed
It is a good idea to focus on the purpose of the style, rather than the attributes of the style itself. So rather than button.blue, do button.primary. Rather than text.big, text.title. That’s because you may decide green is a better primary color than blue, or Avenir is a better font than Arial. I think left/right/center labels are one of a few exceptions to that rule since those should survive style updates. Purpose-driven naming is common in the web dev world too.
Since we don’t have cascading styles, there will be some inevitable redundancy when you name based on purpose rather than form. e.g. text.default.left and text.label.left may be the same, but at least when you want to edit merge text later on, you won’t inadvertently change the appearance of field labels too.
I do stuff like:
button.primary
button.primary.left
button.primary.right
buttonbar.secondary
buttonbar.secondary.right
field.default
field.default.left
field.default.right
field.view
field.minimal
text.label.right
text.label.left
text.title
text.subtitle
text.subtitle.right
body.default
body.alt
3 Likes
Following Vince Menanno’s presentation at last month Sofa, where he demonstrated how taxing local formating can be, I am even more convinced about my approach which would improve performance.
If invited at CQDM 2020, I intended to present a topo about it. I have continued to refine my approach since my last post.
3 Likes
@jwilling renaming is an option too when attributes change.
If I’m not sure if the new style will do, I prefer keeping that style and creating a new similar but with other attribute(s).
This way I’m always sure I get what I expect (read from the “label”
12r.Blck.LC.noB.0|0|0|0
is my convention. I do not mention lettertype. In my experience most of the time this is rather uniform across the theme.
size, style (Regular, Bold, Italic), Alignment (Horizontal and Vertical), borders or not and indent from left, top, right and bottom
And when working with many people on one file/theme. A functional description can work pretty fast.
As always, YMMV. Just my input.
Have a nice day.
1 Like
Glad to have your input! We have different philosophies and that’s what makes this fun. But I’m right 
jk
And indeed you’re right that you can rename styles. 
The reason I tend toward semantic rather than style-based names is that when I do want to edit a style, I know what effect it will have throughout my app. e.g. it’s easier to predict the effect of changing text.fieldlabel.left than text.12pt.black.left. The latter could be used for lots of stuff, whereas the former is pretty clear in its limited purpose.
1 Like
Off course you are right. I'm Padwan, you are J(edi)Willing. 
1 Like