Style Conventions

[Jeremy Bante]

Has anyone starting devising or using any naming or organization conventions when working with themes and styles?

[Matt Petrowsky]

I've not. Suggest away.

On Wed, Apr 2, 2014 at 12:00 PM, Jeremy Bante <jeremy...@gmail.com> wrote:
> Has anyone starting devising or using any naming or organization conventions
> when working with themes and styles?
>

> --
> You received this message because you are subscribed to the Google Groups
> "FileMaker Development Standards" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fmstandards...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Mark Scott]

Timely topic; I've been fiddling around with themes quite a bit . . . but few ideas to show for it that would qualify as nascent "conventions."

When you say "organization," Jeremy, what level of organization are you thinking?  

I ask only because any and all custom themes added through the "normal" channel (i.e., "Save as New Theme…") are automatically thrown into the "Custom" bin in the Change Theme dialog.  One could, of course, use some sort of prefixing approach to at least get a family of related, custom themes to hang together under that "Custom" heading.  

I've been working on a series of iOS 7-inspired themes (desktop versions only, so far), and have named them all "Seven <color>" (e.g., "Seven Orange") to keep them together.  (Mind you, I'm experimenting with the "officially discouraged" approach of bringing a tweaked stylesheet in through the Application Support > FileMaker > Extensions > Themes back door, then, as an additional level of assurance against future overwrites, etc., re-saving as a custom theme once it's loaded into the file.  That approach allows themes to get their own family in the Change Theme dialog [by creating a new <group> name, e.g. "<group>Seven</group>," in the manifest document], but, again, once you re-save it as a custom theme, it just falls under "Custom," rather than your new family.)

Now, as for style naming, we obviously have a lot more leeway to implement something.

One rule I've been generally trying to follow is to name styles for their functional use, rather than appearance attributes.  For example, if I create a button style that is meant to indicate a "default action"—an action that can be invoked with the Return key—and then (in Mac OS tradition) color it blue, I'll name it something like "Button Default Action" rather than "Button Blue."  That way, if I later decide to change its appearance, theme-wide (chartreuse, perhaps?), I have a style name that remains indicative of function, rather than a name that is now at odds with the new appearance.

Mark

[john renfrew]

I am starting to explore this area too... like Mark using two words, first is functional area and second is generic action or attribute

so Button Delete, or Button Link, and for text Header Large, Footer Small, fields Date WebAlt, Date WebMain, Edit Plain

Not doing anything the flag mobile use as I am leaning to having two themes in a file, one for desktop, one for mobile, but with same field names in both.

One of the most difficult areas is that when dragging fields in form the picker it uses the default style as the label style - which for me is best done as right aligned but that also applies to default text added with the text tool. Would be a nice thing to assign the default label style.

john

[Matt Petrowsky]

One comment I have John is that I think I'm deciding on not using the
prefix of the object type - because it's already implied.

In most uses of the Styles, selecting on a button object already both
implies and filters down to only show those styles which are
applicable to buttons.

The one time when I can see using this qualifier is when you are
viewing all styles for a theme. But this is an explicit checkbox
setting.

So, anytime I select a given object in the layout, ONLY those styles
will be initially visible.

I'm tending to name styles according to the applicable area of the
solution. For example.

Help Icon
Help Multiline
Help No Scroll

Where the first would only show for a button, the second for a field
and the last for a portal.

I am also thinking that I will follow the "Default" naming for "base"
object styles (solution wide defaults).

Default Calendar << field
Default Multiline << field
Default Scrolling << portal
Default Group << rectangle (field group)

By extending Default to the area of the solution where the style
(mostly) applies, your styles become specific to the solution. Which I
think is a good idea. For example.

Header Gear Icon << button
Header Background << header
Invoices Paid << button (specific to Invoices layout)

If, in the case where the Invoices Paid button style is used in more
areas than just Invoices then it becomes renamed to simply Icon Paid.

I now know it's my standard Paid icon embedded into a button.

