Tab Panels: Seen, Unseen and Simulated

Last time we examined some of the nuances of tab controls, both visible and invisible. Today we’re going to extend the exploration to include simulated and, in demo 5, genuine tab interfaces for layout navigation.

1386121787023

Today’s demo files:

What you will see in demos 1 through 4 are not tab controls, but simulated folder tabs used for navigation purposes. Like many FileMaker developers, I tend to reuse things from project to project, and recently it dawned on me that I had been building my faux tab interfaces in much the same way for nearly 20 years.

Given the new design surface in FM 12, it was time to take a fresh look at how I was doing things. But first let’s take a look at the old method.

Demo 1

Note the selected rectangle object below… I call it a “retaining wall”.

1386121786057

If we slide the retaining wall down, we see that each “tab” is a white rectangle.

1386121787174

The four rectangles began life as buttons, because I wanted the embossed outline, but I didn’t want the entire button to become highlighted when pressed (i.e., the pre-12 behavior), so I ungrouped to remove the button definition. Note that the foreground Expenses tab is placed in front of the horizontal black line (a.k.a. “horizon line”), but the other three rectangles are behind it. Additionally, I placed a 2-point “border buffer” (white line) over the bottom edge of the Expenses tab.

1386121787095

Also, I was having trouble getting the labels positioned properly, so I removed them from the erstwhile buttons, and placed them on top as independent text objects, as per “Receipts” below.

1386121786735

And since I only wanted the “above-the-horizon” portion to highlight when pressed, I placed a clear rectangle (a.k.a. “button mask”) over the visible area of the tab, and defined that as the button. You might think I would have been able to simply resize the background of the text label, but, at that time, I could not get the alignment of the label within the block to cooperate. So, I went with a separate invisible rectangle.

1386121787154

And to recap, here’s how it looks in browse mode.

1386121787023

Whew, what a lot of work to create a halfway decent illusion… and that was just for rectangular tabs. It was even more work if one preferred rounded corners on one’s tabs…

1386121788044

…in which case one would overlay a series of clear horizontal lines (shown in red here) of increasing width, to approximate the curve, group them, and define the group as a button.

1386121787577

I used the term “illusion” a moment ago, and for the illusion to be seamless there can be no awkward shifting of screen elements as the user navigates from layout to layout. The simulated tab control must appear to be rock solid. If you’re switching between form (e.g., Expenses) and list (e.g., the other three) layouts, you may want to use a three point layout offset like the one shown here: What’s Right With This Picture?

Demo 2

At any rate, here we are in the FM 12 era, and demo 2 showcases the simplified method.

1386121788504

Each tab is a 100 x 27 point button, with the text centered both vertically and horizontally. The foreground tab line spacing height is set to 16 points…

1386121788039

…and the background tabs are set to 19 points, ensuring the text labels on all tabs will line up perfectly.

1386121787418

The “pressed” style of the buttons is assigned via the Inspector, and note that in FM 12, styles only apply to the visible portion of the buttons, so no separate “button mask” is necessary. (That’s a major change from the pre-12 behavior, where the entire button would highlight when you pressed it.)

1386121787673

We still need the “horizon line”, “retaining wall” and “border buffer” we saw in demo 1, but clearly this method has fewer moving parts than its predecessor, and from a UI standpoint is equally effective.

Demos 3 & 4

So what if we want to restrict layout access based on user privilege? In the remainder of today’s demos…

  • Managers are allowed to access all layouts
  • Employees are allowed to access the “Accounts” and “Employees” layouts
  • Trainees are only allowed to access the “Accounts” layout

Demos 3, 4 & 5 have accounts, passwords and privilege sets like so:

1386121788485

(Note that there is no Admin account. The full access acccount is Manager/Manager.)

Of course we aren’t going to rely on the user interface to enforce security. Here are Custom Record Privileges for the Trainee privilege set:

1386121788407

And here are Custom Layout privileges for Trainee…

1386121788449

…and the Employee privilege set is similarly configured. So whatever we come up with at the layout level will just be UI icing on a solidly secure cake.

Demos 3, 4 & 5 are configured to auto-login as Manager (reminder: this is the [Full Access] account), but you are welcome to re-login manually, or via the Privilege popup menu…

1386121788695

…which triggers this script.

1386121788214

Here’s what we see when we log in as Employee…

1386121788158

…and here’s what we see when we log in as Trainee.

1386121788513

Demo 4 reveals what’s going on behind the scenes…

1386121789338

…an invisible tab control with three tabs corresponding to the three privileges. This is essentially the same technique that was explored at length in my previous article so I won’t go into detail here (except to reiterate that when the tab controls are actually invisible, there will be nothing to click, and they will only be navigable via the “Go to object” script step).

Since the Expenses and Receipts layouts are only accessible to Managers, we don’t need to use invisible tab controls there. The only place we need them are on the Accounts and Employees layouts. Also, since Trainees do not have access to the Employees layout, we only need two tabs on this layout’s invisible tab control.

1386121789392

Demo 5

Demos 3 and 4 use a combination of invisible tab controls and visible simulated tab controls. Can we dispense with the simulation and use visible tab controls to drive the layout navigation? Yes we can. Our final demo of the day shows this technique in action. And of course one big difference is that tab controls fire on mouse down, whereas buttons fire on mouse up, so the navigation will feel snappier.

1386121789162

As per demos 3 & 4, only Managers are allowed access to the Expenses and Receipts layouts, so we don’t need to use invisible tab controls on either of those. But here for the first time, we are using a genuine tab control to drive layout navigation, and this works thanks to an OnTabSwitch trigger…

1386121789049

…which invokes this script (yes, there are more elegant ways to handle navigation; we’ll get into that another time).

1386121789434

Since I only wanted the foreground tab to have a red label, I applied conditional formatting to that tab.

1386121789450

We still need a “retaining wall” to obscure the body of the tab control. Here’s what we see if we slide it down.

1386121789069

As per demos 3 & 4, we use an invisible tab control on a couple of the layouts to flexibly determine which visible tabs the user sees.

1386121789258

And I think that’s enough for today.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s