FileMaker Archives

May 12, 2015
2

FileMaker Pro 14’s Best New Features for Developers

FileMaker has always had a special place in the world of software. Its legendary ease-of-use is aimed at letting people gather and manage their data without needing to understand geeky topics. So it makes sense that most upgrades have focused on features that are readily apparent to end users. But FileMaker Pro 14 may be the first upgrade that has more to delight developers’ hearts more than end users’.

FileMaker 14: Performance, Performance, Performance

That’s not to say that end users don’t benefit. FileMaker’s engineering team always knew that FMP 13’s WebDirect technology was a 1.0 release. It was amazing how well it worked, but all those features came at a cost to performance that some users found frustrating. So the great gift to end users is the fine-tuning of FileMaker Server for increased performance. We’ll see some real world figures drifting in over the next few days and weeks, but before release some folks were reporting a 2-3x speed increase in some operations.

Plus, the new Standby Server feature lets you create a second server that can nearly seamlessly take over in case your primary server fails. Neither of these are glamorous features, but they’re the kind of trust-building upgrades a mature software platform has to provide in the competitive world of database apps.

Features to Make Your Developer’s Heart Sing

As with any upgrade, many features are improvements to old standbys. So you can expect the usual influx of new functions (like a suite that lets you control media playback in container fields), and improvements in existing features. But by far, the biggest change, and the one that will inspire the most love—and maybe the most initial frustration—is the ground-up redesign of the old-school Edit Scripts window.

Script Workspace

FileMaker 14’s new Script Workspace is long-awaited upgrade to script writing. All the functions of two dialog boxes have been combined into the new workspace and the menus. Most interactions with the workspace can be issued through the keyboard, instead of the mouse. You can also choose steps’ option with the keyboard — for the most part. Instead of secondary dialog boxes, most options are entered from a popover right in the Edit Script pane. This improvement will lead to faster script writing that’s more like code writing in other platforms. The Script Workspace also includes line numbers to make finding and reading specific sections of your code easier. A new Description area (under the Steps list) will save trips to the Help file if you need a short reminder about what a step is used for.

As welcome as these changes are, the new workflow takes some getting used to. Since you can still point and click, some folks won’t notice the change right way. That’s a good thing for the change-resistant, but it does tend to put the Script Workspace’s light under a bushel.

Here are our tips for learning to use the new Script Workspace without losing your mind.

Specify Calculation Window

The timesaving features of the Script Workspace are also ported to the Specify Calculation window. Select functions by typing, and setup calculations or specify options with keyboard controls. Just start typing the name of your function, and a popover list of functions whose names match your typing appear. When you see the function you need, use the Up or Down arrow keys to select it, and then press Enter. If the function takes parameters, you can just start typing them to see another list.

The popover list of matching functions also includes table and field names. You can enter even the longest fully-qualified field name with just a few keystrokes. For example, if you want to add a reference to the Estimate::Date field, do this:

Type “e,” then press the Down arrow to select Estimate (your table’s name) from the list.
Press Enter. “Estimate::” is entered into your calculation. The list automatically shows the fields from Estimate table.
Use the arrow keys or type a “d” to select the Date field. Press Enter again, and the field reference is complete.

This is one of those shortcuts that takes way longer to describe than to do. And as with the Script Workspace, this keyboard driven assembly will take some getting used to. But after a few hours of practice, you’ll wonder how you ever put up with mouse-based scripting and calculation writing.

Heaven help us all during the switchover period when we’re working in both FileMaker 13 and 14.

Navigation Tools

A new Navigation layout part and the new Button Bar tool lets you create modern navigation bars that float at the top of your layout no matter how far you scroll.

Navigation Parts

There are actually two versions of this new layout part: Top Navigation and Bottom Navigation. Like Headers and Footers, they anchor to the top or bottom of your layouts. Navigation parts don’t print by default, so they behave the way you’d expect them to right out of the box. These parts can’t be scrolled or zoomed, and if you throw a field in one of them, the data from the current record is shown. You can only have one of each part on a layout, but you can create sophisticated navigation systems by putting your main navigation in a Top Nav part, and your context sensitive buttons, or a lower level navigation in a Bottom Nav part.

Button Bars

The new Button Bar tool lets you create several related buttons at one time. Each segment behaves like an individual button and can have its own script or script step attached. You can even mix buttons and popovers in a button bar. So even though FileMaker still doesn’t have templates or master pages, now you can create a navigation or context-sensitive button bar and copy/paste the whole bar to a new layout. This will be another huge timesaver for making your database’s interface more consistent and professional-looking. Here are some other ways Button Bars will make your life easier:

Button Bars re-size as one unit, so they’ll behave better than single buttons when windows are re-sized.
Button Bars can have calculated names. That way you can use one bar on layouts used by users with different roles. Your script can check for privilege set before deciding which action to take, and now the button that runs it can display different text to help orient (or train) users.
All segments of a bar share the same style, which makes consistency easier and more fool-proof (you can’t forget to apply a style to one segment, for example).
Segments can have their own individual conditional formats.
Segments can have their own script triggers.
Segments can be hidden with the “Hide object when” option.

These two navigation improvements don’t stop with making development more efficient. Knowing that you can use Navigation Parts and Button Bars can help you think more clearly about your database’s organization before you even open FileMaker to define your first table. Try sketching out navigation along with your ER diagrams and you’ll start to see how quickly your thinking about how a database will function becomes more clear.

Button Improvements

Even without the new Button Bar, Button handling has been upgraded to let you add text or an icon, or a combination of both. When you display both, you can even choose how the two elements relate to each other—you can put text above or below the icon, or to the right or left of the icon. The Button Setup dialog box comes loaded with a set of icons (called Glyphs) that you can choose. Once you’ve selected an icon, you can resize it with the slider that sits just below the glyph window.

Glyphs appear grey in the dialog box, but are black on the button by default. But you don’t have to live with that color. Glyphs have their own object state. Once you have all the options set in the Button Setup window, travel over to the Inspector, click the Appearance tab, and then change the top object state pop-up to Button: Icon. That’s where you change the glyph’s color to match your color scheme.

If none of the default icons meet your needs, you can add your own custom glyphs, as long as they’re PNG or SVG format. Use the “+” button under the glyph window to import the file.

Note that button glyphs are more than just a convenience. Early testing indicates that glyphs help your layouts render faster than text used as icons (say if you used a “+” symbol from your keyboard instead of the glyph).

Minimalist Styles

FileMaker’s styles are useful for that quick and dirty database you need to throw together in a few hours. But most professional developers create their own custom styles that matches their clients’ branding (or their own). It’s a huge amount of work changing a mature style since every single style—along with all their object states—have to be updated. New themes, called Minimalist and Minimalist Touch, start out with no pre-defined styles except the Default style for each object type. That way, there are no styles to re-define or re-name and no unused custom styles to delete. Just start creating the styles you need.

That old bane Classic style is no longer included in new files you create with FileMaker 14. But you’ll still see it if you convert an old file, either from pre-12 version that had no styles to begin with, or one that created back when Classic was a thing.

FileMaker Go Script Steps

You’ll have more control over your users’ FileMaker Go experience with a few new script steps:

Set Allowed Orientations lets you limit screen flip on those layouts that you design not to rotate.
Enable Touch Keyboard lets you enable, or more importantly, disable the touch keyboard. This steps works on FileMaker Go and under Windows 8 touchscreens.

What features are you looking forward to using? Leave a comment or question below.

FileMaker Pro 14: The Missing Manual is now available for pre-order. Set for release May 23, 2015.

May 7, 2015
-

ROI on User Centered Design

Category : Design , FileMaker , User Experience

You may have heard that User Centered Design (UCD) costs more up front. Project Managers have definitely heard it, and sometimes, they’ll balk at a new approach based on cost alone. In response, you’ll need to give those PMs some arguments they can use to make a case for UCD to their bosses.

When users are involved in development from the beginning the project is much less likely to fail because:

goals and requirements are clearly understood by all parties
goals and requirements are reiterated throughout the development process
if goals or requirements change, then the delivered software can match the the moving target of shifting goals
users need little or no training because they’ve been testing and using the software BEFORE launch
testing undercovers more bugs before launch, which gives you time to fix them when it’s less expensive
tech support costs go down, due to fewer errors

All these items are above-the-line costs. You can quantify the savings when a project launch requires less training and tech support. If there are bugs that cause downtime or financial errors, it’s easy to see how much that would cost.

And that’s just the internal ROI. If the software is for online shopping carts, or retail order fulfillment, then you can include an increase in sales after the software is launched in the ROI calcualtion. Don’t forget the ROI studies specifically on document management have estimated that up 30% of a person’s work week is spent looking for the resources they need. So the ROI on that software is 30% of each user’s annual salary. So that’s the business case for User Centered Design.