Hope this helps out.

Matt

[Denis]

The problem I have is that FM 11/12 > 13 converts oddly and you can't always tell if you have a proper button or a text label that you made clickable and into a button.  I've been naming as:

btn Delete

btn Transparent

btn Transparent Default

btn Jumbo

btn Jumbo Default

Still figuring this out too, but I found this is helping with cleaning up my existing layouts and adding themes/styles.

D

[Matt Petrowsky]

On Fri, Apr 4, 2014 at 1:12 PM, Denis <dso...@gmail.com> wrote:
> Still figuring this out too, but I found this is helping with cleaning up my
> existing layouts and adding themes/styles.

I'm a bit of a purist. If there are text objects from pre 12 solutions
which were defined as buttons then I take the time to convert objects
into their proper type.

This will really matter when you want to take a solution to Web Direct.

[Denis Somar]

I agree and have learned that in approaching WD.  Unfortunately, steering the monolith is more difficult in FM than it should be so this has been my convention to manage that transition, thus far.

D

--
You received this message because you are subscribed to a topic in the Google Groups "FileMaker Development Standards" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fmstandards/HYkfDR0gzgE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fmstandards...@googlegroups.com.

[john renfrew]

Interesting point Matt
Wondering about a hierarchy of parts (max 3) which when read will identify as uniquely as possible.

There is for example colour info, alignment info, page position info, action info, useage info, etc

But, I know that I have a field as a button which copies the email address to the clipboard so it can be quickly used somewhere else, but if you use modifier keys it puts the cursor into the field

To be fair, this is styled as a field that matches those around it....

John

[Mark Scott]

Howdy y’all,

I’m resurrecting this thread based on Bob Shockey’s and Adam Ward’s excellent DevCon sessions, this afternoon and yesterday, respectively, on using styles effectively.  I previously thought that style-naming conventions were perhaps somewhat lower priority, but am now reevaluating that assessment.  Bob showed an example of a complex solution, using quite a number of carefully named custom styles, that he was able to “re-skin” with a with just a few clicks, thanks to strict adherence to a style-naming convention.  In mere seconds he converted the whole solution from a dark theme to his lovingly crafted “Buffy Blue” theme, in response to a client who requested a dark-text-on-light-background approach.

This wouldn’t have been possible without all the styles in his old theme having identically named counterparts in the new one.  Same applies when you take things a step further and start talking about sharing themes between files or among developers.

Also, Bob, Adam, and Andrew Paulsen (who also presented on themes, styles, and the rendering engine yesterday) all stressed the importance of moving locally applied formatting into custom styles, and then into the theme itself, which can result in a considerable proliferation of named styles.  This is especially noticeable for things like text objects, where you’ll likely need different formatting for field labels, descriptive text, merge fields, alert text, headings of various sorts, and on and on.  All agreed that the increased cost in size of the stylesheet that has to move across the wire is minor compared to the cost of keeping that same styling local.

I’ll try and chime back in later with a bit on the naming convention that Bob Shockey uses; it’s probably not something we would adopt as is, given its extensive use of initialisms for object types, but may be a good springboard for discussion.

Also, lest I forget, please check out Bob’s amazing (and free!) tool for visualizing styles, called StylŌ.  (On the surface, it appears to overlap just a bit with the tweak tool in Matt’s Theme Studio, but I think their purposes are largely different and complementary.  StylŌ doesn’t work with clipboard data, let alone tweak it for pasting back into a FileMaker layout; it’s strictly about creating, visualizing, and organizing the myriad styles that make up a comprehensively thought-out custom theme.)

Best from San Antonio!

Mark

[Jeremy Bante]

I'm a-quiver with anticipation waiting for your update on the conventions folks were using!

[Mark Scott]

The only convention I saw presented was Bob Shockey's. He uses a two-letter prefix representing the FM object type, then separates the rest of the style-name words with underscores.  

