Category Archives: Blog

  • 0

Podcast 133: FileMaker 16 – New Features Galore!

Tags : 

 

Matt Navarre and Matt Petrowsky (aka Matt Squared) talk about the new FileMaker 16 release and what it means for FileMaker developers around the globe. Looking for that deep dive into what the new features mean? Have a listen to this particular episode.

 

Like this? Check out more podcast at FileMaker Talk.


  • 0

FileMaker 16: External Data Sources

One of the new features in FileMaker 16 is the ability to set an external data source dynamically by using a variable.

So, what does that do?  How does it work? What does that mean for FileMaker development?

What it Means

It provides the ability to have multiple customers share a user interface file but each have their own data files.

In previous versions of FileMaker, external data sources were fixed, so each user had to have their own set of files, or record level security had to be used to block access to other user’s records in one data file.

Record level security can really bog down a system, so separate data files have serious performance benefits. However, if each customer has their own file and there are thirty customers, a small UI change meant that you would have to replace thirty different files.

In FileMaker 16, we can have as single UI file that all users login into. The file will look at who is logging in, dynamically set the data file name in a variable accordingly, and make sure they only connect to their data. A small UI update can be achieved by replacing a single file not the server.

How it Works

The UI file will not attempt to open the data file until it “needs” it, whether it is because there is a reference to it in a script that is called, or a field from the data source on a layout. Once that happens, the UI file will “resolve” the relationship and connect.  If this is defined as a variable, the variable needs to be defined before the external data source can be accessed. This means the variable will most likely be defined in a startup script which the purposely accesses the data file to make sure that relationship is resolved correctly.

That would be scripted something like this:

If [ Get ( AccountPrivilegeSetName ) = “Customer1” ]

Set Variable [ $DataFile ; Value: “file:Customer1_Data.fmp12” ]

Else If [ Get ( Account PrivilegeSetName ) = “Customer2” ]

Set Variable [ $DataFile ; Value: “file:Customer1_Data.fmp12” ]

End if

Go to Layout [ “Data” (Data) ; Animation: None ]

The last line of of the script above goes to a layout based on the data source, forcing the relationship to be resolved while the script is still running and the variable still exists. Alternatively, a global variable could be used, whose scope would extend outside of the script, and then the open script wouldn’t necessarily need to force the relationship to be resolved right away.

Issues to Consider

While this new feature has remarkable potential to simplify UI development on vertical market solutions, there are some issues that will have to be addressed. All of the ones that come to mind revolve around security.

A way will have to be developed to handle the accounts between the UI and Data file. Do you have all of the accounts in the UI file and then only the applicable accounts in each data file?  Or do you have an auto-login in the UI file and some other process for logging into the right data file with the right account?

Another issue is the “Re-Login” script step.  Once the connection is made to the data file, it will be fixed until both the UI and Data file are closed and reopened. This means if a user uses re-login to log in as a user who does not have access to the file they are going to remain connected to a file they no longer have access to. Also, what if a user needs access to all of the data files? Letting them pick on login might be an option, but having to close the whole system and start it back up to switch data could become cumbersome for someone managing several customers on a vertical market solution.

Join the Conversation

What potential do you see for this feature? What other benefits might it have? What other drawbacks?  What solutions do you see for dealing with these drawbacks?


  • 5

FileMaker 16: Passing Multiple Parameters Natively Using JSON

Tags : 

With the release of version 16, FileMaker developers finally have the ability to natively pass and parse multiple script parameters . This is made possible by the new JSON functions — specifically, the JSONSetElement function and the JSONGetElement function. There are various methods and syntaxes FileMaker developers have been using for passing multiple parameters to and from scripts, but the most common one I’ve come across is key-value pairs in the format “key1 = value1 ; key2 = value2 ; key3 = value3” etc. This is a nice simple format, but it has some limitations. The new method in 16 is to pass a JSON object, with a series of elements that form the key-value pairs, and parse those elements out of the JSON object in the sub script. So, what once was passed as:

"id = 32313 ;
name = alice ;
address = 123 Main St. ;
member = true"

is now passed as:

{ 
     "id" : 32313, 
     "name" : "alice", 
     "address" : "123 Main St.", 
     "member" : true 
}