But don’t forget the intangible, below-the-line ROI of having passionate users who are now more effective and efficient at their jobs because you’ve created a great user experience for them.

May 1, 2015
-

Why Software Fails

Category : FileMaker

The Institute of Electrical and Electronics Engineers (IEEE) did a study in 2005 that examined large software project failures (in the multimillion and billion dollar range) to try and figure out what they had in common. Here are a few facts sobering distilled from that report:

$1 TRILLION spent worldwide on hardware, software and services
5 to 15% of IT projects are abandoned before or shortly after delivery
Companies budget 4-5% of annual revenue to IT projects (including software and hardware)
IT companies budget 10%

In other words, as much as 15% of all money spent on custom software development is wasted because the projects never fledge. That’s staggering. If we cut the 5-15% figure down the middle and say that only 10% of projects fail, we’re still talking about $100 billion dollars wasted annually.

These figures are for in-house projects. Consultant projects don’t fare as well. Those projects have a 15-62% success rate. Also the larger a project is, the higher its risk for failure. Larger projects fail 3-5 times as often as smaller projects. That’s because it’s harder to spec, build, and test a large project.

And as any developer knows, software is inherently fragile. You can have perfect schema, beautiful layouts, and well-thought out processes, but a single bug can cause a critical script to fail. Programmers typically spend 40-50% of their time reworking processes to fix bugs instead of creating new, value-added features. Bugs or errors that make it into a launched product can cost 100 times more to fix than if they’d been spec’d properly or caught and fixed early. Anybody who’s launched a database knows why: real data is at stake, so you have to take twice as much care finding and fixing errors after a database goes live.

One major problem is that old-style development processes—the ones that were more common back in 2005 when this report was written—aren’t optimal for preventing errors. Instead they count on a limited round of testing just before launch to find and fix errors. This is hard enough to do when the errors are programming bugs. But if the errors are due to poor planning, bad specs, or poor communication then it’s easy to see why such software can’t be repaired well enough to launch it. One major solution is to use a method of development that can prevent errors from getting into your software in the first place.

The IEEE report says that IT projects fail when the costs to repair badly-done works exceeds the cost of creating spec’d features. Some of the causes they cite are:

Unrealistic or unarticulated goals
Badly defined requirements
Inaccurate estimates
Poor communication
Poor management
Use of immature, or inappropriate technology
Stakeholder politics

Fight Failure with User Centered Design

Next time you get pushback from a client about the extra costs of the planning and design phases of a project, refer to some of these facts about why software fails. It’s easy to see where taking preventative measure gets a big ROI if the project takes user needs into account from the get-go. True, User Centered Design (UCD) doesn’t fix all the problems cited by the IEEE. UCD can’t fix budget, scheduling or bad technology choices.

But even an outside consultant can overcome bad management and poor communication when UCD techniques is applied to a project. UCD is all about developing regular contact with users. So if you’re working on a project where goals are poorly articulated, access to users will help you figure out what the goals are. It’s the same with gathering requirements: when meet with users, they’ll tell you what the requirements mean. And since User Centered Design is all about regular communication, you’ll eliminate the problem of inadequate communication between all the players.

Poor project management can be the result of not knowing how software development works. With a UCD approach, you can effectively become the project manager, or at least steer the manager in the right direction. When you have direct access to users, you can give more weight to the Pam Halberts on the team over the Dwight Schrute types who’d rather see a project fail than see other team members succeed.

Download the full report.

April 29, 2015
-

Define: User Experience

Category : FileMaker , User Experience

The term User Experience (UX) is usually applied to developing startup app companies or web services where there may not be an existing market. In those cases, the company doesn’t have a customer base yet, but they’re using the principles of UX as part of the whole package they’re offering to prospective customers. These new websites and apps are changing our mental models of how software should work. Even if your users have never heard the term “User Experience” you can be sure they have worked with software built on its principles and have expectations about how software should look and feel.

But UX principles aren’t just applied to the web. Retail stores and restaurants and even physical products are paying attention to how the user feels when they interact with them. Some UX specialists analyze how people feel when they walk into a store or restaurant, and then give owners ways to improve the UX, and strengthen the bond with their customers. Some of those principles, like the aroma of cooking food, or the physical display of products at a store’s entry, aren’t directly applicable software UX, but you only have to twist the concept a little to make it fit.