His prefix-set rolls objects that share custom styles (e.g., rectangle, rounded rectangle, and oval) together, e.g., "SH(ape)":

TX - Text

EB - Edit Box, Scrolling Edit Box

DD - Drop-down List

DC - Drop-down Calendar

PM - Pop-up Menu

RB - Radio Button Set

CB - Checkbox Set

BN - Button

PO - Popover

TC - Tab Control

LN - Line

SH - Rectangle, Rounded Rectangle, Oval

CR - Container

SC - Slide Control

CH - Chart

WV - Web Viewer

PL - Portal

BG - Layout Background

PT - Part (any)

An example of his naming system, for Edit Box (taken from the theme included with Stylo):

EB_main_focus

EB_title_header

EB_non_edit_list_view

EB_non_edit_list_ital

EB_edit_field

EB_edit_area

I've got some feelings both for and against elements of this particular approach, but my thinking is in flux right now.  Hopefully not for long, as I'm working on a theme that I want to use for a large project. Curious what others think.

Changing topics a bit, there were a couple best-practices offered for developing and sharing themes:

Both Bob Shockey and Adam Ward (engineer of the custom styles and themes code) strongly suggested doing all development of a theme in one place, so that you don't end up with multiple, conflicting versions of the same theme (in different files) or of a style not yet saved into the theme, on different layouts. Adam recommends that that should be a dedicated file maintained exclusively for development of the theme. Bob, too, favored that approach, while also proposing the alternative of using a dedicated layout in a production file for that purpose. 

Adam also recommended always using the Import button (in either Manage Themes or Change Theme), as the "safer" alternative to copy/paste in Manage Themes.  (I didn't even realize that you could copy/paste themes in the Mange Themes dialog.)  That gives you the option of either updating an identically named theme or adding it as a new theme; copy/paste only supports the latter.

BTW, if you ever get a chance to spend a few minutes talking themes and styles with Adam at DevCon, it's time well spent. He's eminently approachable and loves to discuss the fruits of his labor with the developers who use it.

Mark

On Aug 3, 2014, at 9:05 AM, Jeremy Bante <jeremy...@gmail.com> wrote:

I'm a-quiver with anticipation waiting for your update on the conventions folks were using!

--
You received this message because you are subscribed to the Google Groups "FileMaker Development Standards" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fmstandards...@googlegroups.com.

[Michael Wallace]

I would say that one of the biggest cautions that we should look at is to make sure that the naming conventions do not describe the appearance but rather the function.  Even in the example given there is one overlap into the appearance rather than the function. "EB_non_edit_list_ital"  Might be better ended with "emphasis" as someone may decide to emphasize something with bold as another chooses color and yet another chooses italics.   The basic idea though is that this style should bring some attention to itself.  

There are some really well established naming conventions in CSS that would apply in our decision making with the obvious differences that we cannot nest styles or stack them to get the desired result in FileMaker.

More input on a standard?

Mike

[Jeremy Bante]

Mike, I agree that style names are better off being about the meaning of the style rather than the implementation.

Can you share here some of the CSS conventions you mentioned, and how you think they might apply for FileMaker styles?

[Mark Scott]

Absolutely agree, Mike, re names that encapsulate functionality rather than appearance. It's virtually essential for theme portability and solution re-skinability.  

I noticed the specific example you cited, as well as a few more in Bob Shockey's slides, that seemed to miss differentiating between form and function. That said, his general approach has some nice things going for it and is growing on me, at least as a potential starting point for refinement.

The FMSTDS conventions have been guided by a couple overarching philosophies, so any new naming system has to be judged against those. One is that we (generally) avoid non-self-explanatory representations such as abbreviations: when in conflict, readability trumps conciseness.  (There are exceptions to be found, of course.) Another is that each namable element type takes a shape that is instantly recognizable without regard for the context (in the general sense of that word ;-) in which it's read. Given "People," "Schedule » People," and "People: Customer List," we instantly recognize which is a table name, which a TO name, and which a layout name. To that end, capitalization, underscore use, etc., are important considerations.

"EB_non_edit_list_view" fails the first of those principles by introducing a set of abbreviations for FM object type. Mostly, they're not too arcane, however, and they do help with the second principle: in spite of the underscores (currently reserved mainly for field name types, e.g., "id_Customer," and "unstored_invoiceCount"), these names appear, to my eyes, sufficiently different from anything else in the standards to pass the instant recognizability test.

The question was raised earlier in the thread as to whether to prefix object type at all; Matt points out that it's implied when you look at styles in the Inspector. One argument in favor, however, is that FileMaker (consistent with general behavior across the application) prohibits duplicate style names even for different object types. Thus, one cannot create a "Required Value" style for both edit box and drop-down list, but "EB_required_value" and "DD_required_value" are allowed. Also, prefixes can help capture the idea that certain object types share custom style sets. For example, rectangle, rounded rectangle, and oval, all being shape ("SH") objects, share the same set of custom styles. More subtly, edit box, and edit box with scrollbar are semi-discrete objects in that they (can potentially) have different default styles, but share one set of named, custom styles. Another subtle example is that the two drop-down objects actually use edit-box styles when the "Include arrow (/icon) to show and hide list (/calendar)" option is unchecked.

Just a bit of food for thought…

Mark

[Matt Petrowsky]

On Mon, Aug 4, 2014 at 11:21 AM, Mark Scott <sco...@peds.ucsf.edu> wrote:
> One is that we (generally) avoid non-self-explanatory representations such
> as abbreviations: when in conflict, readability trumps conciseness.

As Mark referenced in his reply. I'm personally not a fan of "over
doing it" when it comes to naming - although, this may not seem like
it. ;) Simple is often easier and all those acronyms requires
deciphering.

