For the last decade and a half, I have used very similar if not the same conceptual conventions in my FileMaker development. But after Devcon 2014, I’m making a major change, and I would like to invite you to review your own methodologies as well. Perhaps, like me, you need to change some habits to become a better developer, and you just need that last little push to commit. Here it is.
So what happened to make me consider killing my sacred cows? The short version is that FileMaker grew up.
I’ve seen this before: as a life-long Mac user, I remember Apple’s OS being called a “toy” OS by the IT types of the day. But then OS 9 grew up into OS 10, and some of those IT types now have Apple laptops these days. The arguments against were taken care of by the maturing of the product.
In a similar vein, many of us have worked for years trying to get FileMaker to do what we can see in our heads, and what our clients asked for. There’s a reason plug-ins came into being.
My needs were simple: rebuild similar-shaped things as fast as possible while working around FileMaker’s features that were designed with a different development model in mind. No worries – I had my own model:
• The Interface Table/User Record
All of my interfaces revolved around the user/interface table. All the user’s prefs and keys were kept there. I could create a new anything from wherever, and know the found sets of every relationship from wherever I was because the context of every UI layout was the center of all relationships. Scripts were reusable (DRY). The graph was clean (squeaky, in fact). The build was fast. navigation was simple. I had it all, and it served me well since 1999.
• Vertical Navigation Buttons
Another reason I used this method is because I wasn’t using any of the traditional FileMaker tools anyway. The one vertical market solution I had back in the day had vertical navigation buttons down the left side, so List View was useless to me. I might hold the record for not using List View for fifteen years straight (feel free to correct my world record if you’ve done better).
I never use table view, either. I know – frown if you must. I never had a client need it, so I never needed it. But the now-out-of-style vertical navigation buttons were a main driver in me finding my own way without using FileMaker-native tools.
Those portals weren’t just any portals, they were multikey portals. Yes, there is a performance hit, but only if you haven’t helped your client refine their found sets to something manageable and realistically workable. Sorry, but I have yet to meet a human that does effective work by scrolling through 20,000 records manually. It’s a waste of time.
So, I limited my multikey portals to 5,000 records or less (10,000 in extreme cases), but traditionally, no more than a few hundred. Usually, it was less than a hundred. As a result, I had to be super-passionate about my clients’ business models. I had to know everything about why they were finding and what they needed to see. And I’ve always had happy clients because of it.
• Who needs the status bar?
I’ve been a status bar hider for ages, which means I hid the status bar and scripted everything. My clients never needed to scroll through records, they needed to focus on the one they selected – from a portal of course.
Plus, I could use whatever icons for new, delete, show all, etc. Very import a few years back to make a polished UI. Or at least the appearance of a polished UI. I also remember when flaming gifs represented a “polished” UI. Which it wasn’t, and now we know better.
We all use far fewer icons now, or at least far less complex ones. My job is to communicate to the user what possible actions are available, not demonstrate my sick Photoshop Skills </Napoleon>.
• Preventing FileMaker from being FileMaker
My philosophy was to work out every nuance of my client’s world so thoroughly that they never needed FileMaker to be FileMaker. They just needed to do business, and I made sure they did. It was amazing and satisfying to buck the norm, and never have to apologize. And I still won’t. Necessity taught me how to grok my client’s business model and fast.
But I’m starting a new project, and I won’t be doing any of that now. And it’s totally unnerving. But it’s going to be worth it.
In a word, everything. FileMaker’s abilities, user expectations, UI conventions – which didn’t change as much as solidify. As a community, we’ve even been paying attention to development habits of other disciplines, and utilizing their best practices where it makes sense.
And then there was mobile. Mobile is what started me rethinking what I was doing, as it should for all of us. If you combine the explosion of mobile with the opinions/habits/discussions of developers I respect, the emergence of Modular FileMaker, and the native abilities now in FileMaker 13, you have the perfect storm for a new way of developing. Perhaps “refined” is a better word than “new”.
If I’m honest, many of the practices I had were because I was trying to make development as fast and as modular as possible. I think in another few years without outside input I would have ended up at the same place that Modular FileMaker has, but it would have cost me a lot more to figure it out. There’s a reason it has taken the best minds in a joint effort to wrestle with the concept and figure out how to do it. And another kudos to the community for getting together and doing it.
So now, it’s the grand experiment. I have lots of questions. What is it like to jump into modular development? How will Perform Script On Server change my approach? What will I discover by changing things up (which is typically how discoveries happen)?
As I work through some of these questions, I’ll come back here to kiss and tell. Maybe it will help you get past your own fears and do something new/different/better. I hope so.
Some shout-outs are in order here:
• John Sindelar, Seedcode
• Todd Geist, Jeremy Bante, et. al., Modular FileMaker
Modular Filemaker has been a lot of hard work, and it’s obvious. Excellent work, and thank you! I’m all in. Thanks for being both diligent and inviting all at the same time.
• Don Levan, Vanguard Custom Software/FM Design Studio
Don will calmly talk you off of any work-around ledge, and help you see the problem you’re trying to solve, and the most native way to solve it within the guidelines of general programing best practices. And that’s on top of his eye for great design. (Full disclosure: I work for Don, but it’s still all true. ;^).
• Nicolas Hunter, FileMaker, Inc.
That guy is flippin’ passionate about doing great things in and with FileMaker. He did his best to take the fear and mystery out of UI development – specifically on iOS in his session, but with obvious application on desktop as well. I saw very clearly that all my development habits were built around preventing or working around things that aren’t issues anymore. His session convinced me that I am now loosing speed in development because of my outdated approaches.
• Ross Macintosh, Datamate Solutions
Forever and always encouraging me to level up anytime I can. Reminds me to be fearless and be great as often as possible.
There are a lot more people that have influenced me, but these specifically came together at and around Devcon in a way that opened my eyes to what FileMaker actually is currently, without all the baggage of my experiences with it from the past.
I would end by saying I’d like to hear your thoughts, but not really. Time is valuable, and I’d rather you go spend that time on learning new habits and building great things. You can tell me all about your adventures at Devcon 2015.
I’ll post mine here.