Skip to main content

More about why I like the new navigation part in FileMaker Pro 14

I myself didn't completely "get" the navigation layout part at first. In this post I want to clarify a few things about the benefits of this new feature.

The new navigation layout part in FileMaker Pro 14 and FileMaker Pro 14 Advanced differs in two significant ways from the header/footer parts we've had since forever (and which we still have in 14):

  • Navigation parts don't zoom
  • Navigation parts don't scroll out of sight

Well, it's a little messier than that, in reality. Let me elaborate on the messiness of it first, since the messiness may have some impact on why navigation parts took me a day or two to "get".

First potential confusion: objects in navigation parts don't zoom, but they are not completely inflexible. If you grab the edge of the window and make the window wider (I'm not talking about zooming the content, I'm talking about actually enlarging the window) then any objects in a navigation part that are anchored to both sides of the layout are going to stretch. It's not an exception in any way to the idea that nav parts don't zoom, but it's worth being clear about.

The other slightly messy aspect of my description about what's distinctive about navigation parts has to do with scrolling. It's correct to say that the navigation part doesn't scroll out of sight (so the objects it contains don't scroll out of sight).  But it's not completely clear when that does and does not make a difference vis à vis headers and footers, because the header layout part never scrolled out of sight either in list or table view and it doesn't in FileMaker 14, either. But it did and does scroll out of sight in form view. So the no-scroll feature that is 50% of the point of the new navigation part is pertinent mainly to form-view layouts.


Why?

Now, why would you want to use navigation parts? Or to be explicit about it, why, if the user zooms the window, would you not want the objects in the nav part to zoom, too? And why, if the user scrolls the window, would you not want the objects in the nav part to scroll?

The real use-case practical value of the navigation part is (in my opinion at least) easier to see on an iPhone than it is on a computer or even an iPad. I have no inside info, but I wouldn't be at all surprised if navigation parts have been given to us precisely because FileMaker is now putting more of its eggs in the FileMaker Go basket.

Because navigation parts don't scroll

With the help of a navigation part, you can now put much more content on an iPhone form layout than the phone's display can show all at once. You just make the layout very tall and ask users to scroll. This is great news. iPhones generally are used in portrait orientation and in that orientation, the iPhone's content area is normally not very wide. This is true even on my iPhone 6+. On computers, which by default have displays that are wider than they are tall, we can build nice form layouts with fields organized into multiple columns, say, home address in the first column, work address in the second. This is harder to do on the  iPhone. On the iPhone, when you to put more stuff on a layout, you mainly have to go down to find the extra space.

Anyway, I can now design for the smallest iPhone I'm concerned about, without worrying about the height of the layout. I don't have to mess with UI tools like tab control objects (which I find a big ugly even on the computer and which certainly do not work very well on an iPhone) to organize lots of fields. Now, I just move fields down to the bottom. Most iPhones have about 5" of vertical display for content. I can use 1" for my fixed UI widgets and, by putting it in navigation part, lock that stuff on the display so it's always there. Then I can create 9" of content in a body part. If I later need to add something, I can just add another 1" at the bottom. The user simply scrolls down to get to it.

This is exactly what computers with GUIs have done forever with their menus. The menus don't scroll. If they did, we'd lose 'em and we don't want users to get stuck thinking they've zoomed up the river and they're now without a paddle. As I was writing this post in Blogger, the menus in Chrome as well as the Blogger toolbar stayed fixed on screen the whole time. As I worked on this post, I scrolled up and down as needed to change my view of its content. It's what we're used to doing.

Let me digress for a sec and ask: why didn't FileMaker simply add a no-scroll parameter to the old header and footer parts? Could have been a checkbox in the body part setup dialog: "Don't scroll header in form view." The reason they didn't is precisely related to the mistake I made in my review, which I corrected in my previous post. Sometimes you need both a navigation part (for buttons and such) and a header (for something else). By providing the navigation part as a separate design element instead of simply adding a parameter to the old elements, FileMaker's programmers have given us a more flexible set of options.


Because navigation parts don't zoom

The no-zoom property of the navigation part is equally valuable. Presumably you will design your buttons so they're large enough on the iPhone to be useful at 100%. If you've done much iPhone / FileMaker Go work you probably have found as I have that buttons need to be bigger than they do for the computer. The mouse (or the computer trackpad) is simply a more accurate pointing device than your finger on a touch screen. But sometimes, some users wish to make the data entry area of an iPhone screen larger or smaller. You know this surely from using your smart phone to browse websites that haven't been optimized for mobile. If you are presented with a form, you might have to zoom in a good deal to find the 'commit' button. At other times, a user might like to zoom OUT to get a bird's eye view of a FileMaker Go layout. This would be useful, for example, if there is in fact a long form layout that caused the user to scroll down. A well-designed long, scrolling layout should probably have a "scroll to top" buttons sprinkled tastefully here and there. But you never know what users will do: somebody might simply prefer to do the two-finger pinch thing to zoom out. And if they do, I want my UI control widgets to stay the same size and remain in the same place.

In short, I think these are fantastic, really useful enhancements. And if you don't like them, you just keep using headers and footers and no harm's done.

On my wish list

I'll conclude by adding that there's one thing that isn't in FileMaker 14 that I wish was there: a vertical navigation part. Button bars can be oriented vertically, and you can now design a form layout that has (say) a vertical button bar on the left for various actions and a portal in the main area of the window to act as a pseudo-list view. But if you do this, because the button bar isn't placed in a navigation part, you're not going to enjoy the no-zoom or no-scroll property of nav parts. What I would like almost more than anything else to see in FileMaker 15 is vertical navigation parts that can be placed on the left and/or right, so we could create layouts with utility panes.

Comments

Popular posts from this blog

Setting up OAUTH with Google in FileMaker 16

Setting up OAuth with Google in FileMaker 16 Posted by William Porter Intended audience: Intermediate to Advanced FileMaker developers Date of publication: 2017-June-06 Updated: 2018-June-06 One of the many exciting features in FileMaker 16 (released May 2017) is OAuth or Open Authentication. Open Authentication allows users to connect to a FileMaker database after authenticating with an external (non-FileMaker) account. At the present time, FileMaker supports OAuth through Google, Amazon and Microsoft. If you're a developer there are two main questions to answer. First, should I do this? And second, how do I do it? I'll answer the first question later. It's important. But the other question-- How  do I setup OAuth?--is answered in the attached document. I wrote this tutorial with the help of my friend and colleague Taylor Sharpe of Taylor Made Services , also here in Dallas. We provide step-by-step instructions on how to get your users authenticating in

Virtual List Basics

The concept The basic trick behind virtual lists is the wonderful GetValue() function. GetValue() takes two parameters: A list of return-delimited values A number specifying which value in the list to get For example say you have a field in a single record called “List of Values” and it contains the following:    Apple    Boy    Cat    Doorknob    Elephant    Fish When that record is selected, GetValue ( MYTABLE::List of Values ; 4 ) will return “Doorknob”. The brilliant idea is to replace the list of values stored in a field with a list in a global variable . The basic implementation, part one Create a table called VIRTUALLIST. In it, define these two fields: VALUE NUMBER: a number field Value_calc: calc field returning text value, = “GetValue ( $$VALUES; VALUENUMBER )”. Make sure that this value is an unstored calculation. Go to the layout for the VIRTUALLIST table and create some records. Later you can create hundreds or thousands, bu