Since object types are implied and FileMaker does handle the
segregation for you, the simple approach would be to come up with
something that indicates stylings which are not implied. Further to
that, styles are also often solution specific. So, to that end I am
opting for this type of example. Using a Field object as an example...

Scrolling 14pt Body

I can't obviously provide all attributes within the name, but I need
to provide enough to myself in order to determine what is implied. In
the case above, I know the style is typically used on an enterable
edit field. The font size allows me to differentiate between another
style with a different size. I don't just use the literal size though.
If the design will vary then I will use something like this.

Scrolling Big Body

(yeah, yeah, sounds the title of a geek dance hit)

The "Big" allows me to differentiate against "Medium" or "Small".

The "Body" provide the indication of where it's predominantly used.
Not limited to just the body but allows me to determine it's general
use. I might then have.

Scrolling Medium Header

The extension to this is then to allow for solution specific identifiers.

Scrolling Big Body Notes
vs.
Label Info Header Stats

Where the above is now much more specific and the "Notes" tells me the
field comes with some coloring and/or integrated icons (base 64 image
data)

You can also determine, based on the name that Label identifies a text
object instead of a field.

So the formula follows

Attributes | Differentiator | Relative Use | Solution specific identifier

Let's try another

Checkbox Mobile Body

This seems pretty clear that it's a field, formatted as a checkbox,
used for mobile (probably larger text) and something the user likely
interacts with.

One thing to remember is that styles are typically created/used based
on locations. Both relative to layout parts and as to where they
appear within a solution. The more complex a solution, the more
locations there will be. So a location identifier becomes pretty
important in order to gain a distinction between style use.

I'm also still evolving my styles use as I work on more and more projects in 13.

One thing to note is that using long style names doesn't make your CSS
for Web Direct any smaller. It's a small performance hit and
hopefully, FMI is doing style sheet optimization for Web Direct.

However, because I really dislike acronym naming conventions, I'm
typically not afraid of longer styles names.

That's my input for now.

[Michael Wallace]

