We are very excited to announce that our Karbon framework will be released at the FileMaker Developer Conference in Dallas next week.

Karbon is an open-source framework for building ambitious custom FileMaker applications for the modern era. By “ambitious” we mean complex business applications of significant value that will be around for a while. If you have a simple problem, Karbon will just frustrate you and get in your way. But if you believe, as we do, that a thriving business requires a flexible and robust custom application, then Karbon maybe what you re looking for. In this post, I am going to lay out why we built Karbon and why we are releasing the core as an open-source project.

Times Have Changed

A lot has changed in the over 20 years that we’ve been developing complex applications with FileMaker. The landscape into which we deploy our solutions bears little resemblance to what it looked like 20 years ago. Technology has changed. Competition has changed. What’s possible has changed.

FileMaker has done an incredible job adapting to changing technology demands. There are few, if any, platforms that can boast 25 plus years of continuous success. The FileMaker Platform is incredibly robust and flexible, and it provides a solid foundation upon which to build custom applications of significance and value.

But what does an application of value and significance look like today? What does it need to do that it didn’t before? What are its characteristics?

Here are some of the high-level issues that we encountered over and over as we built and rebuilt Karbon and worked to solve our customer’s needs over the last several years. A custom application with significant value is going to need to do most of the following.

  • Integrate with other Apps and Handle Distributed Data
    Critical data is now spread out over many apps and services. It is no longer reasonable or even possible to avoid integrating with other apps and services. Even FileMaker Go apps often have to work offline. The ability to exchange data with third party services or an offline FileMaker Go app is an important first step, but without understanding the implications of distributed data, you can quickly get into trouble.
  • Work over the Internet
    Even if you aren’t planning to deploy with WebDirect, your FileMaker application must be built to serve users in across the country or even the world.
  • Allow for Collaborative Development and Maintenance
    It is no longer reasonable to build a business on a custom application that that relies on a solo developer—the risk to the business is too high. Even with the very best application development platform, solo developers or small teams will find it challenging to innovate to remain relevant in today’s fast-paced tech world. Applications must be able to incorporate the efforts of other people effectively, either by employing larger teams of developers or relying on third modules, which can be incorporated quickly and with little effort.
  • Automated Testing of Critical Business Logic
    If you can’t verify that critical business logic works, you can’t make changes to your logic without the fear of breaking your application. If you can’t change your logic, you can’t change your business—if you can’t change your business… well… somebody will come and change it for you.
  • Fail With Grace
    Applications crash. They get disconnected from the server. People close their laptops. Somebody locks a record. The consequences of these kinds of failures on valuable data can be severe. Given the distributed nature of networks and applications, these types of problems are even more common today. A valuable application must be able to handle failures while safeguarding critical data and enforcing complex business rules.
  • Solid, but Flexible
    For an application to have lasting value, the data has to be dependable and lasting. If you build a data structure that can’t be easily changed or adapted, you may find yourself painted into a corner.
  • Embrace Standards
    It is no longer reasonable to invent solutions to problems that are already solved by the rest of the world. All this does is create confusion for new developers coming from other other platforms. Time spent doing it our own way is time we could have spent creating value.
  • Continuous Improvement
    A complex business application today is never complete. There is no finish line. There is no final feature to be added. It continuously evolves. The application and its development process must be able to thrive in such an environment.

Karbon’s Values

