MightyData

FileMaker and WordPress Consultants

Outstanding Support from BaseElements

by Leave a Comment

Recently, we were engaged by a customer to provide consulting and coaching to their team of three in-house FileMaker developers. As part of the initial review, we created a DDR of their database and tried to import it into BaseElements. Shortly after starting the import, BaseElements displayed an error message saying the file may be corrupt. The error dialog also had a link to a support article on the Goya web site.

Per the article, I validated the XML using a trial version of TextMate. The second error TextMate found sounded suspiciously like the layout error described in the BaseElements article. Since I could not quickly determine where the missing XML tag was, I opened a support case with Goya and uploaded the DDR for review.

The next day, Nick Orr at Goya responded. Over the next 48 hours, Nick and I determined the root cause was a tab control in the Footer part of a specific layout. Once this tab control was removed and the DDR recreated, BaseElements was able to import the DDR with no problem. We suspect for some reason FileMaker Pro Advanced was creating invalid XML in the DDR. Nick submitted this as a bug report to FileMaker Inc.

The reason for retelling this story is to say thank you to Nick and Goya for outstanding customer service. In my mind, looking at a problem DDR and helping to identify the issue is going above and beyond. Being able to process a DDR with BaseElements was critical to being able to help our customer. Nick showed what type of company he runs and I appreciate working with a vendor who “gets it”.

Thanks Nick!

Image Rotation and FileMaker

by 3 Comments

Recently I was asked whether it is possible to rotate an image in a FileMaker container field. As far as I know this only is possible by exporting the image, using another application to rotate the image, and then re-importing it back into FileMaker. This solution would exist only in a Mac OS X environment, so I turned to AppleScript, and the built-in image manipulation app called Image Events.

Although I am sure refinements can be made to the process, and it currently only works on the Mac OS, the process is fairly straightforward. The file has a container field which stores an image. Another field stores the temporary path for each record’s image. I decided to capture the direction of the rotation (clockwise or counter-clockwise) as a script parameter and set up some basic buttons to handle the process for the demo. To rotate clockwise the angle is 90 degrees, while for counter-clockwise it’s 270 degrees.

Script to call AppleScript from FileMaker

Since the AppleScript uses the database name and layout name, I captured these as variables. I also set the AppleScript itself as a variable so I could step through the script and see what it generated. I then built the path for the export, and also converted the slashes to colons for the AppleScript path. Immediately after exporting the image, I ran it through the Image Events to rotate it, and then followed this up with an insert image script step, grabbing the rotated image from its Finder location. I added a platform check so this would run only on the Mac.

AppleScript to rotate an image

There are at least two plug-ins that accomplish very similar goals. 360Works’s free ScriptMaster rotates an image based on a URL, so if this image resides in a container field you first will need to export the image, apply the rotation with the ScriptMaster function, and import the modified image. CNS Image will actually rotate an image inside a container field, and has many other useful features; prices can be found at the CNS web site. Both plug-ins are cross-platform, unlike the AppleScript solution outlined here.

Sample File: ImageRotator.fp7

A Great Why

by 5 Comments

I have been thinking lately about the concept of Why. You may have seen the TED Talk by Simon Sinek. The concept is simple. If you know and clearly communicate your Why, you can inspire team members and customers.

Example of A Great Why

Recently I stopped to get lunch from Chipotle. They had changed the look of their menu, and I immediately noticed two things. First, they clearly state their Why. They call it Food Integrity.

Second, their Why clearly influences the How and What of their menu. Notice the simplicity. What do you want (burrito, taco, salad)? What meat do you want? What sides do you want?

Chipotle's what (their menu)

A Clear Why Makes It Easy

A clearly defined Why makes it easier to state the How and What. Defining the Why is the hardest part. What is your Why? Have you spent any time lately to write it down? A few minutes, a couple of hours, a day?

Beautifying Browse Mode, Functionality in Find Mode

by 1 Comment

The Problem

Ever since sub-summary parts started working in Browse mode, developers have been using them to enhance list layouts. The catch? Find mode.

If you place a field in a sub-summary part, the user is unable to enter the field in Find mode since it is not in the body part. So while the technique adds functionality in one mode, it removes it from another.

The Solution

Watch this short video and learn how conditional formatting and field  behavior can solve the issue. With “hidden” fields and “no entry” in Browse mode, you preserve the beauty of Browse mode and keep the functionality of Find mode.

Dealing With Errors in FileMaker

by Leave a Comment

Approaches to errors during development generally break down into two methods. Like defensive driving, the first method attempts to avoid errors from occurring. The second method attempts to deal with errors that occur and find appropriate ways to minimize the effects. Good solutions find a balance between both methods.

