Review Request

[MelJ]

I'm learning from scratch as I go so please don't laugh too hard!!

I have a very small portion of, what I hope will become, a full blown solution some day.

I would really appreciate it if everyone in the know would take a peek and let me know how I'm doing and where I can improve. I'm certain there are allot of short cuts I haven't learned yet.

The plugin I'm using was too large to upload here. Here's a Link to the plugin on my website. (Trial version of course). It is "Dacons Scriptfire".

I'm afraid without the plugin my scripts might be meaningless. (On the other hand, they might be meaningless WITH it!)

Thanks a million for all your help.

Mel

Greenville_Cabinets.zip

[sbg2]

I'm not real big on plug-ins so I didn't look at that part of it. One thing that bothers me right away is making the background a button that does nothing, not sure what you were going for here. Also, it appears your contacts should be in a seperate table from Builders List file. See the example I attached in the thread - two questions about layout and adding contacts . Lastly I think its great that you know how to make some 3D text and add a dropshadow but I am of the firm opinion that a normal button is much more usuer friendly, keeping things simple looks and works better IMO.

[Ted S]

MelJ,

In your scripts I see validation like:

If ( BlanketyBlank > " " Then ...

I assume you attempting to validate whether a field is blank (null) or not?  If this is the case then you might want to try this:

If ( IsEmpty ( BlanketyBlank ) Then ...

or this:

If not ( IsEmpty ( BlanketyBlank ) Then ...

[MelJ]

Hi SBG2!

Thanks for the critique and the sample file. It never occurred to me to keep the info in separate files.

In answer to the "button behind everything"...

I have a "Save Record" button that I absolutely have to have the user push to save the record. It has allot of validating in it. I thought I had everything taken care of in that dept. when I learned that all the user had to do was click outside of any field and Filemaker would politely ask if they wanted to save the file! Completely bypassing my validation script! Someone (who will remain nameless) suggested the "big button" idea and it worked. I'm not really a fan of the flashing black background but if it works it's a small price to pay.

As for the graphic buttons, I was playing around with them. As my solution develops (and I learn how to make my own drop down menus) the buttons are most assuredly going to standard buttons.

I really appreciate your taking time to look at it and if you have any other suggestions....

Give it to me straight!! (I can take it!) :smirk:

[MelJ]

Hi Ted,

Thanks for the info.

I've been glancing at the Isempty frequently but afraid to touch it fearing I might blow something up.

I'll start getting into the habit immediately.

Thanks for the Help

Mel

[Ender]

Hi Mel,

I hate to be the one to throw ice water on your lap, but I took a look at your solution, and found it very confusing (both from the user perspective, and from the design perspective.) So having asked for it, here's some constructive criticism:

1. I don't get what the purpose of the "Main Menu" file is. It has no fields and no relationships. Why not just use a layout from one of the other files?

2. While I'm on it, it's not clear why you chose to use separate files for Jobs and Builders. With FM8's multi-table capability, it's much easier to design the solution all in one file.

3. The attempt at preventing the user from committing the record outside of the Save script doesn't seem to work against my simple attempts to bypass it. A user can hit the Enter key or flip to another record to exit the unsaved record, and get the Save dialog. If you truely want to prevent record changes unless a script checks it, you might try using a set of globals to hold the values, and have the scripts set the real fields with the contents of the globals.

That said, in most cases, I don't like enforcing validation like this ("You can't continue unless you fill in field x." followed thereafter by, "You can't continue unless you fill in field y.") Users quickly get annoyed by these types of validations. Just imagine situations where they don't have every bit of information for the form, or their work gets interrupted in the middle of data entry.

The validation method you've worked out is also very confusing to understand in the scripting. What happens when fields are added or removed? You have to find where scripts where those validations occur, and add or remove the fields to each. What happens when you're no longer around? The scripting is going to be rather confusing for the next guy.

In my opinion, it's better to use a passive approach to validation. Use status flags to indicate when various sections are complete, or don't allow the record to be "Active" unless a validation script checks everything and sets the Status.

4. The layouts do not have a consistent size, and the placement of the elements is not consistent. The Jobs layout barely fits on my 23" cinema display, while the Builder Add/Edit layout seems to be made for a vertical 8.5 x 11 display. This may not seem like a big deal, but having things spaced consistently and keeping the buttons alike and in the same place from layout-to-layout is a great way to make it all cohesive. You can make a template layout, and copy and paste it to each layout to help with placement. It is also a good idea to make sure view/data-entry Form View layouts fit within the smallest typical resolution that your users might have (without making them scroll.) If necessary, use a set of button tabs to separate different sections into multiple layouts (or Tab Control panels.)

5. When changing files, the previous file stays up in the background. This may be fine for the Main Menu, but your data-entry screens should probably go away when you leave them.

6. The duplicate table occurence names don't describe what the TO is related by. It is much more helpful to have TOs named by what their keys are or what they're used for, than to simply have a series of TOs named "Job", "Job 2", "Job 3", etc.

7. I didn't see any List View layouts, or selection portals. You should consider these as ways for users to choose the right Customer or Job from a list of search results.

8. As you're working on these files for your client (or prospective clients,) you may also want to have an example of a print layout and a report. These should be separate layouts specifically designed for printing.

9. You should not forget the Access Privileges part of the solution, as this can be a significant amount of work. This is also an area that's easier to manage if everything is all in one file.

10. I found it hard to tell if I was in Edit mode on a record, or if I was in Find Mode. I'd suggest using visual cues to make it clearer when the user is in Find Mode. Personally, I use dedicated Find Screens that have a different field background color. The Find process goes to the Find Screen, then when the Find is executed, the layout switches to a List View (or in some cases, directly to the View/Edit screen if there is only one record found.)

Overall, I guess I'd recommend studying other people's solutions to get a feel for what makes them easy to use and easy to understand from a developer's perspective. Check out the templates that come with FileMaker Pro, check out the Business Tracker solution, check out some of the published templates by other developers.

Anyway, that should be enough for now. Hope that wasn't too harsh. :

[MelJ]

WOW!!

I had to print that reply out! I'll be referring to it for weeks. That's great stuff!

Keep in mind I'm you're "less than average" beginner. This is the kind of stuff I need. Thank you soooo much for the detailed critique. Some of the items you mentioned I will have to figure out how to impliment..(consistent screen size for one).. they all "look" the same size on my screen.

Ayway, I love learning this stuff and I'll keep pluggin away!

Thanks again for all your help!

Mel