We have tried to build Karbon to address or begin to address all of the issues raised above. We should be clear that it isn’t close to “done” (nor will it ever be), but we think it’s far enough along to share with the rest of the world. We’ll have more information and downloads available at DevCon, but for now, I wanted to lay out what we call our Karbon Values. These are the principles that we tried to use while making decisions on our development approach.

  • First Correct, Then Fast Enough, Finally Pretty
    A beautiful user experience that hides fundamental problems in the data model or logic is far worse than an ugly user interface that handles the data logic and data model well.  That isn’t to say we don’t value nice user interface and user experience. We do. We just value data integrity more.
  • Modular Design
    We follow modular guidelines laid out a few years ago. Keeping things in their own box as much as we can within what FileMaker offers us helps us with organizing code especially at the sub-file level.
  • Database Transactions
    We consider any complex logic that updates more than one record broken if it doesn’t use database transactions. Once you learn to write transactional scripts, you are unlikely to want to return to any other method. It’s easy and safe and frankly has fewer moving parts.
  • Separation of Concerns
    This is not the same thing as the Separation Model, although it shares some of the ideas. Karbon has three core files: 1) a UI file, 2) a Controller file, and 3) a Data file. We don’t do this to avoid imports while migrating from development to production. We do this because this makes it easy to make consistent decisions on how to write good code. When we are writing a code in the Controller file we “know” that we are not dealing with user interface, or data modeling relationships. We can focus on scripting solid business logic. When we are in the UI file we can focus on building a good user interface, and not be concerned about building layouts or graphs that are concerned with enforcing business or database integrity rules, as those are handled by the controller scripts.
  • APIs First
    Karbon’s modular design allows building testable and transaction-safe API scripts based on JSON for all critical business logic.
  • Automated Testing
    We have integrated techniques into Karbon and into its supported files that make it easier to write testable code and write tests to validate rules. Tested logic is maintainable logic.
  • Separate Dev and Production
    Working on live files is a recipe for disaster. Separate development and production environments make testing, development and maintenance easier. Data migration issues have been mostly handled by new tools from FileMaker and other 3rd parties.
  • Understand the Source of Truth
    In modern systems, you likely will work with data that comes from third party systems; you need to know which app is considered correct.  Sometimes this isn’t always clear. Take invoices as an example: If you are integrating with an accounting system—like Karbon does with QuickBooks Online (QBO)—then you are likely sending invoices to that system. Once the invoice gets there, it may be modified in QBO; which is one is now correct?  Does FileMaker hold the truth, or does QBO? The answer, in this case, is provably QBO.  Once an invoice lands there, it has impacts on accounting reports and taxes. And once an accounting period has closed, it can’t be updated again from FileMaker. So clearly QBO holds the truth. Understanding that drives your development approach. For example, Karbon (by default) let’s QBO assign new invoice numbers.
  • Better Data Models Last
    Data models like the Party Model take longer to implement, but once implemented they allow the app to scale and adapt and avoid disruptive changes.
  • Spend the Time on The Right Stuff
    User interfaces change frequently. Every year we get new and different widgets from FileMaker that might radically impact how easy it to build a type of layout. For example, FileMaker 17 shipped with a drop-dead simple way to build Master Detail layouts. We’re wasting our time if we spend our time on complex workarounds but should instead focus on investing in transactional scripts with tests—this code likely won’t need to be changed or to become obsolete by FileMaker’s next release.
  • Sharing is Caring
    Sharing is not just about “feeling good” or “giving back to the community,” although those are critical aspects of it.  When you write code that is shareable, you are writing better code. It will have been worth it if the only person you share your code with is your future self.
  • Simple is Better
    Avoid building abstractions that don’t add value. Saving yourself some keystrokes is not value. Try to keep things as simple as you. Create abstractions that provide more value, without making things harder to read.
  • Documentation
    Documented code has a better chance of being successfully maintained then undocumented code. The standard we use also allows us to build code-generation tools.
  • Write Code that Writes Code
    If possible use, write FileMaker applications that can write other FileMaker apps. We proved this works well with Generator, our free utility for generating scripts to interact with JSON web APIs.

OK, But What Can You Do With It?

That’s a fair question. Karbon’s first release is focused on Customer Relationship Management. It handles contacts, activities, and some sales transactions.  It has a fleshed-out Party Model. It has tested transactional scripts for critical business logic. It’s pre-integrated with several APIs like Smarty Streets and Quickbooks Online. It is a solid foundation to build a business on, and we have plan to continue extending the feature set in the future.

We think that some people who are at the beginning stage of a project might just choose to adopt Karbon in its entirety. Others who are already deep into a project will be able to grab large chunks of it and move them into their own system. Still, others may just tear it apart and try to learn everything they can from it. All of those outcomes are a win as far as we’re concerned.

Why Give it Away?

The core of Karbon is open source and will remain free. We think that a project like this has to be free to fully express the values listed above. But it is also a practical approach to a large and complex problem. As we encountered more of the issues outlined above, it became clear we needed a different approach to provide our clients with awesome value. We also needed this for our internal applications. We know that it’s a large and challenging task.

We want feedback and help from people who are interested.  Good software is always widely used, and we’d like others to use Karbon and tell us where it doesn’t make sense, or what’s broken, or what it should do instead. Lastly, we want to help improve the state of the art in the community. We want people in the community who want to build—or already are building—these kinds of projects to have good examples of how to deal with the issues we discussed above. We hope that this will create a cycle of virtuous feedback that will benefit anyone who chooses to participate.

How does Geist Interactive Get Paid?

At the end of the day if we can’t afford to work on projects it doesn’t matter how cool they are. They can’t get done. So clearly, we think that this will pay off in some way.

  • Karbon’s core will be free, but we will likely ship it with several optional modules, which we will charge for. Users can remove them or not use them at all, and not have to pay anything. But if they want to use them they will need to license those parts. For example, Karbon will ship pre-integrated with Quickbooks Online. The module that empowers that integration is called LegerLink and will cost $500/yr.
  • We also have some other modules that will not ship with Karbon but will be built to work with Karbon.  Those modules may carry a fee.
  • We will also offer support, implementation and training for Karbon.

