Here is a technique for advanced FileMaker users. Most modern solutions allow you to have multiple windows open showing different information. There is a simple way to manage those windows.
How many times has this happened to you? You are working on a database, and you need to open a new window. Maybe you have a list of clients and a detail view of one client. Then you have to open a third window to view some invoices for that client. Now you have three windows named <<Solution>>, <<Solution>>-1 and <<Solution>>-3. You go to the window menu to go back to the list view; which window do you choose?
This is the exact scenario that happened the other day when I walked into a client’s office. Dave turned to me and said, “Isn’t there a better way to do this? I can never remember what window has what info in it! I cycle through 1, 2, 3 then check any other windows open hunting for my info.”
What I really want, is a way to name windows that is flexible and doesn’t have to be maintained. There is no built in menu command or function exposed directly to the users called, “Rename This Window”. However it is possible to build this. Since there IS a script step that can be used to rename a window.
Here is the script that I came up with:
The first step grabs the current window name, so I can present that to the user. This way they know exactly what window they are renaming. Then there is an if statement in case the user wants to cancel. Finally the business of the script, renaming the window.
One thing to keep in mind, the consequences of giving the user this ability. In one solution I have a home button. This button navigates you home. Once I gave the users the ability to change window names, sometimes navigating to the home screen gave funny results. Imagine walking by a computer, on the home screen with a window name of ‘Invoice # 444 for Joe Blow”! To make up for this, I updated the ‘GoTo Home’ script to also rename the window to the solution name. You may also want to ask the user if they also want to close all the other windows.
I try to make this script the first one in the scripts menu. This makes it easier to select for the user.
So now when opening multiple windows, I can name each one. Each window is named with what it represents! See this example;
File this with those other nice tips that your users won’t even realize are there. But design paradigms like this make systems more robust and easier to use.
Published on
July 1, 2011.
Everyone likes a good story, even one that relates to a database. When you are working with a database that is shared among different users you will eventually see this scene, or perhaps experience it yourself:
You, or someone else, are staring at the computer screen looking at a record that has changed since the last time you looked at it and you mutter to yourself, “Who changed this record? This is not the same as the last time I looked at it!”
An audit log is like looking at a record through time. It will let you trace any changes that have been made on a piece of data in your database. For example, in a contact management system an audit log will let you see address changes over time for a particular person. You can use an audit log in an ordering system to track changes made to each invoice over time. It is also an important tool for determining workflow processes. Remember the old adage, “who what when where why and how”. Who changed this record? What data was changed? When was it changed? Why was it changed?and How? An audit log can tell you all of these things (except probably the “Why”).
Continue reading ‘Tracking Changes in Your Database’
Published on
April 29, 2011.
I’ve been posting about a few principles that have helped me minimize the pain of understanding complexity in my own code. See part 1 of this series where I briefly discussed leaving yourself and others notes about the “why” of your design decisions. And see part 2 for discussions about simplifying your code.
Continuing with the movement towards simplicity; whenever possible make functions and scripts single use and encapsulated. We can think about breaking functions (or scripts) down into their smallest useable parts as simplification, or we can talk about it as encapsulation. We broke down a confusing custom function into separate parts in order to improve readability. What we also gained was some compartmentalization and modularity. It’s difficult to separate the two principles of simplicity and encapsulation.
Continue reading ‘I’m just a stupid developer, don’t confuse me… part 3 of 3′
Published on
April 28, 2011.
See part 1 of this series where I briefly discussed leaving yourself and others clues about the “why” of your design decisions.
The second principle I want to talk about helps with the “how” and “what”.
It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.
- Albert Einstein
Or how it’s more often paraphrased:
Make things as simple as possible, but not simpler.
Take the time to make things simpler. This is much more about the “how” and “what” of programming.
Continue reading ‘I’m just a stupid developer, don’t confuse me… part 2 of 3′
Published on
April 27, 2011.
Our human brain has the amazing capacity to remember and understand the things we do. What’s more amazing is our brain’s capacity to overestimate how much it has the ability remember and understand the things we do. My average shelf life for remembering how my code works is about two months. That is to say if I don’t touch a part of an application for up to two months, I can jump in and get back to work, no problem. After that I have to study it a bit and get my bearings again. The longer I go the worse it gets. Your mileage may vary, but no one can escape this problem.
There are a few things that have helped me minimize the pain described above, which I’ll be posting about over the next couple of days.
Continue reading ‘I’m just a stupid developer, don’t confuse me… part 1 of 3′
Published on
August 6, 2010.
Recently I was on a family trip to Pittsburgh. We were walking around the campus of Carnegie Mellon and I saw this memorial brick;
It got me to thinking about some of the monster databases that I have had to take over for clients. When I take over a project, often I am spending a great deal of time just trying to figure out what the developer was trying to do.
Our earlier posts on this blog are generally concerned with improving the user experience(better printing workflow) or getting more out of your data (One Report two sets of summarized data). Today I would like to return to that lowly person, the developer. Anything that I can do that can make my job easier will make be a better developer and ultimately make my customers happier. Or as my grandfather would say to my grandmother, “What would you do if I got hit by a bus?” Continue reading ‘Speak your Mind. Using Comments, part 1.’
Published on
July 16, 2009.
My wife, 3 year old son and I hopped in the car at 6:30 this morning and headed north from Philly to NYC. I was headed to PauseOnError; Andi and Sam were going to hang with our Brooklyn friends, some of whom we hadn’t seen since we moved from Brooklyn in 2007.
I arrived at the Ace Hotel – a gorgeous, hipsterish old/new world style hotel on 29th street – close to 9 AM and squeezed into the crowd in Molly Connolly’s room for the intro session. I then spent the better part of the day hopping around the various sessions and talking. The mood was pretty festive and congenial, like partying with a bunch of geniuses.
Continue reading ‘PauseOnError Day 1′
Here is a technique for advanced FileMaker users. Most modern solutions allow you to have multiple windows open showing different information. There is a simple way to manage those windows.
Speak your Mind. Using Comments, part 1.
Recently I was on a family trip to Pittsburgh. We were walking around the campus of Carnegie Mellon and I saw this memorial brick;
It got me to thinking about some of the monster databases that I have had to take over for clients. When I take over a project, often I am spending a great deal of time just trying to figure out what the developer was trying to do.
Our earlier posts on this blog are generally concerned with improving the user experience(better printing workflow) or getting more out of your data (One Report two sets of summarized data). Today I would like to return to that lowly person, the developer. Anything that I can do that can make my job easier will make be a better developer and ultimately make my customers happier. Or as my grandfather would say to my grandmother, “What would you do if I got hit by a bus?” Continue reading ‘Speak your Mind. Using Comments, part 1.’