ISO FileMaker Magazine

If you’re new to FileMaker, or even an old hat at FileMaker development, then it’s always nice to understand how to use your own tools. In this video, I start the process of walking through the standard Inspector palette.

By taking a bit of time to understand each of the unique areas of the Inspector palette, you may gain a tip or trick in terms of what you can do with this critical part of FileMaker development. Spend a few minutes to watch this video about the first of the four sections of FileMaker’s Inspector palette.

Heading back into our series on the Custom Function database, there’s always an opportunity to explore yet another area of using FileMaker to create solid solutions. This video focuses on the fact that we’re storing canonical data which we want to leverage, yet not alter.

When you store data for any type of templating system or data which acts as the basis for further variations you have a number of choices in terms of how users interact with that data. For this solution we want the user to be able to easily modify the data but not the original data. Instead, giving the user their own copy allows them to keep the original and have their own custom modifications as well.

Watch this video if you’d like to learn more about using FileMaker’s validation options in order to facilitate controlled data duplication. That’s exactly what we’ve done in part 9 of the Custom Function database.

Planning out your UX (user experience) obviously requires less work on a smaller solution than it does within a larger solution. I guess that goes without saying, but no matter what solution you start working on, it will always seems to grow and expand to add new features and functionality.

While you can’t always plan for what you don’t know is coming down the road, you can certainly work with what you have in front of you. Trying to prototype and account for how your solution will be used is what your primary focus should be.

For the most part, this comes in two different forms. There’s the build it, then test it camp, and the get feedback/suggestions, then build it camp. In this video I start with the process of building first and then asking for feedback. This is typically my first approach because I simply lack the resources to take the other route.

The big trick with creating your UX is the fact that when users start using it, they establish mental pathways of how to get things done. It’s very hard to change things on your users once a “certain way” of doing things has been established.

So, the best approach is to think really hard about how users will use the software and go as simple and minimal as you can. Don’t try to put everything in within the first release. You can always add more to a user interface and keeping things simple makes it really easy to get feedback when people start asking the inevitable question “can it do this?”.

There comes a time when every great database must acquire a brand new look. This really applies if you’ve never even given your database a user interface or you’re looking to revamp the one you currently have.

The best place to start, I find, is with the “primary objective” of the interface. In fact, I would argue that it’s best to focus on the number 1,2 and 3 aspects or goals of the user interface. I do this for every single layout being designed. By doing this before you start to throw fields on the layout, you afford yourself the ability to keep things simple before getting too complex. Many of the most popular products and software interfaces start out super simple.

Some of them become bloatware, like many of the Microsoft Office products, but they had a good foundation when it came to how users have learned to use them.

In this video, we take a look at starting the user interface for our Custom Function database. I provide some foundation and the basis for how I approach the process and showcase how I implement based on the decisions I’ve made.