Any Questions?

If you have questions and are going to DevCon come to see us at our booth. If you aren’t going to be at DevCon keep a close watch our various feeds for news during the conference. We’ll be announcing how to download Karbon, and how to get started during the conference itself.
Thanks for your interest. We hope you find Karbon useful.

In less than a week (as of Monday, July 30), I will work with FileMaker developers to learn, or get started learning JavaScript. I can’t wait. While I’m nervous about it, I’m also pumped that we get to talk the power of JavaScript and the power of the web viewer. It’s been my life’s goal (for the past 4 or so years) to get FileMaker folks excited about using JavaScript. We get to take another step in that direction. JavaScript is easy, it is powerful, and it is part of native FileMaker.

If you’ve not yet registered up for the training day (an additional cost), I encourage you to do so. I know it’s an investment. So to make sure your return will be adequate, I’ve described in pretty minute detail what we will do during the morning (there are other great sessions in the afternoon). You can check out the outline here. And you can review this video.

 

The Highlights

On our minds

As we wrap our brains around JavaScript, we’ll keep in mind two questions:

    1. How does our current understanding of FileMaker help us learn JavaScript?
    2. What are the benefits to using JavaScript in our FileMaker development?

In education, these are called “Essential Questions”. These are vital mainly to our adoption of JavaScript as a viable tool in our FileMaker development, and they keep us grounded. As cool and powerful as JS is, we need to remained focused on our client’s data and custom app and needs.

Hands-on

We will spend most of the time in the session:

  • Working with pure JavaScript. We’ll write little functions that accomplish something for data presentation in FileMaker or data manipulation.
  • Exploring how to set up using JavaScript in any environment, for any custom app.
  • Implementing and customizing current JavaScript libraries out there for our use.

I’ve got quite a few files for us to work with. Here’s a few screenshots.

We will spend a lot of our time in here. writing functions that display our data in interesting ways.

We will spend a lot of our time in here. writing functions that display our data in interesting ways.

This file is a reference for what is known about the web viewer object

An example integration we’ll implement.

Join the JavaScript revolution

I encourage you to sign up for this training session. The more FileMaker developers that know and use JavaScript, the more the movement grows and the more awesome custom apps get delivered to clients.

Join me August 6, 2018 at 8:30 a.m. at DevCon 2018 to begin the JavaScript journey.

-Jeremy

Introducing FileMaker Kanban. This tool organizes data such as tasks in a visual way into lanes and cards. It is familiar for users and flexible for developers. The tool provides a full suite of data-management functionality. A FileMaker user can organize the tasks into different lanes, reorder the lanes, edit the data, and add new cards to the board and to FileMaker.

Familiar for the User

Kanban provides a rich and familiar interface for all FileMaker users.

They can clearly see the organization of the tasks as cards on lanes. Further, any user can move the cards or lanes, repositioning them on the board and saving the position back in FileMaker. Cards can be added to the board, data can be edited. There’s a lot of functionality possible.

Flexible for Developers

FileMaker Kanban is just that. It consists of a layout, a web viewer, and some scripts. That’s it.

These scripts allow the developer to make many changes including:

  • Change the color of the board background
  • Remove dragging functionality
  • Remove editing functionality
  • Use data to change the color of a card background

And much more. Find out all the possible customizations.

The scripts that run from the FileMaker Kanban board can be easily disabled or adapted for any custom app.

And the data that generates the board is a JSON object, which can be constructed in any number of ways using just FileMaker. The example uses tables and fields and records, but that’s only one way.

Give FileMaker Kanban a try

Read more about Kanban and download the demo and see how Kanban is easy to use, to implement, and to customize. The demo is fully-featured, though it does limit the data to three lanes, and shows an additional lane with relevant Geist Interactive blog posts.

 

We love Kanban, and we are excited to use it in our daily work. See if it works for you.

 

Lance Brandenberg, Solutions Architect here at Geist Interactive, will present a session title “Testable FileMaker Custom Apps”, focusing on FileMaker testing.

He is a first time speaker at DevCon, and we’re excited that he is another voice in the ‘testing-in-FileMaker’ conversation. He hopes to jumpstart the topic again and get folks talking about it because, as he will argue in his session, FileMaker developers have more of a need to rely on testing.

His session is Wednesday, August 8, from 1:00 p.m. to 2:00 p.m. Here are the details:


Session Description