And on the receiving end, we parse out each element into a variable and use them from there, using the JSONGetElement function. There’s no longer a need for custom parsing functions, or complex let statements that parse and instantiate each variable.


There are two ways to form the JSON object when passing the parameters. The first, and more clunky way, is to just write the JSON from scratch. I say clunky because you have to do things like escape lots of quotation marks, and insert ampersands, and insert unescaped quotation marks, and insert syntax errors, and (barf) and I wouldn’t recommend it. But this is what you’d write, if you so desired:

"{ 
     \"id\" : " & TableName::ID_Field & ", 
     \"name\" : \"" & TabelName::Name_Field & "\", 
     \"address\" : \"123 Main St.\", 
     \"member\" : true 
}"

 

The second, and more elegant way, is to leverage the JSONSetElement function:

JSONSetElement ( "{}" ;
     [ "id" ; TableName::ID_Field ; "" ] ; 
     [ "name" ; TableName::Name_Field ; "" ] ; 
     [ "address" ; "123 Main St." ; "" ] ; 
     [ "member" ; True ; "" ] 
)

Now when the script into which you’re passing parameters begins running, you (optionally) set a variable to*:

Set Variable [ $param ; Value : JSONFormatElements ( Get ( ScriptParameter ) ) ]

And in the following script steps, you instantiate a variable for each of the incoming JSON elements as needed, using the JSONGetElement function. Since the variable $param is now just a tidy little package of JSON, you can pull out individual elements from it like so:

Set Variable [ $id ; Value: JSONGetElement ( $param ; "id" ) ]
Set Variable [ $name ; Value: JSONGetElement ( $param ; "name" ) ]
Set Variable [ $address ; Value: JSONGetElement ( $param ; "address" ) ]
Set Variable [ $member ; Value: JSONGetElement ( $param ; "member" ) ]

It works beautifully. This is JSON functionality at its most basic, but it’s a pleasure to use, and provides us with a brand-new, simple way to do something we’ve wanted to be able to do natively for years. And what’s cool about the new JSON functions is that FileMaker developers can start natively doing even more complex things, like building arrays of data, with child records and all, right inside variables, and pack and unpack them at will using native functions. All in all, JSON is a welcomed addition to the FileMaker platform’s toolset.

 

*The JSONFormatElements function is nice to have for looking at parameters in the data viewer, but is not actually required. All it does is take the JSON that is passed in and format it neatly with line breaks and indentation. You can just use Get ( ScriptParameter ) alone and everything will work just fine.


  • 0

AppWorks is hiring

Tags : 


AppWorks is hiring! We’re looking for energetic, creative individuals to build and/or maintain custom software for our clients using the FileMaker Platform.

Responsibilities

  • End-to-end development of custom business software, including building data tables and relationships, designing user interface, scripting, and quality assurance testing
  • Maintenance of existing new and/or legacy software systems
  • Interaction directly with clients to assess their needs, and keep them apprised of project status, when necessary
  • Working closely with project managers and other FileMaker developers to design, implement, and maintain systems with a high level of quality
  • Working with internal project management tools
  • Accurately tracking billable hours on a daily basis

Requirements

  • Excellent communications skills
  • 3 years of FileMaker Platform experience
  • Strong understanding of relational database design
  • Solid programming skills
  • Ability to articulate software concepts to non-technical staff
  • Ability to train/instruct end users to use the FileMaker Platform features
  • Exhibit signs of creativity and a positive attitude
  • Team player
  • Ability to perform job functions with a minimum of supervision
  • Basic knowledge of at least three of the following SQL, PHP, HTML, JavaScript, REST, JSON and C++

About AppWorks

AppWorks is a custom app development firm that specializes in creating database solutions to be used on any iOS or desktop device – including the web. We predominantly work with the FileMaker Platform (FileMaker Inc. is a wholly owned Apple subsidiary). We continue to diversify our portfolio while maintaining a strong focus in healthcare and public health, commercial and government databases.

We are pivotal in the FileMaker community – we are one of only three Platinum members in Oregon. We regularly host Apple events and co-host the FileMaker Portland Meetup group that is over 135 people strong.

