 |
|
| December 2002 In this Issue Main feature How to make a clean mess and keep a happy system So how do I get that @@#$!!&** structure right? A Taste of Normalization (Getting the structure perfect) Prototyping along the way What's Next Tips from the KnowledgeBase Calculation fields— unstored vs stored Your Reference & Action Points Use the User Interview form in the Developer Companion Show me now Back to top Back to top How to get yourself out of this mess before you get into it is covered in a later article. I also suggest reading up on the 'Better FileMaker Structures' document from QuickToolKit.net Show me now Back to top Back to top Have a good reading of the 'Better FileMaker Structures' document. Show me now Back to top To see a video taking you through this example in more detail click here to: Download or View To see a video taking you through this example in more detail click here to: Download or View Back to top Back to top To see a video taking you through this example in more detail click here to: Download or View Back to top Back to top Back to top Visit Quicktoolkit.net now for a closer look Back to top Back to top Back to top Back to top Back to top Back to top |
In each issue you will find an article, usually with lots of illustrations and examples. In each issue you will also find a more technical article taking you through a specific subject. These technical articles are usually supported by example files downloadable from our web site. Finally we present to you some special offers, for Better•FileMaker•Developer subscribers only, which we have negotiated through our partners. Best of all, we assume you will really be too busy to learn anything new. That's why we have introduced our concept of effortless. So join us on this learning journey of becoming a Better•FileMaker•Developer. If you're not already a subscriber click here now to get a trial subscription for 6 months - it's absolutely free. To view back issues on the BFMD site, click here.
I can hear you ask "is it really necessary to drag me through all these dry bits?" Well, er, yes. BUT the first really nice bits arrive today, just wait till you see the videos. However, if you don't know the basics of good structure, whatever you do in FileMaker Pro will have a weak foundation. So, in the last issue we went through... Getting the right information from your users. * Who is a user anyway? * Defining your system - Outputs Defined - Control point outputs - Inputs Defined - Making your inputs clever - All about transactions * What information should you collect? * How to make a clean mess * Tips from the KnowledgeBase - Lookups and how they differ from other methods Probably the single most important bit was: ====================================== What should you collect? I always collect lots of stuff. The more the merrier.
======================================
Most importantly we will take a first glimpse at a universally successful development methodology. Ensure you get the system right EVERY time. So here goes
“Now, HANG ON”, I hear you say. “Didn't this guy tell us to specify from the rear end get the reports first?” Yes, go back and read it. I said specify, NOT build. By specifying from the rear you get valuable input to the correct structure of your solution. Without that you're lost. I mean completely L•O•S•T. However, if you implement the reports up front you're in trouble. Deep trouble, as a matter of fact. For many reasons
I suggest you take a thorough read of a document like "Better FileMaker Structures". In the next article we will cover the key principles of normalization (if this sounds pretty complicated, let me assure you it isn't). Even though I have studied with the founders of modern relational theory in my youth (hmm, many years ago) I'm not hung up on the finer details on this. This is, after all, FileMaker, and so it is a bit more forgiving than many other systems. Let us go through a quick example that will show you the key principles and I'm sure you'll quickly pick up the pace after that. Let's assume you're creating a new system for sales. You have a rough idea of what it should do (gather some contacts for prospecting but you suspect there is more to it). Simply list all the fields that you see (on reports, forms and that users speak about): - Company name - Company address - Phone - Person name - Person title - Last contact date - Contact notes - Product interests - Year founded - Account manager They have a contact list report like: – Name of account manager next to contact – Next contact date Which also includes Company name, phone They would also like to track orders like - Likely Order date - Product(s) concerned - Order value - Executing account manager - Order status - Stock status So after a brief look you can find at least two entities that seem well defined • Client (or prospect) • Order  You already figured out that the contact list could simply be a find function in the database, so that was easy. If you look closer at the Client entity you find it has a problem: In the real world one company can have many contact persons. Hmm, let's try and split it and see what happens:  The secret to figuring out whether this is right or wrong is reading the diagram. Over and over again. Aloud. Read it with the users (they will always pick out the holes). What I mean is “One Organization has one or more Person(s) attached to it.” “One Person belongs to one and only one Organization.” If both these statements keep sounding true you probably got the structure right. If not, rework it. In the next chapter we cover normalization in detail but as it is such a big topic we will start with a taste here:
Remember that whatever you decide can be correct (however, in practice most people would never want to call the switchboard but would rather call a specific person). This is the way you decide where certain fields belong and where processes (scripts) are run from. OK, hand there on the back row...? Yes, is this getting technically complex? Don't worry says Ed. We'll only cover the layman's version of it. Next, let's look at the contact list, concerning the entries you make there. Consider two scenarios:
Look back at the fields we had in the beginning: – Last contact date – Contact notes – Name of account manager who is to make next contact – Date of next contact In scenario [1] you probably just want four fields, probably just placed in the Company file In scenario [2], however, your structure is clearly inadequate. What you would need in order to adequately support your users’ processes would be a structure more like:  We have shown one of the key principles of how you validate your structure. Simply go through your processes. If your structure can hold the data you need, and it sounds like it will be easy for your users to do what they need to do according to the defined processes then your structure is right. Open FileMaker Pro now and start your definitions! We will cover this in much more details in the article following this one.
Now I want you to lean back for a moment and absorb this. You have just learnt one of the key steps on the path to becoming a BetterFileMakerDeveloper. So knowing all this, wouldn't it be better if you could simply build the system WITH your user. Along the lines of:
And so on... Do you think it is easier to get the users on your side for this kind of development? So is it possible to do this kind of step-by-step piecemeal prototyping approach? Well, that is exactly why I recommend people use QuickToolKit. Call me biased (I admit, it's true), but it has saved me hundreds upon hundreds of hours over the years just on this capability alone. Does that mean I don't specify a system first? Of course not! Any system is specified in detail. But in many cases you can build a mockup (that is by the way FULLY functional!) in QuickToolKit within an hour or two and thereby short-circuit a committee squabbling over whether they like blue or yellow buttons and who cannot agree whether the report should preview before printing. With the QuickToolKit prototyping approach you can show the user what it will look like and HOW it will work. And you can easily roleplay the structure of the database. If something is not quite right, hey, at this stage it is “no trouble” to move a few fields around. The difference between the QuickToolKit approach and doing the prototype in plain FileMaker is that you achieve instant operability. Users can navigate between files, switch between layouts, easily create or delete records. Even better, the training on how to use the finished solution starts right there as the final result will look just like the prototype, in fact it will just be an evolution from the prototype. And yes, I know, I'm biased, but this saves you SO much time and elegantly ensures you get it right.
One of the features in FileMaker Pro that is often overlooked is the ability to choose whether a calculation field should be stored or unstored. Generally speaking you have the choice to store a calculation field, except where the calculation references • A global field • A field in another file • Another field that itself is unstored • A GetSummary calculation ... and in certain situations a lookup field that looks up an unstored calculation from another file. In all other situations you can choose whether to store the calculation, or not. Stored vs Unstored—what does it mean? Storing a calculation means that the value is held (stored) in the file you're in. If the field is unstored it means that FileMaker Pro will calculate its value on the fly as the record is displayed. Especially in list views this may slow down the operation of your system. When you have a choice... There are certain types of calculations where FileMaker will allow you to store the result but where doing so generally will lead to the wrong result, or give unexpected results. Status() Any of the Status functions are meant to calculate on the fly the status as it is at the very moment of record display. If you store a calculation with Status() the value that is stored is the value the Status() had on record creation or when the Status() function first acquire a valid value. Aggregate Functions Count(), Max () Same as for Status() External Functions External functions include all calls to plugins as well as the external functions built into FileMaker Pro. Most external functions are only suited to be used in scripting or as part of a field validation (date, text, time, number fields). Always have a close look at the documentation that comes with a plugin to ensure you fully understand its use. In most cases I would recommend against attempting to store the calculation. Unstored calculations for reports and display purposes In many cases you may want to construct special fields for display or reporting purposes. Say for example you have a contact database, you could create a field called “Full Address” with a definition like: Address_Line_1 & “¶” & Address_Line_2 & “¶” & City & “ “ & State & “ “ & Zip_Code This field would then be easy to place on layouts for display, to use as a single merge field and so on. Do you store it? No, there is no point. Making such special fields eases your development and keeps your database slim. Finding on unstored calculations FileMaker allows you to perform finds on unstored calculations, even though they are not indexed. However, with many records this is a slow process. If you know that finding records on a certain fields will be required regularly see if there's a way to make the field stored (for example by creating a lookup field instead of a calculation field). How to Subscribe Subscribe today to take advantage of this special offer: Normally the article series is $97 per year but for the time being we’re offering you a 6-month subscription (web only) completely free. |
|