Editor's Note -- This is the second in our ongoing series of articles exploring FileMaker Pro. In the first installment, Alan Graham introduced you to this venerable cross-platform relative database. Now in this article he shares some tips to help you design a clean, attractive user interface.
There's designing a database, and then there's designing a database. In this article we're going to discuss the latter, or at least some best practices for building an effective UI for an FMP solution. You'll also have access to some support files to help you with your work.
Most database solutions have a front end where users interface with data on a daily basis. Because of this you want to build an effective, yet attractive GUI for them to work with. I'll say it again, building an FMP solution is building an application within an application. And while a UI is an important factor, FMP is not the graphic designe's friend. It doesn't support transparency layers, and the graphics tools are circa 1986. Even so, you can still pull off some wonderful feats of design.
When designing an interface, remember that the people who'll use the solution aren't FMP developers. They don't know how to navigate layouts, create reports, jump between windows, build scripts, etc. This means that you have to build your solution just like any other application, making sure that users have a clean, clear, and consistent UI to work within.
Building a good UI has a lot to do with past experience, but even seasoned developers can't foresee every UI issue until the solution actually gets in front of its audience. I know that some of my best ideas have been shot down because I was thinking with my higher "developer brain" and not my primal "user brain."
The following tips have been gleaned from my Best Practices list. I will explore many of these in more detail in future articles.
Don't waste energy on a nice graphic design until you've had time to test the functionality of the solution and get it into some type of alpha/beta testing phase. Since FMP is not a graphic design application, you'll find that it can be rather unforgiving at times, so you don't want to jump back and forth between apps until you are comfortable that there won't be too many changes with the UI.
|
Related Reading Mac OS X Hacks |
Use a vector-based graphics program to create a library of common icons, buttons, and UI elements that you can use from solution to solution. I use Adobe's LiveMotion because it specializes in creating vector graphics for the Web, and file size is an issue when creating an FMP solution. I just copy and paste items between LiveMotion and FMP.
|
|
FMP doesn't respect transparency layers, so if you create drop shadows for UI elements, realize that you have a large marquis coming along for the ride. This means that a simple 32x32 icon could be more like 40x40 with a drop shadow and marquis. You can use these effects, just keep them tight.
|
Some UI elements can be created within FMP, but often they look crappy. Learn techniques (I'll cover these later) so you can mix and match elements from inside and outside FMP and keep the file size down.
I find that I typically use about 50/50, larger items coming from FMP and smaller icon-based elements coming from LiveMotion.
Be sure that once you define a graphical theme for your solution, you carry that across all of your files. Consistency is the key to user comfort.
The reason we have wizards is because users often feel daunted by large screens with numerous fields and buttons. You don't want to overwhelm a user, so think of splitting some tasks into steps. However, try to keep steps within a few screens or layouts. You don't want the tasks to be tedious. I try to keep my tasks to three steps or less.
An example might be in building a list. I often use a series of three screens to help users build a list. One involves a menu of what type of list (this selects the right layout), the next helps them select the data, and the third helps them use that data (print, email, view, etc.).
I often find that I develop solutions for different clients with similar needs. I hate to reprogram everything from scratch, so I keep a simple set of solutions that I can quickly customize for a client. This saves me a lot of development time and decreases my turnaround time for projects.
Users don't want to mess with toggling status areas and windows. Provide as much automation for simple and complex tasks as possible, but organize that automation. You don't want to litter a screen with 500 buttons. I'll cover some of these techniques in the future.
Build in safety nets. I find most users forget things or make simple mistakes, so performing certain scripted tasks, without dialogue, makes for forehead-whacking moments. I think the biggest of these is printing errors between the current record and records being browsed. All you need is a user sending 5,000 pages to a printer, when they only wanted one.
Another safety net is a global "Home" button. Sometimes, early in development or with new users, you have an issue where someone gets lost in the database and needs to get back to some place they recognize. I create a global field with a Home button that can take the user to a familiar location.
One of my favorite safety nets comes in the form of preventative modification and deleting records. You don't want to give deletion and modification power to just anyone.
Let's talk about deletion. We all know when a record is gone ... well, it's gone. Even if you back up records, you can't possibly track hundreds of thousands of records going back months and months. I never give anyone "god" power in my solutions ... and this is for their own good. I build a deletion script/button that allows a record to be marked as deleted and moved to an invisible/hidden database, or the "scrub" database. This database keeps all "deleted" records with their deletion dates and who the user was. Then an administrator can go through and restore any record from this file with the click of a button.
When it comes to modification, you know that once you modify a record and commit it, that's it. Even I have accidentally erased fields and changed data. I'll go into how I prevent these mistakes in another article.
Lastly, a global field with a "Bug Report/Help" button is valuable. I have two support buttons, one for reporting bugs/feature requests/support, and another which links my Instant Messenger to a "Helpline" button. This gives my client a "red phone" for those 911 moments. Plus, as a business measure, it gives me an added stream of revenue for providing this level of live support.
The night before Thanksgiving last year, a 911 moment occurred. Thanks to my support button and VPN, I was able to ensure an entire office of people were able to get out and off to their families. I don't have a family ... I'm a developer.
I'll be going into more detail on some of these topics in the future, but in the meantime I wanted to share a few files with you. The first file is a collection of buttons and other UI elements you can use in your solutions. They are LiveMotion files, so if you don't have the program, go over to Adobe and download the demo. You can play with them in LiveMotion, or you have 30 days to move them to your program of choice.
The second file is a collection of demos within FMP. I've built a run-only version (for those without FMP) and an open version that is unlocked and free to use anyway you like.
Alan Graham is the creator of the Best of Blogs book series and is a frequent writer on the O'Reilly Network.
Return to the Mac DevCenter.
Copyright © 2009 O'Reilly Media, Inc.