In addition, we also offer FileMaker training classes four times per year. We offer beginner and intermediate classes. Matt Navarre is a regular speaker on FM Academy; is often asked to speak at conferences (like FileMaker’s annual DevCon); and co-hosts FileMaker Talk.

Working at AppWorks

AppWorks offices are located in downtown Portland, Oregon.

  • High-energy atmosphere
  • Encouraging and supportive work environment
  • Opportunity for professional development and growth
  • Training, mentoring, and opportunity to obtain professional certifications
  • Opportunities to attend annual FileMaker Developer conference
  • Competitive salary, health plan, yearly paid time off, 401K with company match after one year of service.
  • Annual bonuses
  • Team outings

We are looking for a long-term employee. Someone who sees our vision, fits in our culture and wants to help us maintain and build on this momentum as we grow over the years into a larger, flourishing company. We are a work-to-live company, not a live-to-work company.

Please provide samples of your development work.

Send inquiries to kimberly@app.works

 


  • 0

Podcast 132 :: Molly Connolly & Matt Navarre talk about conferences

Tags : 

 

 

 

 

 

 

 

Molly Connolly & Matt Navarre talk about conferences – DevCon, Pause on Error, and news about Elusive Moose.

Did you know Women of FileMaker are sending three women to DevCon. Apply for the scholarship for free conference pass now – applications close on April 7!

Make sure to check out her sessions at DevCon!

Molly also highlights Thorsen Consulting‘s services including business topics such as the jump-start training program.

Like this? Check out more podcast at FileMaker Talk.


  • 0

Podcast 131 :: Mark Scott from Beezwax on Button Bars

Tags : 

 

Matt Navarre catches up with Mark Scott from Beezwax on Button Bars.

Like this? Check out more podcast at FileMaker Talk.


  • 0

LaunchIt

Tags : 

Credit: NASA/Tony Gray

AppWorks is happy to share LaunchIt a user friendly file launching module. This FileMaker module gives developers a fast way to share solutions with clients.

It takes time to talk a client through adding the hosted solution to their favorites and going through the steps of typing credentials – especially if the client is prone to typos. The launcher file takes less than a minute to set up, gives the user feedback if it doesn’t work, and doesn’t have the potential for opening security holes in a system.

A fmp url protocol and the open url script tell FileMaker to go to a server and open a file without having to put an external data reference in the launcher file or authorize the launcher in the hosted file. This only passes an open command – no account name or password information to the file. Security is left to the hosted file and comparable to the open command from within FileMaker.


Set Up

  • Download the LaunchIt file from our downloads page.
  • Make a copy of the LaunchIt file.
  • Rename the copy to match the filename being launched.
  • Double click the renamed file to open.
  • Type the server address and filename in the setting screen, this screen displays the first time the file is opened.
    The server address can be the raw IP address or the domain name – don’t use http:// or https://.
  • Test the settings with the  “test connection” and “open file” buttons.
  • Close the settings window.

D’oh: If you set up file without making a copy you’ll need access to the admin screen. To edit the file, hold down the option key (shift in Windows) and double click on the file. “Admin” is the username with no password.


Use It

Attach the launcher file you created to an email and send to your client.

If a user has an unsuccessful launch, the file will test the internet connection by trying to connect to Google.com. Then it will try to connect to the server’s test page at :16000/Test.html. If a developer has disabled the test html on their server, they will need to add some other test for server connection, or forgo that test altogether.

Depending on the results of these tests, it will tell the user:

  • You do not appear to be connected to the internet.
  • Connection to server [server name] failed.
  • Successfully connected to server, but file [solution name] does not appear to be open. Please confirm the filename is not misspelled, or that [solution name] has not been closed or moved.

The user can use the “Try Again” button, or click on the gear icon in the lower right to go to the settings page and modify the server address or filename.

Get the free download:  Download LaunchIt

If you would like to schedule a professional consultation for personalized integration, please contact Shawn at shawn@app.works or (503) 616-9422.


  • 0

FileMaker Pro 15 Advanced Training – April 2017

 

Date: Monday, April 10, 2017 and Tuesday, April 11, 2017
Time: 9 a.m. to 5 p.m.
Event location: AppWorks conference room
Description: FileMaker Pro 15 Advanced Training
Taught by: Matt Navarre
Hosted by: AppWorks

