Tag: Claris

As FileMaker developers we pride ourselves with our ability to perform amazing feats of behind-the-scenes scripting and calculation dexterity. But, sometimes we forget that functionality is only half of a good design. The other half is what the user sees and interacts with. This half is the UI/UX.

For this discussion, let’s define the user interface (UI) as the workspace that contains objects (as well as their themes and styles) for data viewing and manipulation. These objects encompass everything from edit boxes to drop-down lists to tab controls, button bars, portals, web viewers, and so on.

The user experience (UX) is defined as how a user interacts with the UI. Foremost of UX is workflow, which is how a user moves from one object to the next in a logical fashion. UX also includes the layout’s “intuitiveness”, which is how easy (or not-so-easy) it is for a user to understand what they can do, where they can click, and what they can edit.

A good UX makes a user’s job easier. It reduces the learning curve of your app which reduces training time. It also increases “buy-in” from users. If they like what they see (UI) and feel comfortable using your app (UX), it increases its value to your client.

Let’s take a look at a few tips to enhance that comfort level. Below are six tips to consider when designing a good UX:

Workflow:

Never leave your user stranded.

When a user opens an additional window such as a report window or navigates to another layout to perform a task, always make sure to build obvious navigation tools so that your user can get back to where they started.  Leaving a user stranded on a dead-end layout can be confusing and frustrating. A user needs to feel at ease to explore areas of the app while always feeling comfortable that they can go back to start over.

Good workflow includes circular navigation, not linear. Linear navigation brings a user down a singular narrow path from one layout to the next but often leaves them stranded at a dead-end.

Circular navigation incorporates buttons to circle back to a previous step or go all the way back to the beginning to a dashboard or main menu to start over. It also allows a user to go forward to the next logical step, or branch off to a different section of the app.

Design the workflow of layouts to “read” from top to bottom, left to right. 

Place data that the user needs to know first in the upper left area of a layout. 

For example, on a form/detail layout of a “people” record, knowing the name of the person is most often the first thing a user needs to know. So, place the name fields in the upper left area so that the user “reads” that data first.

The additional data fields should flow in a cohesive way so that the user doesn’t have to jump their eyes around the screen to gather the next logical piece of the puzzle.

In action areas, place action buttons in the lower right or centered across the bottom.

Keeping with the concept of “top-to-bottom, left-to-right”; in dialog windows, card windows, popovers, tab panels, and slide panels it is best practice to place the action buttons in the lower right or center bottom of the action area. 

Clicking an action button such as “Okay”, “Cancel”, or “Save” is usually the last step your user will take when in an action area. Your user’s eyes will flow from top-to-bottom. So, their eyes will be positioned to see the action buttons when they need them. Placing the action buttons elsewhere forces the user to hunt around for the buttons.

Intuitiveness:

Use tooltips. 

Always add a tooltip to a button that is an icon only, one without text. Icons can be interpreted different ways by different users – and developers. Many users are afraid of clicking blindly in fear of breaking something. To help users feel more comfortable clicking a button, add a tooltip to buttons, especially icon-only buttons, to make sure your user knows what a given button will do.

Add the Self tooltip to long text fields. Fields that can hold long strings of text sometimes get cutoff. A simple help is to use the Self function as the tooltip calculation. Then when a user hovers their mouse over the field the entire field contents is displayed for a few seconds. This allows a user to know there is more data to read.

In addition, using the calculation box for tooltips allows us to provide extra data that may be pertinent to a field but does not need to take up real estate on the layout. For example, hovering over a person’s name in a list view layout could display a tooltip that provides that person’s title, rank, phone number, or other additional info from other fields.

Disable Browse Mode access on calculation and summary fields

 Users new to your app can get confused and distracted from their task when they click into a calculation field and attempt to edit data. FileMaker will provide a dialog box with a message saying the field is not modifiable. This can cause them confusion as to what they are supposed to do next and derail their task at hand, slowing down their work.

Since a user cannot edit data in a calculation or summary field, why allow a user to click into the field to begin with? In the Inspector (on the Data tab, Behavior section) simply uncheck Browse Mode for field entry. When a user clicks on the field nothing will happen. They will immediately learn that field does not need to be edited without a scary distracting error message.

Add Close buttons to all Popovers and Card Windows.

Many users can get stuck after opening a popover because they do not know how to close it. They do not know that simply clicking outside the popover will close it, it is not intuitive.

Always add a simply close button – with a tooltip – in the header/title area of popovers. A single script step of Close Popover will do the trick (use the Close Window (current) script step for card windows). This makes the popover more user-friendly because it is easier to understand what the user needs to do. 

Building a close button only takes a minute or two and can then be copied and pasted into every popover to maintain a consistent look and function.

Consistency adds to intuitiveness since after learning it on one layout, users will more easily recognize the same functionality on other layouts.

Conclusion

These simply techniques help put a professional polish on your app. They can improve your user’s experience which in turn helps them do their job more comfortably and more efficiently.

Claris’ FileMaker platform offers a number of great avenues for keeping your data secured. One of these avenues is to secure the database itself using Encryption At Rest. To be as un-technical as possible, this keeps your data in an unreadable form that can only be opened with a secure key. So, if the database is stolen, the thief would have no way of opening and reading or extracting your data without also have your secure key.

