1 of 1 people found this helpful
As you note, estimates vary widely depending primarily on the complexity of the layout in question. FileMaker Advisor magazine published an estimating guide (attached) some time back (so it may be a little dated) that gave a guideline of 1 - 5 hours per layout.
Of course, if you're estimating how long it'll take you to build a layout, then I'd use how long it'll take you to build the layout instead of relying on a guideline from someone else.
Thanks so much for that - it's a great help. I know I have to go by my own judgement in the end. What I was trying to understand was whether my current experience is typical or whether I'm really, really slow because I'm so new at this game.
1 of 1 people found this helpful
Layouts, when done well, do take more time than 'coding'. The interface is what the user sees, so it is very important. It's not just a "FileMaker" thing. UI takes time.
-- sent from my iPhone4 --
I realise this a "how long is a piece of string" question,
That was my first thought when I saw the question... I love that expression because it describes the dilemma perfectly and I often say it to my clients.
It's like when they ask "can FileMaker do this or that..." I usually respond with something like "FileMaker can do anything I can make it do...".
I never get the estimates right... but I get closer every time I do it. The issue is not usually the layout itself... especially if you submit to the Themes... but rather the navigation, transaction and interface aspects of a layout that take the time. These generally mean scripts and conditional formatting etc etc. You can spend 10 hours on a layout with three fields on it...
I like to firstly draw a mud-map of each layout and assign a value of time in 15 minute increments to each feature that requires special treatment. That forces you to be able to remove yourself from wild guesses and from the impulse of saying "oh that will only take 5 minutes". Immediately you will have a bit of fat 'cause nothing actually takes 5 minutes.
Take conditional formating... could be that you select the object, open the dialog and choose from the menu and style options and click ok... and that is the end of it... OR you fiddle and test and fiddle and test a custom calculation for an hour. You must therefore be able to rate the difficulty of the task when making your estimate.... is it a 15, 30 or 45 minute job?
Like Mike suggested, a layout might take 1-5 hours to construct... but generally you will come back several times to tweak it or test. I generally work to a 4 hour estimate as a starting point and add or substract (rarely) degrees of difficulty and design requirements.
Mud map =?
How long does it take to write a song?
Billy Joel wrote in "The Entertainer" that it took 10 years.
Mud map = gardener's term to describe the sketch you draw in the dirt of the future garden layout
Wow... another cultural divide...
Ye olde 'mud map' is a common expression for a quick (and dirty) drawing of something. I do not know it from a gardening perspective but rather common usage in Australia.
I couldn't tell you any more how long it would take to develop a layout entirely from scratch, because I haven't done it in years. I use the standard trick of copying something that's CLOSE to what I want and modifying it. Thru the years I've developed lots of standard stuff — including, for example, an entire file dedicated to storing addresses and another devoted to storing an organization's basic ID info (name, addresses, URLs, officers, etc.). I just plug those in at a new client and have them ready to roll in under half an hour, no new coding needed at all.
Same deal for basic info like name components, a finance table, "Electros" (phone numbers, eddresses, and website URLs), metadata (primary key, found count, creation date, modification date, obsolete date), and support data (arbitrary tag, notes, temp, calc, length, etc.). All standardized, all appearing under the same headings in the same order in every table in every file I create. All using super-standardized naming conventions.
In setting up relationships, I go well out of my way to try to name the tables so that each one has a unique initial, for example, B for beings (people and organizations), E for electros, F for finances, I for invoices, L for line items, P for products, Q for quotes, and so on. Then I assign each one a mnemonic color, which can be evocative (money green for finances, electric yellow for electros) or alliterative (blue for beings, indigo for invoices, purple for products, quicksand for quotes, etc.). I use the plural name of the table for the anchor table occurrence, but the singular version for any of the buoys attached to it. For example, the anchor table "Beings" would have "Electro vB" and "Finance vB" hanging off of it. (The "v" is short for "via".) "Invoices" would have "LineItem vI" hanging off of it.
In my experience, having highly standardized naming conventions — which FileMaker the program doesn't give 2 hoots in hell about — is of immense long-term value to me as a developer, because it makes it easy to keep re-using the same work over and over again, instead of having to re-invent it from scratch each time.
Copy & Paste can be good for saving time but it can also bring in legacy rubbish that you have to shed. It also gives all your work a sort of same-ness which can be a good and a bad thing.
I use meaningful table names which are mindful of the sort order in lists. I also reflect the purpose of the relationship within the name where appropriate. Contrary to popular opinion on this point I do not end up with long relationship names. eg. just with invoices and invoice items I might have:
Invoices (base table)
InvoiceItems (base table)
Invoice_InvoiceItems (The basic relationship beween the two tables by Invoice.)
Invoices_invoiceItems (For relating to the whole found set of invoices)
When I get to the next level or a special purpose, I will use Inv_InvItems_by_status or Invs_InvItems_by_status or similar to refind for specific purposes.
All the tables are sorted alphabetically and easy to find. There is also no decoding by a key of meanings.
I also hate the fk pk etc notation. I have ID (which is the native primary key for the table) and ID_Table_purpose (purpose is optional). This means that all my IDs are grouped together in lists. It also makes it easy to copy & paste code in PHP as the ID will always be the ID whichever the table.
Thanks so much for that. That's exactly my experience. There are no shortcuts when it comes to user experience and while FM12 has some nice tools, it could use a few more
Thanks so much. As luck would have it, my first real project involves a lot of very intricate layout design requiring a high level of graphical aesthetics as well as some tricky user experience issues especially with FM Go. It's quite an initiation, but rewarding nonetheless.