Strengthen your FileMaker muscles with FileMaker Pro 15 Advanced Training provided by AppWorks. Space is limited, sign up here.

What: This intermediate to advanced two-day intensive training course will be taught by Matt Navarre, founder of AppWorks. Using FileMaker Pro 15 Advanced, Matt will delve deep into all that FileMaker 15 has to offer the intermediate developer that wants to hone his/her skills and for the advanced developer that is looking to stretch his/her knowledge.
Two days of lecture will conclude with an hour or two at the end of class for hands-on assistance with a project you are currently working on, or a project you’d like to get started on.

Materials to be covered in class include

  • Focused training on FileMaker Training Series 15 for Intermediate to Advanced developers
  • Highlighting what has improved and what is new in FM 15
  • An opportunity to pick Matt Navarre’s brain

What to bring to class

  • Your own laptop — with FileMaker 15 Advanced installed
  • Your own project to work at the end of class (if you have one)
  • Any questions or specific problems you’d like to solve in FileMaker
  • Your sense of humor

Sign up here


  • 0

When we’re not developing custom apps

Tags : 


Did you know employees at AppWorks are hand models when we’re not developing custom apps?

Come say hi and try one of the number of delicious eateries we have in our neighborhood!


  • 2

User Interface Design: The Mental Map

Tags : 

Compass Study

Techniques for Making FileMaker Apps more Intuitive

The FileMaker platform enables us to build software very quickly – far less time than the typical software development cycle. With the ability to construct a working piece of software so fast, it’s easy to “rough in” a quick user interface that gets the job done (whatever that job may be), but may not be very intuitive to use.

The most intuitive software needs little or no explanation. The user intuitively knows how it works, either from visual cues, conveniently integrated documentation, or through the use of conventional UI techniques that people already understand.

Unintuitive software, on the other hand, is initially confusing or overwhelming, and will leave a user asking where to find what they’re looking for, or how to accomplish basic tasks. A badly-designed user interface can be learned eventually, just through sheer muscle memory, but that doesn’t mean it’s become easier to use. It just means that the user has been able to finally remember the steps to get their job done. It means that they’ve finally been able to construct a “mental map” of the system.

Just like in the real world, people need to create a mental map of software in order to find their way around. You know how to get to work every day without consulting your phone, because you’ve built a mental map of your surroundings, based on your starting point. To find their way around in a piece of complex software (particularly in the case of relational databases), your users need to build a mental map too.

A map graphically describes the spatial relationship between objects in an abstracted form. In the case of a geographic map, that’s the overhead view. In a desktop operating system, the overhead view is analogous to your “desktop”. So you visually move into and out of folders, scrolling through files that are contained in them, and then close the folder again, which goes back to its original location on the “desktop”. You move “into” and “out of” folders and applications, go “back” in your browser, and up and down in the directory structure, and all of that is reinforced by visual cues in the UI. You have a sense of where you are, and where you’ve been at all times. The same sort of interface conventions hold true for your mobile OS. You swipe left/right to move across the surface of an imaginary area. Even though the entire surface of that area is not visible at all times, you are able to create a mental map of the entire workspace because the location of objects in it are reinforced by the movement of the interface. You know that the app you’re looking for is “to the right” of your home screen. Likewise, when you click on an email in a list, and the single email slides in from the right, you know that the list of all your emails is still “to the left”, and clicking the arrow at the top left corner will return you there. Of course there is no “to the right” or “to the left” on your phone, but the software has enabled you to build a mental map that makes it easy to remember where to find everything.

As a FileMaker developer, you’re intimately familiar with the relationship graph that serves as your actual map to the system, at least in data form. But it’s all too easy to forget that the user of your software will likely never see that graph. This is your map to show how table B is accessed from table A, but the user doesn’t see that. They need to be shown, through the interface, what the relationship is between the two tables. And similarly, the relationship between a found set of records in list view, and a single record in form view needs to be clearly delineated. As a developer, your aim for the UI should be to enable the user to easily create a mental map of the system as a whole.

There are several techniques that I use to reinforce a user’s mental map in the systems I design.