Some of the things listed already are common practices for CSS.  Readable>Succinct. General page location and hierarchy are important considerations title_header_big vs just header_big.  As Matt mentioned, big is better than 14pt.  I agree with another post though that says that they were leaning to having the same duplicate naming conventions for FMPro as for FMGo and Web Direct so that each would have its own style.  This allows for a layout to have its use quickly changed by changing from the Pro version of the theme to the Go version of the theme.  

I do have a question on how you think we should handle individual items like if we have a group of fields and in the style only the top of the top field and the bottom of the bottom field is rounded.  I would like to avoid the local overrides if possible because I would like to be able to reskin everything by simply applying the new theme.  Ideas?

Mike

[Mark Scott]

I would define separate styles for top (rounded in upper corners), middle (no rounding), and bottom (rounded on bottom corners) fields in the group.  The cost of extra styles in the stylesheet is almost always less than the cost of local formatting.  (This exact example came up as a question in one of the sessions.)  

Also, if you later decide to change the degree of rounding, solution-wide, say from a 5-pt radius to a 3-pt radius, it's just a couple clicks, and stylistic integrity is ensured.

Mark

[Mike Duncan]

The problem is that if you create a style for every combination of attributes, your list of styles will go on for a very very long time. Also, if the naming is too long, then it gets hard to read in the inspector. You end up with stuff like

Right top corner rounded 12 Pt bold left align
Right top corner rounded 12 Pt bold center align
Right top corner rounded 12 Pt bold right align

I have tried to create some base styles and not get to upset about a little local formatting where needed, it's practically unavoidable. I just wish we had better inspector tools, I know I'm not alone there... give us a similar inspector that you have in webkit or firefox.

It would be nice if they'd followed CSS a little closer and allowed you to assign more than one style to an object. That way you could assign one style that handled the rounded corner and another style that handles font, and another to assign alignment, etc... that's how it's done in CSS. 

 

On Mon, Aug 4, 2014 at 4:59 PM, Mark Scott <sco...@peds.ucsf.edu> wrote:

I would define separate styles for top (rounded in upper corners), middle (no rounding), and bottom (rounded on bottom corners) fields in the group.  The cost of extra styles in the stylesheet is almost always less than the cost of local formatting.  (This exact example came up as a question in one of the sessions.)  

Also, if you later decide that you'd rather reduce the rounding, solution-wide, from a 5-pt radius to a 3-pt radius, it's just a couple clicks, and stylistic uniformity is ensured.

Mark

On Aug 4, 2014, at 1:44 PM, Michael Wallace <michael...@rcconsulting.com> wrote:

I do have a question on how you think we should handle individual items like if we have a group of fields and in the style only the top of the top field and the bottom of the bottom field is rounded.  I would like to avoid the local overrides if possible because I would like to be able to reskin everything by simply applying the new theme.  Ideas?

[Mark Scott]

Good point, Mike. 

In fact, one problem with the Inspector that came up in a couple DevCon sessions is that, while you can tell if local formatting has been applied (by the red button and the asterisk), you can't tell which properties were edited vs. which are part of the style (or theme default).  Actually, that was put forth as another reason, beyond the couple I mentioned in my reply to Mike Wallace, for moving (almost ;-) everything into custom styles.  (Keeping styles documented is one of the goals of Bob Shockey's Stylo tool, although I haven't yet formed an opinion about whether that tool will ultimately prove useful.)

Mark

[Jeremy Bante]

Now that we've had time for this to settle a bit more for each of us, does anyone have any new ideas for theme and style conventions? I thought listing some elements from iOS and OS X design resources might give us some more granular vocabulary to play around with:

## Elements from the iOS UIKit Catalog

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/UIKitUICatalog/index.html

- Tint color — "Views have a tintColor property that specifies the color of key elements within the view. ... The tintColor property is a quick and simple way to skin your app with a custom color."

- Action sheet

- Activity Indicator (indefinite progress indicator)

- Alert view (custom dialog)

- Collection view

- Image view

- Label

- Navigation bar — top bar in a typical iOS app for navigating a series of hierarchical screens

- UINavigationItem — a screen in an app

