I recently built a set of styles from an app with aesthetic choices from both my client and Soliant. As I made named styles, I needed to differentiate different kinds of buttons. I caught myself tempted to name them with their appearance (color, size, et cetera). But that appearance is exactly what can be so easily changed when we use styles. Instead, we should name them by their unique purpose (button for report, cancel button, save button, row navigation button).
You get bonus points for naming in such a way that similar styles group together alphabetically. Then you can easily see what you already have in your styles list. For instance, instead of button for report, cancel button, save button, row navigation button, we might instead have button_Report, button_Cancel, button_Save, and button_RowNav styles.
This approach to naming then helps us keep track of the unique types of element we have. This makes it a bit more intuitive when to reuse an existing style and when we genuininely need a new one. It also supports consistency of usage, which helps users know what to expect from a given element. When you name styles according to use, it can make it easier to put a lid on style proliferation. This keeps your app looking clean. Unfortunately, it also makes it easier to see when you actually DON’T have a style for the action you want to offer and do need to add to your style library.
I recommend staying organized in this way when you start a new project. However, sometimes the chaos of early-stage design experimentation gets in the way. If that happens, take interface inventory to get a handle on what you have, what you need, and what is redundant.
These two articles describe ways to make an inventory of all the unique styles of interface elements in your site or application. They show how to use that inventory to help prune and stay focused on utility. These principles – or lighter-weight versions of them – apply equally well in planning or building up a set of styles in one’s FileMaker application.
Try to regularly do some kind of interface inventory exercise after a few cycles of development. You’ll have plenty of real features to examine. You’ll also find places to standardize and tighten up styling. This helps build up the right library of styles to help developers work faster and cleaner in your layouts.
Hello July,
I agree with you on the usefulness of grouping style names!
However, I would like to WARN against GROUPING BY OBJECT TYPE and also to
distinguish between grouping by object type and grouping by function.
In the FileMaker inspector the list of shown styles are *only for the currently selected object type*, so – if you are styling a button – ALL of the styles are going to be button-styles.
=> Having the word “button_” at the front of all button style names makes it hard on the eye, makes it difficult to scan to the style you are looking for – and takes up valuable column width.
If however you are styling another object type, say a text-object which should be styled as a button, then “buttonNavTxt”, “buttonStandardTxt”, “buttonLargeTxt” is a good naming/grouping prefix to distinguish from other text styles such as “LabelStandardTxt”, “HelpTxt”, “AsideTxt” etc.
Nevertheless the TYPE OF OBJECT should be added AS A SUFFIX, for two important reasons:
1. Style names must be unique – and indeed unique ACROSS object types. This means that if a text object style is already named “BigButton” a button object MAY NOT be named “BigButton”. THUS it is essential to add an – otherwise redundant – object style abbreviation to the name to ensure this uniqueness, e.g.: “BigButtonTxt” and “BigButtonBtn”
2. Given that the FileMaker style inspector is very narrow, it makes very good sense to place this REDUNDANT information AT THE END of the style name, where it does not matter if it cannot be seen/read.
Following a mix of your and my guidelines developers can get a very clear list of *readable* style names.
——
ANOTHER WARNING for everybody considering RENAMING THEIR STYLES, who wish to continue to be able to update their themes between files:
If you have FileMaker 13 – DON’T RENAME YOUR STYLES! … In fm13 the styles are given a new internal id and can no longer be updated.
First in fm14 styles can be safely renamed and retain their updatability (internal ID).
Later versions of fm14 have also introduced updating of styles by VISIBLE name, and not just internal name (UUID) – but use the import theme function from the change theme dialog rather than the manage theme dialog, as the latter still has an issue when updating styles of same name but different internal ID.
>> Check the FileMaker community website > Issues area for the latest. <<
I hope this helps you all.
Happy fmStyling
MrWatson