The Dashboard

The first technique is using a “Home” screen or “Dashboard”. This serves as a central point from which you can access almost any other screen in the software. Think of it as the front door, or perhaps more accurately, a “software foyer”. Taking this analogy, you enter the software through the front door, and are presented with a set of doors and hallways that take you to other locations in the house. If one doorway leads to the dining room, and one to the living room, and a staircase leads upstairs, then you always know how to get to the living room from the dining room, or from the dining room upstairs: by going back through the foyer. The well-known home icon always takes you back to the starting point, and you can now move to a different part of the software. It’s easy to build your mental map based on a single home screen, with all the different sections of your software radiating out from there (not unlike the FileMaker relationship graph).

Limited Context-Jumping

Another key technique I employ for reinforcing the mental map is to limit navigation across contexts. Every time you move from one context to another, it adds another layer of complexity to your mental map. If you move your user between contexts without providing some very clear indicators that they’re looking at things from a different perspective, you run the risk of actually breaking their mental map, since the place they think of as “back” is no longer the same as it was moments before. As a real-world example, wouldn’t it be confusing if you started at the front door, went upstairs, then into a bedroom, and then walked through a door and suddenly found yourself back downstairs in the kitchen? For that same reason, it’s generally better to make the user return to the dashboard (back downstairs to the “foyer”) in order to visit a new context, so that they can easily add on to their existing mental map. Alternately, you can enable your user to view their related data from a single context, without forcing them to move to a new screen. I do this whenever possible. For example: My user is viewing a “Customer” record, and on the layout is a portal that displays related “Jobs” for the customer.  When I click on a job in the portal, instead of navigating away from my customer to the Jobs context, I simply load the single related record right there from the customer context, using a global-field-based relationship. Now, my user only has to hold the Customer “location” in their mind, and from there can see into detailed info about that customer (i.e. their jobs), rather than forcing them to build a new location into their mental map – the Jobs “location”. If they are required to move over to a new layout in the jobs context, they’ll need to somehow build into their mental map exactly how that relates to the customer, how to get back to the customer they were on, and how that relates to the system as a whole. If, however, they’ve never moved from the customer context, they can immediately understand how the job relates to the customer, and how they got to that information, because in theory, they’ve already built that part of their mental map.

Signposts and Icons

As I described earlier in this post, one of the ways that mobile operating systems reinforce the mental map is by using buttons that explicitly display an arrow icon, typically coupled with animation that shows the movement of one screen to another. When clicked, the screen shifts over from the direction that the arrow pointed, reinforcing the mental map of “detail on the right, list on the left”, or the “master-detail” view that we’re all familiar with. Although we don’t currently have the benefit of sliding animation in FileMaker (with the exception of slider panels on the Mac and iOS), we can still reinforce the mental map by using arrow icons on buttons. From a Customer list view, I’ll place a clear button (i.e. no color fill, gradients, or outlines) over the row that navigates to the detail view. At the far right end of the button I’ll place a simple arrow icon, which implies that the Customer detail is to the right. When I arrive at my detail view, there’s a button in the upper left corner, with an arrow pointing to the left, that says “Customer List”, implying that the List view I was just on is to the left. These reinforce the user’s mental map, in which they begin at the dashboard, click customers, then click a single customer. They’ve “moved” from left to right. When moving back up the chain, all icons point to the left, reinforcing the movement back from right to left. And moving from left to right, they can build a mental map of All>Some>One, which is not unlike navigating a hard drive, where the user drills down from hard drive, to folder, to file.

Remember the Map!

Designing an intuitive interface for your app is probably the single most important element contributing to the successful adoption of your software, as a database system is only as good as the user’s ability to get at the data. If they have a hard time wrapping their head around how it all connects, what the relationships between tables are, and how to get the right data into or out of it, then it will be of no use to them. They’ll probably find something they can more easily grasp. If, however, your user can easily build that mental map, they’re much more likely to feel comfortable using and understanding the software, and if you can make that mapping process effortless, all the better. Having a few go-to techniques to help reinforce the mental map can be especially valuable for projects in which the development time is limited, but as a software UI designer, you should always try to have foremost in your mind your user’s perspective, and remember to help them create their mental map.