With the release of FileMaker 16 and native JSON functions, it’s easier than ever to create testable FileMaker apps. We will walk through a simple example of what testing is, and how it can improve your solutions. Most developers have had situations where they need to alter some existing logic, and are concerned that they might alter something with unforeseen consequences. Wouldn’t it be nice if you could ensure that your changes didn’t break existing code? Welcome to FileMaker Testing.

Recommended Background

How to write modular scripts, trapping for errors, and some experience with using JSON objects.

Session Objectives
  • What is Testing?
  • How to write testable scripts
  • Benefits of testing
  • Custom functions needed for testing

To get a better understanding of this topic, I sat down with him over RingCentral and asked some questions. Catch the video here of our interview. You can also read it here.

Here’s our conversation in written form:

Q: Who are you? What experience do you have in FileMaker?

A: Lance is a Solutions Architect at Geist Interactive. He’s been working in FileMaker since 2006. He stumbled into the platform while running a screen-printing business. Like many of us, he decided to get out of that game, selling the business in 2011 to become a full-time FileMaker developer. He’s in San Diego, and really enjoys working at Geist Interactive so that he gets access to the cool tools that Todd and the company have developed.

Q: Describe your session.

A: Lance’s session “Testable FileMaker Custom Apps”, on FileMaker testing. Building FileMaker solutions so their testable is interesting. There doesn’t seem to be a lot out there in the FileMaker space, so he’s excited to start that conversation. There’s a lot of ground to cover: modular scripting, custom function libraries. For attendees, you’ll see the benefits of testing and some live coding to see how to build these tests. (Lance will be brave and live-code!).

Q: Why is FileMaker testing important?

A: Remember the game “Wack-a-Mole”? It’s extremely close to how we develop in FileMaker in complex apps. We develop a new feature, and that has the potential to break something already working. Lots of feature requests means we need to test more, and we then need to develop a robust testing methodology. It’s possible we don’t test enough since we do have the rapid-application-development platform, but we really need to.

Testing allows you to build more durable solutions. If you write a test a year ago, and you add a feature today, you should be able to run the test causing nothing to break. We don’t have to worry when we deploy that something’s going to break. If we rely on tests and new tools that we have such as the Data Migration Tool.

It is not simple to test, but it is highly worthwhile. Testing is specifications in code. Scripts that run tests are run by anyone.

Q: What is a tip or trick that you’re going to demonstrate in your session?

A: Lance hopes to have a FileMaker Testing Generator file built. It is similar to our Generator file. A FileMaker developer can create a test using script comments written in a standardized JavaScript form. Test-writing seems boring and challenging, tedious. Lance’s Testing Generator file will help write tests a lot quicker with no mind-numbing work to do.

Lance welcomes anyone to continue the testing generation idea.

In all of software development, testing is complex. We have to be aware of what testing can achieve, and we also should test everything we can anticipate.

Q: Does the person who develops the code also test?

A: The best way to produce tests is the developer who makes changes or creates new features. She knows the system inside and out and knows how the app should work.

Q: Is Testing different than QA work?

A: Yes. A QA person is operating like a user, doing some user testing. What Lance will talk about is more analogous to functional testing. Lance will demonstrate with a purchase order system where a developer is adding new features and how to add tests to accommodate those new features.

Q: What materials will be available?

A: Lance has three libraries on GitHub libraries: JSON Validations, a custom-function library, and an error tracking library. These are all FileMaker custom functions. Lance will also include the starter file upon which he will do the demo. Finally, he’ll have references to documentation on such things as JavaScript standards and his Testing Generator library.

Q: What are modular scripts?

A: There are a few sessions at DevCon this year. Todd will speak of Modular FileMaker, and John Renfrew will speak about Modular Programming. These modular scripts should be a must-attend session. Modular scripts are, in essence, scripts that perform one function well. For example, you can build a script that returns the end date of an event if the script is given the start date and the event length as a parameter. Inside this script is the logic that will return the correct end date.

Q: How much JSON do you, Lance, use in your daily work?

A: Every project Lance work on uses JSON primarily to pass data around. JSON makes modular code easier. Each script has to receive data and return data. The chunks of code (in the form of JSON) make it very easy to work. Lance will always use JSON.

Q: What is something we could know about you that has nothing to do with FileMaker:

A: Lance will be a dad in December.


Lance’s session, “Testable FileMaker Custom Apps” is Wednesday, August 8, from 1:00 to 2:00. Check it out. It will be a good one.

 

 

