Our team worked with FileMaker to build several template files to help businesses launch specific functionality. These files encourage workplace innovation without requiring extensive development experience.[/callout_small]
File Foundation Built for You
At the core of the FileMaker templates, you’ll find a solid, consistent design, clean look, and strategic user interface and user experience. Look under the hood and you’ll find much of the same. That wasn’t by accident. Our team spent a great deal of time determining how these apps should look, how they should flow, and most importantly, how to develop them.
Unlike starter solutions, these files are meant to be dissected, understood, learned from, and actually built upon. I’d like to go into some detail about some of the best practices we hit on as we worked through our design and development process for them.
User Interface & User Experience Best Practices
User experience depicts how the user perceives certain features of an app. Consider usability, efficiency, and the overall flow of the app. User interface describes the overall look and style of the app. We made our goal to build these solutions to feel and operate much like the apps we enjoy every day.
For example, see how navigation between different layouts moves throughout the app. Rather than have a navigation bar on each layout, we took advantage of one of FileMaker’s newer features, card windows. We created a navigation layout that displays as a card window. Card windows, introduced in FileMaker 16, allow you to layer windows within the same window, a great feature to take advantage of when designing file navigation. It gives the user more space on each layout and eliminates layout clutter. It also allows for easier manipulation of the navigation menu. You only have to make changes to a single layout versus changing every layout that includes the navigation menu.
We used a small button with the hamburger icon in the upper right corner of each layout with a script attached that opens the navigation layout in a card window. Because you have control over the size and position of card windows, you have the power to display the navigation layout anywhere within the window. We chose a slender window that appears on the far right on the screen. Setting the Height within the New Window script step to Get (WindowContentHeight), we are able to allow the navigation window to always keep the same height as the active window. Using the Get (WindowWidth) and subtracting the navigation menu’s layout width (in this case 320pt), the navigation window will always open to the rightmost side of the window.
The finished product is a clean, functional navigation window that only displays when the user needs, giving the main layouts a sleeker look and feel.
Another important aspect of user experience we focused on when designing these custom solutions is the use of consistent colors throughout the app. We aimed for the workflow process to come as naturally as possible to the user, without confusion or hesitation.
One way of doing is to guide the user through the workflow with specific colors. This means selecting colors for each different type of call-to-action, whether a button or clickable text. We kept the colors simple for these files and selected a single color for “positive” or next action steps, and then muted colors for “negative” or canceling action steps.
For example, a user creating a new time entry in the Job Tracking file has two options for the user once they finish entering in time, “Close” and “Delete”. The natural action , “Close”, displays a brighter color for that button (in this case, blue). The user may still need the option of “Delete”, but it shouldn’t be called out to their immediate attention. Therefore we built a more muted color (for this case, gray).
This part of the user experience carries throughout each of the core files and their additional build-ons. For any action we wanted to guide the user through or call an action to, we used blue for buttons and hover states. Any buttons or text we wanted to keep as an option but steer the user away from as the unnatural next action, we used a shade of gray.
Setting a design theme at the beginning of the development process allows you to easily apply a consistent design throughout the entire solution. You can use a custom theme, one of your own design. or an inherent FileMaker theme. It should include consistent colors, fonts, and styles set for each type of object.
Setting a design theme at the beginning of the development process allows you to easily apply a consistent design throughout the entire solution.
We recommend choosing a single theme at the beginning of your design process and avoid making changes. This eliminates design inconsistency during development.
For our team, this process took a few iterations, but we landed on a custom theme, with styles for all layout parts, shapes, buttons, portals, edit boxes, and more. Although this required a bit more work in the beginning, this saved time and stress as we worked through designing each layout. Every added object had a style, so we didn’t need to think about how to style each object or worry about ensuring we kept things consistent layout to layout.
Scripts and Coding Consistency
We also recommend setting scripting and coding standards at the beginning of a project. Define and name scripts, fields, tables, variables, etc.
We spent significant time on this for the template files as well. Our team defined a set of standards and naming conventions before development started. Consistency tremendously helps testing, QA, and future rework needs.
Similarly, you should strive for consistency in the organization of scripts and scripting itself. Folders organize your scripts and make them easy to find. Each script within the core files has a header section providing details for each script. This includes the purpose of the script, the context, parameters passed to the script, what the script returns, and any notes that might be useful for future users. This helps keep scripts clean and easy to read. It also gives anyone wanting to manipulate the script information to help them understand the script and its purpose.
Commenting throughout the script also helps others understand the logic put behind each step or set of steps. When developing larger solutions or working with multiple developers, it’s easy to forget the thought process put into the script at the time. Having comments eliminates that “What was I doing here, again?” thought. The result is an end product that not only looks and operates professionally but is clean and well-laid-out under the hood as well.
We also consistently used the native FileMaker feature of global variables for manipulating layouts throughout our design. As I mentioned before, we used card windows throughout the files, not only for navigation but also for a way to quickly input or manipulate data for different records.
For instance, in the Job Tracking template, we used a card window to input new and existing time entries. Instead of creating two near-identical layouts with only slight differences, for example, in the header name, we used global variables set in the calling script that are then used on the layouts as merge variables that display the appropriate header text for that action. The header for the two actions displays as, “Edit Time Entry” and “New Time Entry”, which in layout mode shows as “<<$$globalField>> Time Entry”. When the user triggers the script to add a new time entry, the global variable, <<$$globalField>> is set to the word “New”. The user then sees the card window displaying the layout with the header “New Time Entry”. This allows the use of a single layout for multiple actions.
The same concept is used for each call to action button on these layouts. Buttons used to create new records will have different actions than buttons used to edit or delete records. Following this same Job Tracking example, the case would be editing existing time entries versus creating a new time entry. Each of these different actions requires different buttons. By using global variables, hiding conditions, and layering the buttons on the layout, you can continue to use the same layout for multiple actions. This keeps the design process simple and the number of layouts to a minimum.
The last native FileMaker feature great for enhancing both user interface and user experience that I’d like to share is the use of Master-detail layouts. This is new to FileMaker 17. You can now create portals that work with the a found set of the current table. This saves time as you no longer need to create self-join relationships and additional scripting to accomplish this.
The resulting layout allows users to click through a list of records and see a record’s details all in one layout. This works great for displaying things like staff or client details. Using Master-detail layouts became standard for the core files. This takes them to the next level, both visually and functionally.
Ensuring a Strategic User Experience in All FileMaker Solutions
Taking time in the beginning to focus on consistent design and organization pays off in the end. It reduces your development time and ensures a professional looking final product.
For more information on how to use the templates, check out Sara Severson’s post.
Our team follows these best practices in all of our development. If you would like our insights in taking your FileMaker solution to the next level, contact our team to learn more.