Your software can’t give off the comforting smell of cinammon when a user launches your database, but they’ll form a first impression nonethless. They’ll be watching how your database launches, and what you’ve chosen to show them from the moment the first window is drawn and data starts to display. They’ll be looking at speed, and arrangement of data, and whether the tools they need are easy to spot and simple to use.

So it makes sense to understand how and where we can apply them to FileMaker design and development. First, let’s define a few terms that represent design specialties under the broader umbrella of UX:

Visual Design is the look and feel of the user interface. It’s the graphic choices you make on your layouts. Visual design includes colors, images, fonts, and symbols. It’s usually the first thing people notice about your software, and it’s the part of UX that most people are most comfortable talking about. But while good design choices are a big part of overall user satisfaction, it’s far from the only thing users experience. All the following terms are also part of UX, but they’re a little harder to grasp.

Information architecture is just what it sounds like and a little more besides. It refers to how the data in your software is organized for storage, but it also refers to the way that data is presented to your users. Does your architecture match users’ mental models of their data? Does your presentation match their work flow?

A subdiscipline of information architecture is Structure. You already design tables and records for good normalization. But structure also refers to the way data points relate to one another. What’s the context in which they’re presented, analyzed or manipulated? Does your database’s structure make it clear to users how the data is related? Is it easy for them grasp how a list of contact methods relates to a single person’s data?

Information refers to your data, but also to metadata that describes or enhances that data. In FileMaker, metadata might be things like creator and creation date data, or filetypes and paths in a document storage system. The term “information” also includes the business rules that describe how you gather and treat your data. How are discounts on invoices given? How and when are receipts issued? Who can void an Invoice?

Users need to be able to Find and Manage data. FileMaker gives us good native tools for finding and displaying data, but we often have to create custom, scripted Find processes to make it easier for our users. For an even better UX, we can think of ways to show the user what they need without entering Find mode. For example, you can show users with a list of their daily appointments when they log in, or the open items on a To Do List.

Interaction Design is how your database behaves when users navigate to a layout, click on a button or need to scroll a portal or a field. Again some of FileMaker’s interaction design is native. Portals have scroll bars for viewing a long list of related records. We can show active record states or active portal row states as highlights to help users keep their place on screen as they work with lists or portals full of records.

Affordance is a specific type of interaction design that refers to feedback from the system that makes it feel responsive to the user. Active record states and object states (normal, hover, pressed, and in focus for buttons, for example) make a database affordant—users see objects respond as they explore a new interface with their mouses. Affordance makes a database feel responsive, but it’s also a teaching device. A field that highlights when you click on it is inviting interaction from the user and makes the field’s purpose a little more clear.

All the above design choices add up to create Usablity. Can your users get their jobs done more easily with your software or does it stand between them and their work? Have you created clean, uncluttered layouts that present data efficiently? Are buttons easy to find and use? Is the system reliable? Can users trust it or does it have performance or stability problems that make it slow or difficult to use?

In a big development firm, specialists in each of the disciplines might collaborate on every project. If you’re on a smaller team, you might have to switch hats. Even if you’re a one-person development shop, you may focus in a few of these specialties. But just understanding these terms, and how they can affect UX, will expand your set of design tools

April 22, 2015
-

Don’t Blame Users

Category : FileMaker

When things go south in your software, don’t blame users. Let me tell you a cautionary tale about what that blame does to user experience. I’d gotten an email from a vendor that I already had had a good experience with. They were promoting a new product that looked interesting so I clicked on the link, watched a video, read some marketing stuff and decided to buy it. Pretty good user experience, right? If had one of those satisfaction monitors that some of the reality shows have, you know those dials where you can dial it up to show you’re happy or dial it down to show you don’t like what’s happening. Well, I was well into the good zone.

Everybody knows how to buy something online right? We all have what are called “mental models” of how online shopping works. Mental models are extremely important in UX/UCD, and the idea is that we think we know how something works because we extrapolate from something else. Maybe it’s another online retailer, maybe it’s some instructions we read, maybe it’s what somebody else told us. Anyway, my mental model was that I was going to click somewhere to add this software to my shopping cart, and then there’d be some kind of payment dance, and when I was done, the download would start.

So the software is in my cart, no problem. But there are two buttons for payment: one button was for using PayPal and the other one was for using PayPal to pay with a credit card. And really the last thing online retailers should want is to slow users down by making them think about which payment button to click. What if the effort of having to think about which button to click slows me down just enough to interrupt my purchase?