A few weeks ago, Dave Ramsey, creator of FMPerception, sat down with Dan Weiss and Nick Smedira of Adatasol to talk in their podcast, of course, about FMPerception. It was a fascinating discussion. Even though I use FMPerception everyday and have read and watched videos on it, I learned a lot of great things about the Realtime Developer Intelligence tool. Here’s what Dave, Dan, and Nick talked about.

  • The FileMaker Database Design Report (DDR) is a tool that produces an XML representation of one or more FileMaker files. Tools have already been created to analyze it in FileMaker. Dave says that we FileMaker developers see the XML and immediately our impulse is to build something in FileMaker to analyze it. That’s how previous tools have been built.
  • As files grow in complexity, it is tough for FileMaker to process the data quickly. In recent versions, the developers of those tools have worked hard to speed up the import, which is great. They are fantastic tools, but the processing is still time consuming.
  • The slowness causes a halt in development when there’s a question about some script or parameter or field which the DDR can answer. The developer has to wait for FileMaker to finish processing the XML to find the answer.  (How many of us started an XML import into a tool, left for the night or for lunch?)
  • Dave worked first on fmXRaySpecs to try and develop something outside of FileMaker to process an XML quickly (this tool processed the XML that FileMaker places in the clipboard when you copy objects on a layout ). This product is the precursor to FMPerception.
  • Dave succumbed to the same thought that all great inventors have: “Hey I wonder if I can do this?”. And thus he sat down at his desk with Dr Pepper and Twizzlers and worked out FMPerception.
  • FMPerception is built in Swift (macOS) and dotNet (Windows).
  • It took about 3 months of development from first idea to first unveiling.
  • Dave actually was interested in learning how to parse XML, and FileMaker provides the DDR XML, so he used that to learn how to parse the language. The fact that parsing the DDR XML told him how many tables there were in a FileMaker file (almost instantly) ‘forced’ him to build a full DDR XML parsing and reporting tool.
  • He first showed a version of FMPerception at a user group late in 2015, and people were like “Just Take my Money!”
  • FMPerception was officially unveiled at PauseOnError in 2016.
  • Dave kicked it into high gear to put together a full version before DevCon 2016.
  • The Windows side (which Dave does as well ) was released about 2 months after DevCon.

Three More Points

There are three more things I’d like to highlight from the podcast. Each deserves their own section.

FMPerception: Train up a [new-to-FileMaker person] in the way they should go . . .

Nick from Adatasol brought up a good point, which was expanded upon by Dan. Nick is relatively new to FileMaker, and at the beginning he was taught FMPerception. Now he uses it all the time. It’s his default go-to tool. Seasoned developers may default to other tools, but the young (in FIleMaker) can use FMPerception on day one of their development.

Its Own Category

FMPerception forms a whole new category of tool for a FileMaker developer. It is a RealTime Developer Intelligence tool. Any developer can use FMPerception to find out about their FileMaker file in real time. It takes only a moment to import an XML DDR, so we briefly turn to the processed XML, get a question answered, and then move back to developing in the custom app.

The Depth of FMPerception

Since the FileMaker DDR is XML, and since FMPerception processes the XML quickly, as FileMaker adds more information to the XML, FMPerception’s future features are endless. Dave already has eight-to-ten years of features in mind, and is always willing to listen to folks about feature requests.

Dave brought up two features of FMPerception that might not be as widely known: the Text Search and User-Flagged Functions. Here’s a brief description, but I’d recommend you explore these features.

Text Search

Dave built a ‘slow’ (2-3 seconds in this context) feature that allows you to search for some text within the whole DDR or just within a script or table or layout.

User-Flagged Functions

This feature I knew nothing about. But it allows us to flag a function in Preferences.

There are already some functions there, and these show up in the reports throughout. I can add more functions in User Defined 1 and User Defined 2. Notice in my example I’ve identified the Position function. 

That’s pretty cool.

FMPerception at DevCon

FMPerception will be running and strong at DevCon in Dallas, TX. Dave Ramsey joins Geist Interactive in our double-wide booth (we’re going to be across from the FileMaker one). Dave will be there from sunup to sundown (except for meals and breaks) to demonstrate FMPerception’s features and speed. He invites you to bring your XML DDR to the booth with questions. Dave will show you the magic of the tool.

On Tuesday, August 7 at 3:00 p.m., Dave will give a vendor demonstration of FMPerception. Every user of FMPerception as well as those curious about the tool should attend. No one has ever come away from one of these deep dives without learning some new feature they can immediately make use of.

As the podcast closed out, Dave said that as a FileMaker developer, “I would rather charge my customers less than spend my time doing slow, annoying busy-work. I’m far more motivated by avoiding pain than by getting money.” FMPerception avoids pain, avoids the slow, annoying busywork by helping you find exactly what you’re looking for in your complex custom app so that you can make whatever change in less time.

Go and listen to to the podcast, and check out FMPerception.

 