We recommend encrypting ALL FileMaker databases with sensitive data.

How to encrypt a database?

The first step is to get the database onto a local computer. If the database is currently hosted using FileMaker Server, it must be closed and then removed from the server. You will then Open the Developer Utilities. (If you do not see Developer Utilities, it means that you do not have advanced tools turned on. There is a checkbox in FileMaker Preferences to turn this on)

You will select the file you want to encrypt, what folder you would like the encrypted file to be saved to and then select Solution Options.

Here, you will select Enable Database Encryption, enter a shared ID (or just leave the default one), specify one of the database’s Full Access FileMaker accounts and then enter your encryption key. (Make sure to keep the key on file. Once a database is encrypted, the ONLY way it can be opened is by entering that key). You can then choose whether or not to keep Open Storage, which relates to FileMaker’s container data. There are some situations where you may want to keep the container data open even though the database is closed. This should be determined on a case-by-case basis.

Alright! You now have an encrypted file. You will notice when you try to open it, it first asks for the encryption key before it asks for your username and password.

How does it work with FileMaker Server?

Now, you will upload the database back to your server. When you do so, you will see this alert:

When you open up your admin console, you will notice that the file is indeed closed.

You can open the file through the admin console, and when entering the encryption key select “Save Password” or through the command line as shown below.

By saving the password, when you close and open the database, it will open the database without asking for your encryption key.

How does the new FileMaker Server 19.1.2 Update Relate to this?

With the new FileMaker Server 19.1.2 release, you can now run two new system-wide scripts automatically through FileMaker Server’s script schedule.

The first script, SYS_Default_PurgeTempDB, clears the temporary cache of the server. If your server is not restarted often, this temporary cache can become quite large and affect the performance of the server. Now with this script, it can be cleared weekly, daily, or even hourly if needed.

The second script, SYS_Default_VefiryAllDB, will verify all databases on the server to confirm that none are corrupted. During the process, the server will close each file, run the verification, and then open the file back up. The server, however, can only open an encrypted file if its key is saved to the server using the command line script. Because we want this schedule to be run automatically, it is necessary for the encryption key to be saved to the server in order to run this script.

Has FileMaker’s dropdown list functionality left you wanting more?  While adding a drop down has the benefit of being quick to implement, often it’s behavior can leave a lot to be desired.  Not being able to filter the list by any word in a string (typing out the second word instead of the first for example) or being able to style the look of your drop down can be huge drawbacks.

Here’s a technique that is both powerful, speedy, and quick to implement.   By Creating a “text tree” in any table (as pictured below) we can utilize FileMaker’s relationships which supports multiple values (separated by carriage returns) to find records by our own specified amount of letters, words, or even data from multiple fields.  This technique doesn’t involve finds, and given how versatile it is, we can place it anywhere in our solution — allowing the user to find data without leaving the layout. For example, finding a name only knowing the last name.

Setting this up is fairly straight forward.  The first thing we’ll want to do is prep the data by adding a text field to our target table. In this demonstration we will be adding a full_name calc field to the People table. Our new text field will be an auto-enter calc breaking down each name into a text tree, like above.  This code can easily be copied & pasted into any solution. You just need to modify the input field.  It can also be modified to support longer word lengths, more words, and multiple fields within the local table.

Note: If you’re adding this to existing data, be sure to “refresh” the data, perhaps with a ‘Replace Field Contents’

Now that our data has a satisfactory text tree, let’s create two global fields in the table of the Layout we intend to use. The first field g_SearchField,  will be the field on the layout as the field the user will be typing into.  The second field g_Search_forRelationship will be used in a relationship to our Text Tree, displayed below:

Now, all that’s left is to place a portal on your layout. It’s context should be the table where your text tree is. Then you put a script trigger (onObjectModify) on your search field, which will move what the user types into your secondary global.  It will then refresh the relationship live while the user is typing without having to commit the data entry global.

Your trigger only needs to be a simple set field like so:

There you have it, please feel free to download the file and test it out yourself!

[wpforms id=”59476″]

As part of Claris’s new open release approach to FileMaker 19, the latest version of their platform now supports CentOS Linux. This includes all the features and benefits you’ve come to expect from FileMaker, as well as the most recent updates (you can read more about the most recent version of FileMaker here). While FileMaker Server was previously available for Windows and macOS, this marks the first time it’s been available on the open-source Linux system in many years.

This is especially exciting because a considerable number of businesses utilize Linux for both cloud hosting and their on-premise servers specifically for its security and stability.

In a press release, Claris noted that FileMaker Server for Linux includes key features like data integration via OData and the FileMaker Data API, server-side script schedules and plug-ins, and custom backup schedules. 

Claris also stressed that regardless of which operating system you’re using FileMaker on, you’ll be able to enjoy their new features like faster upgrades and better performance.

This year has seen Claris continue to innovate and bring major, requested features to their platform, and they show no signs of slowing. Have any questions about how you can create FileMaker applications for your business? Reach out to us here.