Typically errors occur in the context of scripting through unexpected behavior, although other areas of FileMaker can result in unexpected behavior, including case statements, conditional formatting, autosizing of layout objects, charting behavior, and security. In this brief article we’ll focus on scripting errors, although the methodology applies to all areas: test all features from as many perspectives as possible.

FileMaker Error Codes

FileMaker harbors built-in detection and notification of errors. Internally, these take the form of numerical codes, and each code bears a matching text description in FileMaker’s error reference in the Help file. Over 200 built-in error codes exist, including the “no error” error code of zero (0), and the common search result error code of 401, indicating no records were found.

Although one might believe it counter-intuitive to include these as error codes, when checking for errors such behavior, it is invaluable. They are like the Hound of the Baskervilles, which failed to bark at a critical moment and provided the clue to solve the mystery.

FileMaker’s own internal codes will spur various dialog messages. Users trying to modify a record being modified by another user will see a dialog to this effect. Scripts that modify records may run into the same issue, but with no one monitoring the script, such dialogs will pause action until they are resolved.

Trapping for Errors

By taking control of FileMaker’s error notification through the Set Error Capture [On] script step prior to actions that may cause errors, developers can plan for possible errors and deal with them below the surface, allowing scripts to ignore errors or set them aside until later.

There are various levels of handling errors that developers can use in solutions, if they accept the fact that errors are possible, even in the best of circumstances. First, suppress all or certain error notifications. Second, assuming human interaction is possible, display alerts in dialog windows to users and guide resulting action from users through the script.

This could mean requiring the user to take action based on the alerts, and handle the user’s possible action(s). In addition, developers could build in processes that log all errors in a table for subsequent debugging.

To Boldly Go

by Leave a Comment

We live in the future. Ideas and gadgets featured in science fiction books and movies decades ago remain fantastic, but no longer seem unreal. The phone in our pocket is far more powerful than any computer a few years ago. Lightweight electronic tablets that store thousands of books have led to some virtual books outselling physical books at Amazon.com. FileMaker Pro is no exception. With the release of FileMaker Go for the iPhone and iPad, we have live instant access to records in our FileMaker databases.