To celebrate DevCon 2018, the newest release of the FileMaker platform, and all things JavaScript, Geist Interactive is pleased to begin a contest called GoCreate, where you get to go wild and show off your most unique use of GoDraw3.
Use all of the power of GoDraw3 to create a unique user experience to solve a particular use case. Read all about GoDraw3, but here are some things you might want to consider:
  • Any of the tools and functionality can be removed or customized.
  • The app is simply FileMaker. Use all of your knowledge and skills of FileMaker.
  • Tagged objects can be used in some awesome way.

Who can get involved:

This contest is open to anyone attending DevCon 2018 of any skill level. Since GoDraw3 is simply FileMaker, anyone can participate; no knowledge of JavaScript is needed.

Here are the details:

  • Use the fully-functional trial version and use that for your implementation.
    • Note: the trial version includes a watermark image. Ignore it.
  • Contest Date range: Now through August 9 at 8:00 a.m.
    • Feel free to work on it now!!! Get Started.
    • Or wait until DevCon.
  • Where: DevCon 2018. You must be a DevCon attendee to win.
  • Winner announcement at 3:30 p.m. on August 9.

Here’s what to do:

  • Download the trial version of GoDraw3 and create a unique implementation of it. Be creative. Create something that would work for any of your current work, or go wild and dream beyond your day job.
  • Email a link to your project to support@geistinteractive.com.

Rules:

  • You must use GoDraw3 in your implementation.
  • You can use any part of the FileMaker platform including FileMaker 16 or 17 to create your design.
  • You can design it for FileMaker Go or FileMaker Pro Advanced. You’ll let us know which device it is meant to be on.
  • Your work must not contain any real customer data.
  • You are limited to one entry per person.
  • Your work will only be considered if you’ve emailed a link to your project to support@geistinteractive.com.

Judging

A team of independent FileMaker developers at DevCon will judge each entry, scoring your submission as they reflect on:

  • How clever of an implementation is presented.
  • How does the submission ‘feel’?

Granted, these are rather subjective, but we’ll do our best to make it fair.

Support

You can get support and questions answered in the following ways:

We will be available to answer specific questions about GoDraw3, not about how you can implement it. We want to see what you can do! 🙂

 

GoCreate! Using FileMaker GoDraw for something awesome

We’re excited to see what you create with GoDraw3.

Terms and Conditions
  • You only officially enter the competition when you have emailed a link to your project to support@geistinteractive.com.
  • All submissions become property of Geist Interactive and will be used in promotional materials. We will credit the author.
  • Submissions have to follow the rules as set out above.
  • All entries must be submitted by August 9 at 8:00 a.m.
  • Geist Interactive have the right to remove any entry at their sole discretion.
  • Objectionable or offensive content will be disqualified.
  • The competition will be judged by an independent panel of FileMaker Developers from the community. The top three will be selected based on creativity, unique implementation of GoDraw3.
  • The winners will be announced at DevCon at 3:30 p.m. at the Geist Interactive booth and by email.
  • The winners have 7 days to respond and claim the prize; if no response has been received after 7 days, you forfeit your prize.
  • Geist Interactive reserves the right to exchange any prize for a prize of similar value.
  • The judges will be selected from folks outside Geist Interactive. 

This will be a short post because the new FileMaker 17 feature master-detail portal is simple in explanation and in its use. I won’t go into much detail about how the master-detail feature is set up and used. There’s been great work done already by Beezwax and Soliant Consulting and others. You can read about how this new object works in FileMaker. I want to take the opportunity to clear up a few lingering questions/confusions about master-detail.

Overall Concepts

It’s a current-found-set portal, really

The idea to keep in mind all the time is that the master-detail portal is simply a current-found-set portal. It shows the records from the current table that are in the current found set. These records completely adopt the attributes of the current found set. If there are 91 records in the found set, 91 records show up in the master-detail portal. If you sort the found set by City and LastName, the master-detail portal will sort the records by City/LastName.

Three records in the found set. Three records in the portal.

Three records in the found set. Three records in the portal.

One record at a time

Keep in mind too that a master-detail portal is usually placed on a form view and used as navigation: Detail view of a record on the right, master-detail portal on the left. So there is visible only one record at a time in the form view. Only one record. That means the sorting and filtering I have applied to the found set sort of only applies to the master-detail portal.

What’s in a name?

Finally, the master-detail portal looks like a portal, but it does not operate the same as related-records portals. I wish it looked different somehow or had a different setup dialog. But I assume we’ll all get used to it and be confused only a little while. These portals are portals in name only. They show not related records but current found set records.

Lingering Questions

