If you're a user of a spreadsheet or any other program that displays information in tabular format, you're probably familiar with a quick sort technique. You can usually click a column header and the data within the column will automatically sort in some way. You can sort of (pun intended) do this within a table view layout in FileMaker as well, but it's not as simple as a click. You have to right-click on the header and navigate a Byzantine labyrinth of menu options before you get to what you hope is the expected result. Wouldn't it be nice if you could provide the typical user experience to yourself and your users within your custom FileMaker app? Well, you can...by naming a few fields/objects on your layout, creating a global variable or two and some buttons that run a script. But we're putting the cart before the horse; let's start at the beginning.
As consumers, our active involvement in product development is basically limited. Some of us might participate in a focus group or share customer feedback to help product managers learn more about product pain points and/or ways to improve usability. But generally, product decisions are based on projected financial and utilitarian outcomes. For example, when we're in the market for a car, we don't work directly with Tesla to design a bespoke car. We usually select from a set of preconfigured models and maybe a list of add-on options to get as close as possible to our ideal driving experience but it's doubtful that we'd reimagine the vehicle as a whole.
Even though products aren't custom made for consumers, we still maintain the power of choice. Products either meet our needs or they don't, so we can keep them or not. Nonetheless, if we have very unique or specific needs, we might have to consider a custom solution. Custom design changes the dynamic of the traditional consumer-producer relationship as the customer plays a very active role in the development process. Sometimes roles become a little confusing or uncomfortable as the responsibilities shift unpredictably throughout the process. Naturally, we're going to unpack roles and responsibilities from a custom software development perspective because we have a lot of experience there. But, the idea can apply to any custom project.
We've shown you how to add custom headers to a CSV file. Custom headers are useful, particularly for end-users, because they provide intelligible header names when downloaded FileMaker files are opened in other applications. We developers don't always use intuitive field names when we're in the heat of custom app development. It's usually a bunch of geeky gibberish only the coder can understand. FileMaker 18 actually simplifies our custom header export process a bit, thanks to a few of the new script steps that this version offers.
Before we begin, it might be helpful to review our FileMaker 18 file-based script steps blog post, particularly the section that discusses how to read, write and manage external files. This will give you a good foundation before taking a look at this more advanced topic.
Image features are pretty common within FileMaker apps. We've had the ability to store images and other types of files in container fields for quite a while. Usually, we leverage that capability to build image modules for our clients. Having developed several of these myself, I can tell you that users generally want to be able to do at least three things:
- Save the images in FileMaker
- View a thumbnail of the image
- Customize the size of the image
Of course, there are different ways to accomplish these requirements efficiently.
I admit, designing a calendar in FileMaker is an involved process. Nonetheless, it's a common requirement, so I’ll walk you through the process step by step. I'm going to piggyback on our previously published post, but for this calendar, we're going to specify Monday as the start of the week as opposed to Sunday.
Of course, there are several different ways that we can structure a calendar. One option would be to create 42 separate relationships and portals to represent events for each calendar day. Why 42? There are seven days in a week and we need six rows to cover the number of potential weeks in a month, 7 * 6 = 42. Also, you’d have to create 42 fields to store the calendar days that would then be used to set up the relationships between the calendar and event tables. This approach can make managing edits or updates cumbersome for developers because of the volume of records.
The Nebraska Forest Service (NFS) first approached us to help them reduce redundancies and centralize their data so that they can focus on protecting their natural forest resources and educating their community. In addition to providing resources and training for volunteer fire departments, hosting workshops for the public and offering grants to communities, schools and other organizations that help manage and protect the trees and forests of Nebraska, NFS also tracks the number of wildfires that occur across the state. Many state and federal agencies require wildfires to be reported. And, recording the wildfires as well as the response efforts of the local volunteer fire departments helps NFS coordinate and provide a variety of federal and state grants to those volunteer fire departments.
FileMaker, Inc. has given us a new XML tool to help us developers now and hopefully even more in the future! This new functionality may be confusing at first as we've had the Database Design Report (DDR) for a long time and we can save/publish that as XML too.
Repeating fields have a long and somewhat controversial history in FileMaker. If you want to start a heated discussion with another FileMaker developer, start one about repeating fields! Some developers love them, some hate them and then there are some like me, who appreciate them as another tool in the belt to be used to accomplish functions that would be hard to do without them.
If you started building FileMaker applications from scratch in more recent versions of the product you may not be very familiar with repeating fields and probably have never used them. You may even have an understanding of what they are but have never found a need to use them. If you've been using FileMaker for a long time or have taken over a legacy solution, chances are you've had to deal with them.
When you get more than three FileMaker developers in the same room, it’s inevitable that at some point in the conversation they will start reminiscing about “the good ol’ days” of FileMaker and trying to one-up each other with how long they’ve been using FileMaker (since 2.1 in my case).
As we anticipate the release of FileMaker 18, I've gotten a little nostalgic about the FileMaker application and naturally, about some of the major milestones of The Support Group.
The FileMaker Platform gives you plenty of options for exporting data out of your app. You can export files as text or even a separate FileMaker file but in our experience, the most common export format is Excel. It's pretty easy to export data out of FileMaker into Excel; the tricky part is customizing the headers of the exported data.
Why would you want to customize the headers? You may want to customize headers so that they're easy for the user to understand or to make them consistent with field names in other systems. For example, some of our developers like to group the "name" fields in a contact database by having them all start with the text "name" – nameFirst and nameLast instead of First Name and Last Name. So when we export that data natively from FileMaker, the column header will be nameFirst, not First Name. I won't get into why we do that here; that's a whole other blog post about field FileMaker naming conventions.
