From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer
Generally FileMaker solutions are designed to meet three possible end user situations. A developer designs it for their own company for internal use. A consultant designs the solution for a clients use. Finally a developer designs the solution to be sold to customers.
At first glance, you may say that they are all the same. If a calendar solution needs to be created, the three different categories shouldn't change the final result. However, that is not true. In custom design projects, such as the first two instances, the database is likely to have a lot of features unique to a company or a department needs. The flow of the solution can be a little less polished because a support person can be right there to help someone that is stuck. Also in both of these instances, you may want the FileMaker database to look and feel like some other tool used in the company.
For example, a company may have a large invoicing system built in Oracle and the developer is hired to build a FileMaker solution to handle customer satisfaction issues with those invoices. The customer wants a FileMaker solution because it is cheaper and faster to implement and is more flexible for spur of the moment needs. In a case like this, the developer may decide to make the FileMaker solution look and feel much like the Oracle invoice system. This would help keep users for experiencing "interface shock" and potentially lower training requirements for the new database.
In the design of a solution for resale, you have to think about the larger general public. You need to think more like a Microsoft, Apple, Adobe or even FileMaker Inc. Even the most experienced FileMaker developer can benefit from some reflection on how to build a FileMaker based software solution for resale to the general public. In many ways, this becomes more of an art form than a software tool production. There are some FileMaker solutions that I consider art because of the high ease of use married with an elegant user interface.
However, the bottom line is that you should not design for what you think is easy or elegant. You should design for what you think the market will consider easy to use and elegant. You might jump to the conclusion that they are one in the same. That could be a fatal mistake.
You may have a list of pet peeves in regards to software releases from your favorite software vendors ("Why do they refuse to add this feature?"). Heck, even FileMaker has someone voice a pet peeves about feature requests in a new version every now and then. When you start walking the miles in their shoes, you may begin to realize the reason behind them. You will begin to realize that building the perfect or even nearly perfect FileMaker solution for a particular need had hurdles to overcome that you never considered.
I’d also like to add a comment for the weekend warrior developer out there. If you are considering marketing a FileMaker solution but more as a hobby, then by all means have fun. Feel free to experiment with different designs and try to market them. You can also make a 2.0, 3.0 or later version that will have more of a polish to them.
More info about the author and FileMaker in general, contact me at email@example.com.
© 2008 - Dwayne Wright - dwaynewright.com
The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.