Okay, we got the concepts identified. Now let’s turn to some commonly-voiced questions.

Can I apply a sort to the Master-Detail portal?

Yes, this can be done. I can sort the found set of records in any way I want, and the master-detail portal will reflect that. It’s that simple. Since this object is placed on a form view in most cases, I only see one record at a time, so the sort order in the form view isn’t that important. Even if I have navigation buttons on the form view as well as the master-detail portal, I’d want the NEXT button to go to the next record in the portal. So it all makes sense.

Sorting the records

Can I apply filter to the Master-Detail portal?

Like the sort issue, this one comes up often because we still think the master-detail portal is a portal like related records where we can apply a filter on the portal itself or in the relationship.

However, again, since the master-detail portal reflects the found set, I can find whatever records I want. I can add a button that finds only records with job description of “CEO”. That becomes the portal filter.

Can I do more with the master-detail portal?

I’m starting to see this a lot. Folks want to be able to do some of the things we’d do with a regular portal: use it as a pick list, add a new record, delete a record, to name a few.

A master-detail portal was meant to show the current found set, to go to a record by clicking on a row (no invisible buttons behind the fields required), and to show the active record. That’s it. Trying to do more with it veers into that ‘hacky’ territory. If we do these things, we’re subverting the normal functionality of the object, and that always comes with issues.

But I want to do more!

To address the functionality I listed above:

  1. A pick list specifically would be tricky to do. If I want to put a checkbox field in the portal and check it, I’m going to have to PREVENT the built-in functionality of going to the record of the current row.
  2. I can delete a record for sure, but again, any button placed in the row would first go to that record, then delete the portal row. But it is a workable use case, and one that doesn’t seem to follow other master-detail patterns. I should be able to click on a trashcan button to delete a row without going to it, as my email client allows.
  3. Master-detail portals do not have the blank row at the bottom into which a new record can be added. It’s best just to add a new record via the form view.

New feature, new thinking

The new master-detail portal is one of the biggest features in the newest release of the platform. It provides us a built in way to show this common user interface pattern. We can throw out complicated self-joins or other amazing-at-the-time methods and instead rely on FileMaker’s way of showing the current found set in a list on a form view layout.

Sure FileMaker is fun to hack on and make it do crazy things, but now that we get new features every year, it is harder to pretend that hacking crazy stuff is a good value for our customers.  This feature is really good and really simple, and that is a rare combination. We are going to use it pretty much as is, without much hacking. Hopefully, none 🙂

(Okay, this wasn’t too short, but it is shorter than other posts!)

Introducing Editor.

Editor is THE rich-text editing tool for FileMaker, for FileMaker Go, and FileMaker on the desktop (it does not work in FileMaker WebDirect). It is familiar for users and flexible for developers. Editor provides a full-suite of text-formatting tools for writing projects such as notes and blog posts. The formatting is saved, and can be retrieved for further editing. Editor is the best way to provide formatted text for FileMaker.

Familiar for the User

Editor provides many of the formatting options we use every day in online editing tools.

Any user can

  • Change the style of text: h1, h2, h3, normal, and code (among others).
  • Apply bold, italics, strike-thru, underline formatting.
  • Align text in standard ways
  • Add ordered or unordered lists
  • Indent or outdent text
  • Insert text or images
  • Change the font or background color.

Additionally, FileMaker scripts can be used to add pre-defined text and images.

Flexibility for the Developer

Editor is all Native FileMaker

Even though the editor and the text is a JavaScript application running in a web viewer, the developer has complete control of the implementation and customization of the app. Here are some reasons why.

  • The web viewer app is self-contained in a separate file, making it easy to integrate into an existing custom app.
  • The design of the layout and toolbar buttons (outside the web viewer) is all done in FileMaker. You can completely change how it looks just using FileMaker layout mode.
  • The buttons run FileMaker scripts.
  • The editor toolbar and theme can be controlled via scripts. If you want to remove the “h1” formatting option, remove that from the scripting.

See the possible customization options available.

The Best FileMaker Rich-Text Experience

Editor is the best way to format text in FileMaker We’re excited about the potential. We have lots of thoughts about how it can be used, and we will be sharing ideas.

Learn all about Editor

Download it for free to try it out. The demo comes fully functional, though it does have a 1000 character limit. So give it a spin and see how easy it is to format (and save) text in FileMaker.

 

We at Geist Interactive are excited about the newest (yearly) release of the FileMaker platform. It is a great step forward and provides a lot of game-changing features yet again. We get to throw out “hacky” ways of doing such things as master-detail and instead use the new features of native FileMaker.