- topItem — the current screen in an app, displayed as the current location in the center of a navigation bar

- backItem — the screen that users navigate back to when moving up the hierarchy of screens, displayed as the left button in a navigation bar.

- Picker view — spinning wheel for selecting an item from a value list or a date or time

- Search bar

- Scope bar — allows user to constrain the scope of a search entered in a search bar

- Prompt text — text appearing directly above a search bar providing directions, visible even after the user has entered search text.

- Tab bar view — bottom bar for app-wide navigation in typical iOS app

- Table view — single-column list of data, often with cells appearing in separated groups

- Cell — A single row of data, which can include an image, text label, and detail text label. Used for both table and collection views.

- Index — for quickly navigating to a particular point in a long table, such as an alphabet scroll control

- Accessory or editingAccessory — an image on the far-right side of a cell,

- Disclosure indicator — a right-pointing chevron indicating that the cell has a separate screen with more detail or options.

- Detail button — "i" in a circle information icon, for showing information, not for accessing editable fields.

- Editing control — appears on the left of a cell when a table view is in an edit mode, for either deleting or inserting a cell.

- Reordering control — (hamburger icon) appears on the right of a cell when a table view in in an edit mode

- Control — anything a user can click on to do something

- Page control — horizontal series of dots representing different pages, such as in a FileMaker slide control.

- Segmented control — what's called a "button bar" in FileMaker

- Text field

- Clear button — deletes all text in a field, typically appears as an "x" icon in the right of the field.

- Slider — only possible via web viewer in FileMaker

- Stepper — a +/- pair of buttons for increasing or decreasing a value in small steps.

- incrementImage

- decrementImage

- Switch — a horizontal toggle provides users on/off control

- Button — some standard options include:

- Add - plus icon

- Edit

- Done

- Cancel

- Save

- Undo

- Redo

- Compose — square of paper with pencil icon

- Reply — left-pointing curved arrow icon

- Action — square with up-pointing arrow "share" icon

- Organize — folder icon

- Trash

- Bookmarks

- Search — magnifying glass icon

- Refresh — clockwise arrow icon

- Stop — "x" icon

- Camera

- Play

- Pause

- Rewind

- Fast Forward

- Page Curl

## OS X Human Interface Guidelines

https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html#//apple_ref/doc/uid/20000957-CH3-SW1

- Window

- Document window

- App window — main window of app that is not document-based

- Panel — floating window, not modal

- Tool panel (palette)

- HUD panel — transluscent panel that allows some content behind it to show through the panel background.

- Dialog

- Document modal — prevents other actions only within the scope of a document, typically displayed as a "sheet" attached to the applicable document window. User actions are still possible outside the dialog for other areas of the same app.

- App modal

- Modeless

- Disclosure button/triangle

- Action button — right-most button at the bottom of a dialog, usually the default button

- Alert — dialog for when there's a problem

- About window

- Pane — separate views in a preferences window

- Source list (sidebar)

- Inspector — section of a window or a separate panel for showing and editing attributes of a selected object.

- Button

- Push button — text only

- Gradient button — icon only, performs an action closely tied to some sub-view it is attached to, such as a plus button to add a row to a portal.

- Scope button — has selected and not-selected states

- Help button — question mark icon

- Action menu — pop-up menu for selecting actions rather than data entry, uses gear icon and no label

- Share menu — action menu for sharing

- Command pop-down menu

- Path control — i.e. a breadcrumb

- Color well

- Image well

- Determinate progress bar

- Indeterminate progress bar (e.g. barbershop pole)

- Asynchronous progress indicator (activity indicator)

- Level indicator

- Capacity indicator

- Rating indicator

- Relevancy indicator

- Text

- Static text field — not user-editable

- Text input field — user-editable

- Token field

- Search field

- Column browser

- Split view — combines sub-views in a single window

- Group box

- Widget (in Notification Center Today view, or dashboard)

- Notification

- Banner

- Alert

- Badge