FileMaker Go is available exclusively through Apple’s App Store for either $19.95 (iPhone/iPod Touch or $39.95 (iPad). Once downloaded, you have instant access to FileMaker files over the network just like any other desktop user of the FileMaker Pro Mac or Windows application. You can also load databases on the device, either through iTunes or a web site. FileMaker Go functions very much like a thin client — the user cannot certain developer features like Manage Scripts or Layout mode, only Browse and Find. Yet imagine the ease and portability: carrying a lightweight iPad throughout the office or a hospital and being able to access database records. Or a sales person on the road quickly able to pull up contact records or product listings via a iPhone.

Developers considering FileMaker Go as part of their repertoire need to take the size of the device into consideration when designing layouts. Certain script steps may not work the same way on Go and will need to be tested on the device as part of the development process. The primary use of “touch” as the input method may change certain user interface design ideas, as users will demand quick and intuitive responses from their application. While the desktop version of FileMaker continues as the core market (and only developer platform), the arrival of its smaller sibling signals an exciting new future for FileMaker, one that both business and personal users of database applications greet with excitement.

MightyData now offers a FileMaker Go training class, designed to help understand the differences between FileMaker Pro and FileMaker Go, and how to develop applications for the use on mobile devices. This two-day class covers key elements such as designing for the different layout sizes and behavior on the iPhone and iPad, dealing with interrupted processes in your scripting and record modification, and network latency. The second day will cover advanced scripting techniques such as scanning barcodes, image handling, electronic signature capture, charting, and more.

The Art of Training

by Leave a Comment

I advocate accomplishment, whether it’s through development of a database solution for a customer or training a student on becoming a better developer. While the former requires attention to detail, knowledge of the FileMaker product line, and the agility to solve problems, what does it take to advocate accomplishment from the perspective of a trainer? Step into to my world…

Training isn’t about standing in front of an audience. It’s not about teaching out of a book. Training is all about understanding student needs, interacting with the students, and being a flexible trainer. Ah yes – and patience. Lots and lots of patience. As developers, we fall into the trap of thinking “this stuff is easy,” especially when covering the basics. I mean, we do this stuff day in and day out. As a trainer, we have to remember what it’s like to know little to nothing about FileMaker. We have to remember that terms like “modes,” “views,” and “scripts” are not part of our students’ everyday vocabulary. It’s our job as a trainer to walk developers through, what can be, a steep learning curve.

With patience comes flexibility. There have been many times where my class outline goes flying out the window when I realize the class could get more out of a different topic. Even if I keep to my outline, my examples and/or approach will change depending on my students. If I’m teaching a finance group, I use transactions and accounts as my real world example. If I’m teaching schoolteachers, the student/teacher model becomes the focus. When teaching a group from different organizations, I do my best to use at least one example from each person’s work background. Not only does it help the student learn, but also it makes the class feel customized and tailored. Who doesn’t love that feeling?

The one technique that holds true to being a good trainer is to always wear your excitement and passion for FileMaker on your sleeve. Students have come up to me and said, “Your excitement is contagious!” and that may be one of the best compliments ever paid. I teach others about the powers of FileMaker and ease their fears of creating databases by letting them know that I’ve been there, that I will help them through it, and that my classes are meant to help them move forward with the development.

So what is the art of training in a nutshell? Remember what it’s like to be new to FileMaker, take the time to understand what your students want and need, and remind your students (and yourself!) that you do what you do because you love it.

Pause On Error: Recapping the Unconference

by Leave a Comment

New York City welcomed us with good weather for Pause On Error on February 17 and 18. Over 100 FileMaker developers, including two MightyData speakers, milled around the Ace Hotel, attending sessions packed with great topics and even better group discussions. As in past years, POE excelled at bringing a part of the community into one hotel and allowing developers to talk about all the things that bring us together, regardless if it’s FileMaker, business, sports, or music.

Here are a few highlights:

  • The Art of Value – In this session, our own Kirk Bowman described his steps toward value pricing. This wasn’t about quoting sources or using jargon: No sir. These were real world examples of how to implement value pricing and how Kirk’s experiences have molded MightyData. The attendants focused on the “how” and quite a few people had their own positive experiences to share.
  • Building Something James Bond Would Use – I, Martha Zink, presented this one! Developers packed the room to see examples of real world interface issues that people face. From alarm clocks to restaurants, I showed how affected we are by our experience and interactions, regardless of the “true” functionality. The discussion was lively, as we talked about the status bar, logos, color schemes, and much more. It was great to have Matt Petrowsky, maker of Theme Studio, in the room to discuss his take on interface guidelines and rules
  • Building a Better Horse – As developers, we need to wrap our minds around a design process in order to come up with solutions for our customers’ needs. Don Levan took us through a condensed version of the process, allowing us to better understand our customer and their perspective.
  • Beyond Anchor Buoy – So many developers preach anchor buoy as a great way to organize the relationships graph (me included!). Corn Walker challenged the idea and asked a fundamentally important question: How can we make this easier? While he wasn’t there to give us an answer, he did allow the community to discuss how other programming languages handle this issue and what we would like to see come from FileMaker, Inc.
  • WordPress FileMaker Sync – If you’re using WordPress to its fullest capabilities and are interested in integrating with FileMaker, Lauren Kuhlman’s plug-in is a worthy purchase. She demonstrated her product, showing how seamless the plug-in is for both internal use, as well as communication with customers. We know how to take FileMaker to the next level, now it’s time to use it to take WordPress there, too.
  • FileMaker User Experience – Put a room of developers in a room and you’ll get twice as many opinions as people. This came through at Vince Menanno’s presentation on our experience of FileMaker interface. It was nice to have Heather Winkle in the room, speedily taking notes on what developers want, need, and beg for. Not only did she listen, but she even probed the “why” for features, really challenging us to understand why we wanted certain things. It was an interesting dichotomy between the needs of new/amateur FileMaker developers versus seasoned professionals.

Half of the POE experience involves the session. The other half is the ability to socialize and enjoy time with other members of the community. After the sessions, it was no surprise to see computer keyboards in developer hands replaced with guitars for strummin’, cameras for photographin’, and forks for eatin’. And of course, POE would be incomplete without the after-party. As the sessions ended, we all opened a few drinks and cheered to a successful event and a fantastic experience. With something as enriching as POE, I wish there had been seven of me at any given time, but alas, I was stuck being one Martha. There is no doubt the event was a success, giving developers the chance to walk away with cool ideas, new approaches, and great memories.

POE is a chance for FileMaker developers to spend time talking about their passions, interests, and findings. And that’s exactly what happened. A big thank you to the steering committee: Ernest Koe, John Sindelar, Molly Connolly, and Andy Gaunt!

Reporting Dashboards

by Leave a Comment

With the advent of native charting in FileMaker Pro 11 developers can take advantage of powerful tools to design reporting dashboards to visually display critical information.

Images can convey information at a glance. Images can also overwhelm. A dashboard design should recognize that in order to communicate information effectively, the key is to illuminate, not overwhelm. Bright graphics and visual effects may have the opposite impact, hiding the data among fancy design and slowing down the user’s ability to interpret information.

Reporting in FileMaker entails sorting and sub-summary layout parts. The basis for any dashboard is almost the same. Data must be sorted and grouped. Charts can exist either as graphs alongside text, such as lists or sub-summary reports, or on specially crafted layouts focused on images only. The latter could display a variety of data from several different sources, all gathered and grouped in ways that make logical sense. I would argue that only the latter is a real dashboard, for while charts can greatly enhance data around it, a dashboard is essentially summary data only, and mostly graphical in nature.

Native FileMaker Pro charts come in only five variations—bar, horizontal bar, line, area, and pie. In addition, there are limits on how one can customize the appearance of each type. Labels with the chart appear untouchable; here a calculation option with Tooltips can prove invaluable. We can, to a limited degree, manipulate the dimensions of the charts by affecting other elements around it, such as the title and label size.

In order to best convey information about data through charts one has to select not just the right type, but consider size, what should appear in the labels, and color. One set of data might make perfect sense as a horizontal bar chart, and no sense in a pie chart.

Charts displayed within a record often require minimal preparation. Dashboards, where different sources can be combined into a single layout, usually require scripting in order to combine all of the elements. In brief, these scripts gather data points into global variables, for labels and/or values, with the last step switching to the dashboard layout where the charts are set up to receive the global variables and display the data.

Incorporating dashboards into FileMaker solutions is now easier than ever, with no need for plug-ins or external data such as the Google Chart API through web viewers. This graphical way of viewing reporting data can enhance solutions and provide developers and users with new tools to understand their data.

Understanding the User

by Leave a Comment

As FileMaker developers, our job lies not only in creating calculations, scripts, and layouts, but also in successfully understanding the needs of the user. Easier said than done, right?

So what’s the key to understanding the user? Feedback. It’s easy to get caught up in the coding and the interface and forget to ask the user for feedback on our progress. So here are a few suggestions:

Before it Starts

During the time that you’re scoping out the project, begin visualizing the look and feel of the database. Remember that while we are concerned with the structure and mechanics of a database system, the customer just wants it to “work,” regardless of what it takes to make that happen. Also, ask your user what they are currently using—it will point to techniques and approaches that they are accustomed to. While we shouldn’t be constrained by what’s already been done, it can be a gateway to understanding the user.

Scope & Screenshots

Once you have enough information to scope the project, provide your customer with screenshots or mock-ups of what you’re planning on doing. The feedback you’ll receive early on can help make the rest of the process easier on you, the developer. What I often do is create a non-working layout for my first status meeting with the customer and say “What do you think?” It’s amazing what you’ll hear—from “I love it” to “Can we get rid of that color” and everything in between. The customers/users are the ones who are going to stare at this database —let them be the judge on what “looks good,” with a little insight of your own, of course.

Dwell On Design

Ever been on a website and things just don’t make sense? We’ve all run into situations where buttons are in the wrong place, the sequence of events seems out of order, or navigation is nearly impossible. These are all things that cause user anxiety. From a development perspective, those systems might successfully serve their purpose. However, removing the human element is a sure way to failure. Even worse than “garbage in, garbage out” is not knowing how to navigate, use, or manage a database. By focusing on the interface and user experience, your database will be more successful than building a plethora of bells and whistles. Try putting yourself in the shoes of the user and going through the process from start to finish. What types of things would you want to do that deviate from a normal scenario? Think of things like deleting, duplicating, canceling, etc.

Touch, Test, Tweak

Once your database is in a state of usability, put it in the hands of future users. Even better, go onsite or setup a screen sharing session and give them a lesson on using the database. Keep your eyes and ears out for feedback like, “How do I get there again?”, “Woops. I clicked on this by accident”, and “What does this do?” A database should be intuitive for the users and questions/comments like these point to a disconnect between what the developer built and what the users expected. Once you’ve provided a tutorial for the users, give them free reign to test the database. The process of testing and tweaking is quite cyclical, but will lead to big success. Ask questions like “What would you like it to do?” and if it doesn’t vibe with what you had in mind, follow up with “What do you think about this other approach?”

Partner Up, Don’t Dictate

Now I don’t want to portray that the developer should do exactly what the user wants. If a car manufacturer asked me how to build a car and I’d never owned one before, I might end up with 7 doors, 2 steering wheels, 12 tires, and no engine. We want to provide direction and focus, but the point here is that your users know the process they are trying to accomplish better than the developer does, usually—so combine your knowledge of structure and design with their knowledge of the business process.

The real crux of understanding users is interacting with them as much as possible. Don’t leave it to just the testing phase in your development process. This will lead to rework and frustration. Instead, when you build something that can be put in front of the user, do just that! Also, the more you accept and implement what your users want, allowing them to contribute to the process, the more likely they are to accept your feedback for efficiency and improvement of the existing process. Understanding the user isn’t rocket science—it’s basic psychology.

Let’s get started on your project.

It will be more fun than you think.

Get in Touch