Scared Cow Burgers For Dinner Tonight

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.

What Happened?
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.

• Portal-Centric
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.

What Changed?
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.

What Now?
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
Thank you for admitting in your session that Javascript scared you, and it was tough to get started. I needed to hear that, and it made it easier to make good decisions about my next steps.

• 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.

Advertisements
Posted in Uncategorized | Leave a comment

Shomi Finally In Development

I have finally committed to developing Shomi (Show-me) as a full-blown product. Shomi is going to help developers introduce the magic of FileMaker to potential clients, as well as help developers estimate projects better than ever before. Shomi is the foot-in-the-door that we’ve always wanted.

I started down the road of building it with native FileMaker fields, but it proved to be too costly in terms of the number of objects (1,000+ on one layout). This slowed FileMaker down even in a local copy, and made maintenance highly annoying.

Enter our Dallas FMPUG meeting. When demoing the concept, the suggestion was made to convert it to using a webviewer for displaying the fields, and so I started down that path. A few weeks later, I have successfully auto-built the fields portion of the Employees form in the demo. And it’s flippin’ sweet.

I hope to have a movie up soon about how it works, but until then, here are some screen shots that give you a little peek under the hood.

Screen Shot 2014-06-17 at 9.35.15 AM Screen Shot 2014-06-17 at 9.35.30 AM Screen Shot 2014-06-17 at 9.35.40 AM

Posted in Uncategorized | Leave a comment

Time Travel And MVC

  Yes, yes we’ve seen this meme before. But it’s very relevant to my time of late.

Sometimes to try new things, one has to ignore the rest of the world for a bit. This creates a kind of time travel experience all by itself. It’s the kind where you look up and say, “It’s been six months?!?!?” I feel that way right now. I can’t believe my last post here was that long ago.

Similar to Olympic training but far less sweaty, I’ve been focused deep in my secret lab for the past few months working on a system that pays homage to the ideas and theories that get knocked about in our FileMaker what-if discussions. What I’ll be writing about in the next few installments is the portable model-view-controller backend I’ve developed in FileMaker Pro 12. Not only is it MVC, but it also has the ability to create and maintain a raw data repository off to the side, for those needing entity-attribute-value records as well.

This project has been brewing in my head for a long time, and I’m happy to have kicked it off. But suffice it to say it’s going to take some effort to get the methodology posted for others to play with and review. It’s been hard enough to get this thing rolling, and the idea of having to refine it before presenting it to the FileMaker community is exhausting. So I’m inviting you into the middle of open heart surgery. Expect it to be messy!

I’ve posted a very preliminary explanation of what I’m doing in this pdf: MVC-EAV In FileMaker. There are some hopeful declarations in it that I wish to be true, but I’m just now testing. Time will tell.

I must give credit where it is due. All I’m doing is trying to implement what I have learned from Ernest Koe, Corn Walker, John Sindelar, Matt Petrowsky, Agnes Riley, and many, many others. What I’m doing isn’t so much new as it is a “follower feedback” moment: “Hey, guys! I heard you say such-and-so. Is that what you were trying to say?”

I do think, though, that if I’ve done my homework, we might end up with a nice set of tools to play with and point at and fix and tweak, leading to some really great techniques for our community.

I will do my best to update this regularly. Please understand that I’m both a developer and the Executive Director of my local Chamber Of Commerce, so time is tight. But I’m determined that it’s time to start talking about this. I’m forcing myself onto the stage before I’m completely done in an effort to create some momentum (a.k.a self-discipline) to document this as fully and as quickly as possible.

Your encouragement and happy thoughts in my general direction are appreciated!

More to come…

Posted in Uncategorized | Leave a comment

Setting A Variable In A False If Script Step

This is a little trick I’ve just learned, and I’d love to know who has been using this trick.

Each If or Else If script step in FileMaker is evaluated to determine whether its true or false. This means that you can define global or local variables in a Let ( ) statement in the very first IF statement, and those variables will be available for the rest of the script, or in the case of a global variable, until FileMaker is closed, or until the variable is given another value.

[Click here to see a movie demonstrating this idea]. Watch the data viewer to see when the variable gets defined:

  1. The variable starts out defined from the previous test
  2. It gets cleared by the first script step
  3. It gets set by the falsely evaluating first If script step
  4. It skips the result of the first If statement, now with the variable $$Test defined as “Hey!”
  5. The value of the variable validates the Else-If step, and fires the “True!” dialog.

This could really help reduce your code load, and the places you have to edit that code later.

Posted in Uncategorized | 4 Comments

Getting A List Of Fields From XML

I wrote this custom function for extracting a list of fields from a given node of XML. Tell the function which node you want to look at, what character in that XML to start at, and the enclosing node tag, and it extracts all of the fields for you in a tab-delimited list:

The explanation.

The reason I built this was because I found myself needing to loop through the fields of an XML node without knowing beforehand what the specific XML structure was within the node I was interested in.

To download the actual text of this function, click here.