Wednesday, June 20, we will examine the platform’s latest release. We will examine the features, and review the use and usefulness of each feature. It will be a discussion, so come prepared to talk about your favorite part of the newest release of FileMaker 17.

 

Where: WeWork Aventine (not WeWork B street) || 

When: June 20, 2018 || 3-6pm

Why: There will be refreshments, and we get to talk FileMaker 17.

 

Join us. Let us know through Meetup.com and we’ll make a space for yah!

 

Today’s post comes from my colleague Barbara Cooney. Here she reports on the PauseOnError 2018.

It was nine years ago that I attended the very first PauseOnError (PoE) in NY at the Ace Hotel. We crammed into each other’s hotel rooms, some sitting on the floor. There we presented and discussed new techniques sharing the challenges and accomplishments we had encountered in our effort to improve our FileMaker skill set. I was an independent developer, and somewhat isolated. So I was encouraged to meet the people behind the screen names with whom I’d exchanged countless discussions on the forums. It recharged me.

PauseOnError Hits the Big Leagues

Two weeks ago, I attended a much more structured and larger PauseOnError, sponsored by the WomenOfFileMaker.  The event was held in the welcoming and creative city of New Orleans. The hotel we stayed at was lush and extravagant and a perfect setting for an intimate gathering of FileMaker pros.

The hotel for PauseOnError was extravagant. Photo Credit: https://twitter.com/LauraJBetz

The hotel for PauseOnError was extravagant. Photo Credit: https://twitter.com/LauraJBetz

The Theme

PauseOnError was organized by the Women Of FileMaker, and the theme they choose was “Stand Tall”.

Martha Zink, Susan Dean Fennema, and Lisette Wilson kicked things off.

Martha Zink, Susan Dean Fennema, and Lisette Wilson kicked things off.

We stood tall by telling our stories from our name tags to an entire session called “Tell Your Story”. Many of the sessions included this theme in their discussion. It was inspiring to hear of others’ journey too and through FileMaker.

Our nametags gave a little insight into who we are.

A Wide-Range of Presentations

The sessions encompassed many topics. The range spanned growing your FileMaker business to leveraging its position as a platform that can integrate easily with other systems. Since joining Geist Interactive, I’ve already been involved in several API integrations. Here I choose to both validate and expand my knowledge in those integrations sessions.

Lots of API topics

In one of the first sessions, Jeremy Upton’s curiosity led him to explore the developer tools available from Amazon to integrate Alexa. Imagine being able to ask your FileMaker database “what were last month’s sales?” And have Alexa answer back!

Sol Rodriguez demonstrated the use of RestFM with Google’s JavaScript Framework, Angular, to quickly provide web-based access to a FileMaker system. His enthusiasm for how approachable this world is for FileMaker developers was contagious. I plan to sign up for the Udemy course he highly recommended.

Chris Irvine introduced us to an alternative to REST, GraphQL, created by FaceBook. This language lets the user limit the data received back from an API call and in doing so, improve performance when latency is a concern.

Overall, what struck me about each of these sessions is each developer used tenacity and trial & error to push through that initial learning curve hump. The message is clear:

  • You can do this too the tools are out there.
  • It’s achievable.
  • You’ve got a community of developers that will support you.

And Other Topics

Taking a break from API approaches, I attended Anton Anderson’s session. It offered instruction on the use of graphical tools such as FlowCharts and ERDs to communicate complex workflows and relationships, so that you and your client share the same understanding.

Mike Beargie demonstrated how to build modular files which allow you to reuse functionality across several solutions, using JSON to pass parameters and results.

Women of FileMaker

The last session that I attended was dedicated to Women in FileMaker. Here, Martha Zink interviewed several community leaders and asked them to share their challenges, achievements and how their attitudes have changed during their careers.

 

Photo Credit: Credit: https://twitter.com/LauraJBetz

I was struck with the similarities to my own experiences in my 25 years as a women developer in a male-dominated industry. I gained a sense of confidence listening to how they too overcame the need for perfection and crisis of confidence with which many women are burdened. The top developers, as I saw first hand in the sessions I attended, and witness at Geist, learn by trying, making mistakes, revising and ultimately accomplishing their goal. No one gets it right the first time and expecting to do so is self-defeating. As Dave Ramsey of FMPerception fame explained, “errors allow me to see how it can fail, and that is important info to have too.”

A Fulfilling Pause

Poetically, I ended PauseOnError by running into Ernest Koe, one of the founders of the first POE, in the elevator. He was curious of my reaction to this experience of Pause. I assured him that the camaraderie was still there and the excitement of interacting with community leaders hadn’t diminished. I’m more than ever optimistic of FileMaker’s future and my ability to help my clients accomplish their goals. I’m looking forward to DevCon.