But I clicked the second one and went through checkout. It was one of those sites where when you purchase something new it appears in your account for downloading. But nothing new showed up in my account. That glow is dimming some more.
So I figured I’d done something wrong (now I feel stupid AND not as happy as I was five minutes ago). But I still wanted the software so I went through the checkout process again, this time successfully. (Light’s shining a little brighter now). All was well until I checked my email and got two notices from the vendor and two notices from my charge card company. What do you think that did to my software therapy afterglow?

But the vendor provides good UX because my account page has a contact us button on it, so I explain the issue in an email and trust them to handle the problem. I figure it’s just a matter of them sending me a refund, and then we’re all on our way.

Now I’m sure the customer support person didn’t make the confusing buttons on the company’s website. But she still provided some pretty poor UX in her email to me: “I see the issue now. You should have followed instructions….”

Blaming users when the software goes wrong only compounds the problem. I design software for a living. I figure that I know how developers think and that I can work my way through most systems. But their ambiguous button naming was the problem. And then they blamed the me for getting confused.

You can have great software and then completely ruin a user’s buzz with blame-y customer support. But here’s the truth—if the user gets confused in my software, it’s my fault for not creating it the right way. I’ve got to put on my big developer pants and figure out how to keep them from getting confused. That might mean better button names, better feedback, or a completely different process. If I’m in regular contact with the users during development, they’re going to tell me what doesn’t work early in the process so that I can fix without a big impact on the schedule and budget.

April 20, 2015
-

Demo and Discovery

Category : Data Visualization , FileMaker

Define: Demo and discovery

Demonstration and discovery is what we call the regular meetings we hold with our database manager and the stakeholders (who might be the whole user group, or a representative sample). It’s where we figure out the details of the use cases we’re developing. Back when I started developing in FileMaker, we used the old school development method called Waterfall.

Waterfall

The old school process puts huge effort into writing these detailed requirements that describe everything about the database, including what every single function should be and often even every step the software will take to get each job done. Since so much effort goes into creating them, the requirements are committed to stone, and they are rarely changed during development. In this process, production is the king. The thought is: we have a product outlined and we know exactly what it needs to do. Here’s the document that describes what we know, now you go off and make it so. This process is called “waterfall” because from concept to requirements to handing off to a developer, the process moves forward for really long time before there’s anything you can demonstrate or test.

In this scenario, the user may or may not have been involved in creating the requirements. Old school development is agnostic on that point. A manager, or an engineer, may have written the requirements. But even if end users had input on the requirements documentation, they don’t come back into the process until after development is done and the whole database is ready to test as a unit. Users test, somebody consolidates their feedback and gives it to the developer, who fixes the bugs (the ones that were found), and the project is deployed. Waterfall development can leave lots of bugs because it’s really hard to test a whole software program at one time. So often, the deployment phase—with live data and sometimes harried users—has multiple bug fix/maintenance releases, and while that’s happening, the product gets analyzed for new features, new requirements are written and the process starts over for the next whole number release.

New School: Agile

So in response to waterfall’s weaknesses, a new school of development, called Agile, started to gain traction. Agile is so widely used these days that’s it surprises me a little to remember how revolutionary it seemed at the time. Waterfall development can feel constricting because you’d often learn something in the course of development that cries out for changing the requirements. But if you do change requirements, all that time spent up front refining detailed requirements is wasted. The engineers, marketers, and managers who’d spent so much time on developing requirements worried that their analysis would be thrown out the window if requirements were allowed to change along the way.

Here’s how Agile development works: you still start with a specific need for a piece of software, and requirements are written. But they aren’t detailed. Agile requirements describe what the database needs to do, but not how it will get those tasks done. Now the first thing that happens is that a team of requirements folks (which should include users or user proxies) meet with the development team and they analyze a small set of the requirements. Those are developed, demoed, tested, and bugfixed. Then the team bites off another chunk and runs the analyze, develop, text process again. But in this cycle, you get the benefit of whatever you learned in the first cycle. You might have thrown some sample data into the prototype database and found out that the original analysis about structure or how some feature needed to work was wrong. So you bring that up at the next analysis meeting, figure out how to adjust and move on. This cycle gets repeated with new requirements until the whole package is built.

With Agile, the software has been tested, bugfixed and improved throughout the whole development process. Bugs and errors are fewer and less serious at deployment. It’s true that the package often looks fairly different than the original concept, but it tends to ends up with more satisfied users because of the benefits of iterated development.

dbhq.net

Category Archives: FileMaker

2