UPDATE 4/17/12 11:35 am – I found an error in the code and have reposted both the image and file with corrected code.

UPDATE 2: 4/20/12 7:10pm – I ran into an out of memory scenario with the updated code. So…third time’s a charm! New code posted.

Posted in Uncategorized | Leave a comment

Returning The Cursor To A Field

I don’t know if this is a previously documented technique (if so, please let me know in the comments), but I discovered a way to handle those nasty return-to-field if statement trees that we have to build when performing finds triggered by OnModify script triggers.

Here’s the scenario:

  1. User types in a find field.
  2. OnModify script trigger runs the find script.
  3. Results are updated.
  4. The cursor is returned to the field the user was typing in, so they may continue typing.

It’s that last step in the process that’s annoying.

Right now in FileMaker 11, we have no “Go To Field By Name” script step. So to make the cursor return to where it’s supposed to be, we typically will do this:

Set Variable [ $ActiveField ; Get ( ActiveFieldName ) ] Perform Script [YourFindScript]

If [ $ActiveFieldName = “Field1” ]
Set Selection [ “Field1” ; End: 10000 ]
Else If [ $ActiveFieldName = “Field2” ]
Set Selection [ “Field1” ; End: 10000 ]
Else If [ $ActiveFieldName = “Field3” ]
Set Selection [ “Field1” ; End: 10000 ]
End If

Of course this works, but what if you edit field names? What if you need to add new fields? It gets pretty tedious updating this type of code.

I realized I could use one of the Design functions to make this super easy to maintain.

Add a layout to your solution that contains only your find fields. This layout can be in any file, because the design function we’ll be using calls the file by name.

My layout looks like this:

This layout contains all the fields I use for my find scripts.

Make a new script whose sole purpose is to return the cursor to the appropriate field. I called mine, “Return To Field”.

NOTE: Any find script that calls the Return To Field script must have this step at the beginning:

Set Variable [ $ActiveField ; Get ( ActiveFieldName ) ]

My find script:

My find script. Note that the key field Users::zzk_DataListRecordNumbers is actually a return-delimited list of numbers representing the number of records I want to see in my virtual list.

Once we know what the active field is, and we’ve performed whatever script we want to, it’s time to take the user’s cursor back from whence it came.

I use a custom function called TrimMV, which stands for Trim Middle Values. The purpose is to remove the trailing return from the MiddleValues function. It looks like this:

If you can’t (or don’t want to) create a custom function, you can use the entire function calculation in place of the TrimMV statement.

Here’s what my Return To Field script looks like:

This is the script that returns the cursor to the active field

Here’s the script text for one of the If/Else If statements (they’re all the same):

If [ Let ( $Count = $Count + 1; $$ActiveField = TrimMV ( FieldNames ( “Users.fp7” ; “Interface Data” ) ; $Count ; 1 ) ) ]

…where “Users.fp7” is the file in which my find fields live, and “Interface Data” is the name of the layout on which the find fields reside.

Notice that if I want to add a field to the mix, I simply duplicate an Else If/Set Selection pair (as highlighted). The ONLY thing I have to change is the field name in the set selection step. This is because each time the script encounters the Let ( ) statement in the If or Else If steps, it increments $Count, and this causes the value returned by TrimMV ( ) (the MiddleValues ( ) function, to be precise ) to be different than in the previous If/Else If step.

If the field names change, it doesn’t matter. The FieldNames ( ) function will pick that up. If you add a field, be sure it’s added to the script in the order it’s found in the FieldNames ( ) function (alphabetical)**. That’s super important, so I’ll say it again: Your Set Selection [ ] results need to follow the order of the field names as seen in FieldNames [ ] !

This method allows me to use one script for all return-to-field moments, with the least amount of effort.

Give that a try and see if that simplifies your life a little bit.

**UPDATE: 03/30/12 1:55 pm On further review, it looks like that the field order is not alphabetical, but creation order instead. Sorry for the confusion!

UPDATE 2: 4/23/12 11:05 am – While working with the FieldNames function while testing the XML Fields custom function, I found out that the order of the fields returned will be the order that they were put on the layout. That’s super handy if it’s true. I’ll have to test it in this scenario as well.

Posted in Uncategorized | Leave a comment

Modal Conditional Formating

I ran into this problem today, and decided to fix it. In the image below, notice the navigational arrows on the far right side?That black gradient is an image inside a container. When I go into layout mode with “Show>>Sample Data” turned off, this is what I see:

I typically like to show sample data in layout mode unless I know that’s going to be a problem, say, over a slow network or something. But in this case, I’m working with ample data off, and I’d like to see the text there.

I decided to change the text to black, and then use conditional formating to make it white in layout mode:I’m using the function Get ( WindowMode ) to toggle the color change, where mode 0 = browse, and mode 4 = layout (when see from the data viewer in FileMaker Pro Advanced). I simply check to see if it’s 0, and if it is, make the text white.

Here’s the result in layout:

This just seemed like it could be one of those little overlooked but highly useful things for  somebody out there today…

Posted in Uncategorized | Leave a comment