Is It A Good Idea To Use Table View Instead of List View?

[jmci]

A client has asked me to design a custom CRM system for his company to replace a legacy system. This client has some familiarity with FileMaker Pro. In initial discussions he is hot on the idea of using table view instead of list view layouts. I've been a contract developer using FileMaker for many years and have never employed table view in a project I've delivered to another company. I know that table view has evolved somewhat recently and I'm interested in hearing the community's opinion of the advisability of using table view instead of list view and the reasons pro and con. If it's as bad an idea as I believe it to be I want to be able to present a compelling argument, if not, I need to be convinced by professionals.

[Ocean West]

i don't prefer to use the table view as a end user forward feature - unless you have implemented much tighter security model where they can't modify schema, or add fields to the layout..

Out of the box the user can ADD Fields to the table using table view - and also add records to the table view - in some cases you would prefer them to have a script add records depending on the structure of your solution.

List view you can control what goes on it and provide better interface with live sub summaries.

The list view has only a 3 pixel shift between form view and list view where as the table view has a 20+ pixel margin on the left for the ability to add records.

Also to know that if you have any <<MERGED>> field on a layout and you switch to table view that value becomes editable.

In table view you cannot add buttons to the body section to take you to related records, as you can in list view -

[LaRetta]

And portals will not work in table view either. Even as Developer and KNOWING how dangerous it is, I can accidentally create a new record or field. The only thing you can't duplicate with List view is reordering the columns. I replace all table views with form or list views.

Oh, you also can't have same field more than once on table view. This is bad if you've stacked fields.

Stephen said, "Also to know that if you have any <<MERGED>> field on a layout and you switch to table view that value becomes editable."

Wow. I did not know this. Another reason to scratch table layouts.

[LaRetta]

Oh, another bad reason ... table views produce the full table occurrence/field name which looks funky and the first thing they will want is to rename them. Of course you can't ... you can uncheck 'include column labels' but then you can't sort or reorder. You can place field labels over the existing labels but they will not move if you reorder.

FMI has added functionality to table view WITHOUT also providing developer tools to control it properly ... same with Status bar. A real shame too.

[Raybaudi]

the first thing they will want is to rename them ...

... and they can, leaving your solution with renamed fields.

( it seems strange but you can rename which ever field of the current table, simply selecting ( double clicking ) the column label )

[LaRetta]

True - thank you for mentioning that, Daniele although I was assuming correct privileges are in place to stop new records or fields so it would stop renaming as well. From the few times I've allowed tables, Users did not like seeing the related table occurrence names and we can't control that either.

Table view is dangerous even for the developer ... even though I KNOW it is easy to accidently create a field or record, I've still done it by accident and that's why I finally decided to drop them from my tool kit completely.

[Raybaudi]

I'm of the same opinion!

[RodSierra]

I also agree with all of the above and have never turned on table view in any of my solutions. Some of the features would give me some report flexibility, but not being able to have better control makes it impossible to use. It's all or nothing, so I chose nothing.

[David Jondreau]

Users often like a spreadsheet view ( and I sympathize ). I consider it my responsibility to make Filemaker satisfy what users want. It's not always possible, but a functioning table view isn't that hard to get right.

I usually have a separate table view only layout for most of my major layouts. There are some considerations when having table view, but nothing insurmountable.

For key fields (or fields auto-entered from key fields) I either turn off access in Browse mode or use script triggers to allow editing (script goes and finds the key and enters it).

For buttons, I use fields with script triggers.

I alrady use "natural naming" for fields, so the column headers look fine.