We've some experience with restyling solutions. Naming styles by the function they have is definitely the way to go. Do not try to describe their formatting since this will likely change.
Which properties are saved in a style?
I thought that all properties under all tabs in Inspector are saved in a stil (appearance, data, position), but have noticed that data properties are not saved in a style.
Only properties under the appearance tab?
Are you using FM13? This process is greatly improved in 13 cf 12.
You mentioned the attributes that are saved into a style.
Options on the data tab are not stored as a style. You can have a style for drop downs, a different style for popups, and yet a different style for calendar fields. It seems that the data tab defines the type of field it is, but not its style or attributes.
In a current solution I am working with, I try to keep everything defined as a style. I figure it brings some cohesion to the solution when I force myself to use what I've already defined. If I need another look, I try to decide if it is going to be used throughout the system. If it is, a style is created with that look. If it is a one-off thing, I'm okay using local styles for that one object.
Here is a description of the approach I developed to do what you describe. I tried several other approaches before I settled on this which I have now used consistently for about a year - so - for me - it works very easily - but you do have to get organised at the outset - thereafter you profit from your earlier investment.
I hope that find this helpful
An efficient method to create your own custom theme
A theme is a collection of styles.
Each style holds most of the defining controls (but not all at present) for the appearance of a single class of object - here is what I recorded when I looked at this about a year ago:
FM13 : The Naming of Styles
2 EditBox3 Button
A PopOver Button
B Drop-down List with [v] button
In order to manage your styles create a layout on which you place an example of every default object style - then adjust all the deafults to follow your designed Theme.
Note 1: there are different default styles for each part although this does not appear in the style menu.
Note 2: AND there are different styles for items in each part -
Note 3: default text is used for field labels
A. Create a layout on which you put an example of every different layout object and style each one the way you want as your default - so you want to carefully get each default so it is a close to your desired final appearance as you can at this stage.
B. Save each one as the default style - for that type of object - you have no choice over the class of object - you just have 11 or more different default styles to set.
C. Save your current theme as a new theme - i.e. My New Theme v1 - and delete all the styles shown in the inspector but the new defaults you have just created.
D. Now import your new theme into the solution and go through each layout and apply your new theme.
E. You should find that all the objects in the layouts will default to your default style for that type of object - since that is the only option.
Now you need to start to develop the styles required where the default does not quite suit - and here is what I found for me was the simplest means of dealing with naming styles - and it is different but I believe much simpler in practice than some other approaches - for example naming based on purpose. This is fine for a small solution, or where every component of the Ui has been exactly designed and specified before you start, but in practice it became far too complex for me as my App evolved, I found the self documented approach was far easier and faster:
(1) Name each style to show the change(s) you have made from the default.
For example my default text box style is as shown on the attachment. Basically left - top aligned, Helvetica Neue, 12pt and a specific colour.
So if I need text centred and mid vertically - I start with the default, change the appearance and save it as a new style called 1_ctrMd10. The first character is from the list of types of object above. This means that in future when I want that style I can select it easily. I have found that this approach ensures the style names are shorter as you don't need to describe the default elements - only the differences.
(2) Be very careful not to change any of your defaults without thinking carefully about it first.
(3) Some special items you create may need more complex names to identify them.
So this is fast, there are zero local styles, and it is self-documented as the style names enable you guess what each should look like.
The second screen shot shows some of the styles for a text field.
I am sure that there are other good approaches but until I realised the importance of defining all the defaults first I wasted a great deal of time trying to figure out an efficient method.
I have used similar approach like you.
I named some styles with somekind of a "naming conventions" and other simpler by functions they perform in a solution.
Some examples: Field_in_R12, Field_in_L12_Bold, Nav_Btn_Next...
Majority of style´s attributes were defined in one older solution,
I only had to copy them in a new template file / FMdb and by saving them as a new styles in inspector I had to name them properly.
By the way I saw some solutin / FMdb which shows all the local formating of objects.
Another approach is to use / "parse" the exported xml file and search there for a <localcss> tag.
Good point about first having the default styles well defined and a great strategy about how to start with a new theme.
I don't agree on naming styles by formatting, though. With the introduction of styles we were given a new abstraction layer that allows us to free ourselves from the burden of dealing with font sizes, styles, colors etc…
This allows a developer to deal with just 'headers', 'labels' etc… and leave the formatting to a graphic designer. We are a team of developers working mainly on tailor made projects. To us this is very important.
If you include formatting details in style names, you are limiting your options. Of course you can change the '16pt yellow' style to '18pt green' and it will update on all layouts. That's great. But do you then really know what you have just updated? Does a developer know when to use the 16pt yellow, sorry the 18pt green style in which situation?
Also, if the customer doesn't like yellow or green, you'll have not only to update each style but also to rename it, right?
You make a fair point about the naming of styles, but I think it depends on what you want to achieve.
I have spent some time developing a theme that seems to work for the purposes I have in mind and in doing that over various iterations over more than 2 years, having tried naming by "purpose", I found it far easier to name by format. Hard to explain why but that is what i found and I tried by purpose for about a year.
If you have a solid design then naming by purpose is fine and in fact some of my styles are named that way - so when Yosemite came out it took an hour to change some key aspects of my Theme to match Yosemite.
If your wireframe is not locked down then, in practice, you will probably find it easier to use a mixture of by purpose for those things which are locked down and by format for stuff you are still thinking about.
Thanks for your comment - a very useful thought
Hi Joris - I think?
Sorry just checked your site as I wasn't sure of your name.
Yes, Joris is my name :-) Thanks for visiting our site!
Of course you should do what works best for you. And there's a difference in working with a team and working on your own. I can see the advantage in knowing exactly which styles to update for Yosemite if the name of the style gives you a clue about its formatting.
All the best,
In my opinion, if you are working on a big solution with a lot of layouts and styling, it is worth to name some styles by formating.
If you have a lot of variations of some object (for example table field or a label) specially in a solution or a theme / template file that still evolves ("agile").
Later can you simply change, rename and delete all the inapropriate styles and export / import the theme.
Great! - and agreed - you have very eloquently said what I thought and what I have been doing but which I had failed to express clearly.
So styles are a two stage thing, first use self documentation - i.e. meaningful format names - until the evolution of your design means that you can change style names to name them by function.