Tabs for Unique Info?

[HawkLA]

I am trying to create a Contact Database for my customers. Every customer has name, address, and stuff like that. I have 4-5 different types of customers that have additional information for each type.

My question is, do I make 4 different layouts for data entry, or do I make one layout with tabs for each customer type? If I do the tabs, I could have my data entry person click on the type of customer tab and input the additional information. Or should I make seperate data bases for the unique information and then link the databases for reporting?

What is the best way to do this? I have tired the Business Productivity Kit. Is this a good system to enter the customer info and then email groups of customers as needed?

I am really lost as to the best way to do this. I have spent hours reading and making tests in filemaker. I just don't want to start off with the wrong design. I need help! If you need more information, just let me know.

HAWKLA

[ThatOneGuy]

I have spent hours reading and making tests in filemaker. I just don't want to start off with the wrong design.

As frustrating as this may be, you're doing the right thing ... it's that ol' "ounce of prevention versus a pound of cure" challenge.

My question is, do I make 4 different layouts for data entry, or do I make one layout with tabs for each customer type? If I do the tabs, I could have my data entry person click on the type of customer tab and input the additional information. Or should I make seperate data bases for the unique information and then link the databases for reporting?

Again, you're asking yourself the right questions. Let's first focus on the latter ... the "separate tables" issue.

Prevailing relational database theory (as I understand it) guides us to break similar information into separate tables. In your example regarding Customers, I can see having separate tables for Addresses, Telephones, People*, etc. Not pulling any punches, this method does require us to have a good foundation on how to create and manage relationships in FM. At the same time, we have to "cut our teeth" on something; this model is a good candidate.

With respect to using Tab Panels or multiple layouts, you have an opportunity to express your creative talents. However, you'll always face "screen real estate" issues. (All of us always do!) If you go with separate tables, you'll probably need some room for portals. Will related fields and portals integrate more easily into Tab Panels or separate layouts? Only you can decide, but here are a few considerations:

Printing. Plan to have layouts dedicated for printing. It's more work, but it eliminates several restrictions.

For Tab Panels, only the default Tab Panel** will print. (Under FM8.5, this might be resolvable using "Go to Object" techniques. I'm still on 8.0 and can't be certain, so I'm going to leave the door open on this one.) Nonetheless, you could only print what you've provided within the Tab Panel. Someday, someone somewhere in your enterprise will want some other information to appear; that's a given.

For Portals, sooner or later the number of records related will exceed the number of portal rows you display. Many of us solve this by going to a layout in the related table (you guessed it ... a layout dedicated for printing) where we can print these related records more easily. Data from the parent record can be displayed there, as well.

Interface and Navigation. The endless quest for balance.

I love the Tab Panels introduced in FM8. They have become a common interface metaphor, so they're pretty intuitive for users. I use them in many places, but they don't fit all situations. In general, my users seem to have a little more difficulty thinking in terms of individual layouts. Still, it frequently comes down to real estate issues.

How many panels can we have in a Tab Control, while keeping the "titles" in each panel intuitive to users? Assuming a common resolution of 1024 x 768, I've often found it to be about six. Horizontal real estate is consumed quickly through the interplay of (1) the font selected, (2) the size of that font, (3) whether a "bold" style is applied, and most importantly (4) the length of the words themselves.***

If you opt for separate layouts, you'll need a well-thought scheme for navigating among them. FM7 introduced script parameters, and they've been a godsend for navigation.

Related Record Creation. Build for the future.

One of the options in defining Relationships is to allow record creation directly through a portal. It's such a handy feature, and weaning ourselves from it requires that we have in place an alternative method for creation of related records. The bad new is that it demands a lot of additional work. The good news is that you don't have to do it now ... just try to leave open the doorways that will allow for it in the future.

There are some drawbacks of creating related records directly within a portal. First, the more elaborate your database becomes, the more likely you'll face situations where all the necessary "keys" are not present in the parent record to fully populate the relationships you need.

This may sound abstract, but I've encountered these problems in a Customers -- Quotes -- Invoices -- LineItems -- Products -- Vendors scheme ... I need to create a LineItem for an Invoice, but I also need it to reference a particular Product of a certain Vendor. Through which portal should this happen? How will I populate this new LineItem record with all the foreign keys I need? I chose to solve it through scripting and modal windows.

Other downsides can occur in a multi-user environment with respect to record locking. When a user clicks into a record's field, that record becomes "busy" to all other users. No surprise there, but from what I've been able learn about FileMaker, the first record of any portal appearing on the active layout is also "locked." ... something in the way FM views that first related record as the "glue" when it looks at that relationship.

We might be able to mitigate this problem by turning off all "field entry" for the portal's related records. Of course, that pretty much forecloses the option of creating child records through the relationship, doesn't it? So, we're back to routines relying on modal windows, scripts, etc.

Don't let these "horror stories" discourage you, HAWKLA, just try to be thinking how you can leave yourself in a position to face them down the line. I've painted myself into corners many, many times. Developers who haven't are few (or perhaps deviating from the truth).

Man, I hope this stuff helps and that you don't take off running and screaming!

------

* While pondering this model, try to keep in mind that you may likely need the "People" table to have its own relationships to Addresses, Telephones, etc.

** The default Tab Panel can be established while in Layout Mode ... it's set when we last click on the desired Tab Panel then switch to Browse Mode.

*** Anal, I suppose, but "[W]hen I do my job, I am thinking about these things because when I do my job, that is what I think about." ... Laurie Anderson's "Langue d'Amour" from Mister Heartbreak (1984)

[bruceR]

More information on what you're trying to do is required in order to help you. What are the catgories, what are the different field types for each category?

[HawkLA]

I am a photographer. Here are a couple of examples. I have clients with babies. In addition to their contact info, they are scheduled to come in every 3 months from the baby's birth. I have calculated fields that compute this after I input the birthday. I also have wedding clients. Usually, they do not have new babies! So, They will not need the birthday fields, but they will need a wedding date field and contact information for the parents, in addition to perminant and temp addresses for the bride and groom.

What it comes down to is Data Entry. I do not need the wedding date field displayed for a baby client. One way I thought I might fix this is to put general contact info at the top of the form, and then have some tabs underneath that had one for babys and one for weddings that had the unique info for those clients.

I want to run reports that show me when my baby clients should schedule next and if the wedding clients need to place orders.

I will not be doing the data entry, so I need a simple interface for my workers to navigate when entering different types of clients. I hope this helps!