1 2 Previous Next 22 Replies Latest reply on Apr 25, 2012 7:06 PM by bnsonger47

    Advisability of Using 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.

        • 1. Re: Advisability of Using Table View Instead of List View
          fmpvince

          No support for buttons in rows, therefore useless enough said !

          (usefull for development only)

           

          This is too bad, I wish FM Inc allowed buttons in rows

          • 2. Re: Advisability of Using Table View Instead of List View
            Mike_Mitchell

            My first question would be, why does the client favor Table View?

             

            My next question would be, what can you do in List View that would deliver that for him?

             

            I'm personally NOT a big fan of Table View for user access; too many opportunities for things to go wrong. And too little developer control.

             

            Mike

            • 3. Re: Advisability of Using Table View Instead of List View
              jmci

              He might just be trying to save money on development costs.

              • 4. Re: Advisability of Using Table View Instead of List View
                beverly

                jmci, on the + side, tables:

                     sortable columns

                     columns can be re-arraged

                     columns can be re-sized

                      

                I do limit access to tables and I don't like the ability to "create fields" with tables, but I understand this can be a training point as well.

                 

                find out why exactly tables are needed instead of list view.

                 

                Beverly

                 

                On 19 Feb 2012, at 7:59 PM, jmci wrote in whole or in part:

                created by jmci in Layout Design - View the full discussion

                He might just be trying to save money on development costs.

                 

                • 5. Re: Advisability of Using Table View Instead of List View
                  jmci

                  I'm hoping people will be more specific about "too many things to go wrong".

                  • 6. Re: Advisability of Using Table View Instead of List View
                    Mike_Mitchell

                    jmci -

                     

                    Table view, as Beverly mentioned, allows users to create fields - to edit schema. Generally a bad thing, especially if your user is passingly familiar with FileMaker and expects to be able to do so. That leaves you with two options: (1) Turn off that capability and deal with an angry client, or (2) leave that option open and lose control of the solution. Neither is good.

                     

                    Another huge problem with Table View is that users who come from an Excel or other spreadsheet background will expect it to act like a spreadsheet. They'll expect to be able to, for example, highlight a "range of cells" for editing. They'll expect to be able to "fill down". Ugly.

                     

                    You also lose a lot of control over the interface in Table View. You still can implement Script Triggers, but, as Vince pointed out, you can't add buttons, headers, etc. So features have to be implemented either through native FileMaker functions, the Scripts menu, or such Script Triggers as you can manage.

                     

                    Generally, I do not like Table View being exposed to users for these reasons. I hate the fact that FMI decided to make it the default view for new databases, because it trains people to expect it, and it encourages bad database design habits - people tend to make things flat file instead of relational because they just create fields as they go, just as if they were in Excel. I have a hard enough time training people away from a spreadsheet mentality as it is.

                     

                    Just MHO.

                     

                    Mike

                    • 7. Re: Advisability of Using Table View Instead of List View
                      Oliver_Reid

                      In some cases I find the customer really does get to appreciate the table structure of an application

                       

                      I have then set up a specific "Tables" interface file with special privilges that prevents things "going wrong" but  allows them to move around the tables and do custom searches and export the results to Excel.

                       

                      When the customee wants "all email addresses for people who are A but have not done B" they find this tool very useful.

                      • 8. Re: Advisability of Using Table View Instead of List View
                        jbante

                        Mike_Mitchell wrote:

                         

                        Table view, as Beverly mentioned, allows users to create fields - to edit schema. Generally a bad thing, especially if your user is passingly familiar with FileMaker and expects to be able to do so. ...

                         

                        Another huge problem with Table View is that users who come from an Excel or other spreadsheet background will expect it to act like a spreadsheet. They'll expect to be able to, for example, highlight a "range of cells" for editing. They'll expect to be able to "fill down". Ugly. ...

                         

                        You also lose a lot of control over the interface in Table View. You still can implement Script Triggers, but, as Vince pointed out, you can't add buttons, headers, etc.

                         

                        I agree with the concern that users may expect an interface that looks something like Excel to behave like Excel. However, your other points aren't necessarily true. Table view does not give users the ability to edit schema if users don't have that security privilege. If that makes customers angry, it's because there's some disagreement or misunderstanding about how much control the client should have over their application, or mistrust between the client and developer — relationship issues rather than design issues. Also, table view in recent versions of FileMaker does give us the option to include headers and footers in table view via "Layouts" > "Layout Setup" > "Views" > "Table View" > "Properties...". We can't have buttons on the records, but it's something.

                        • 9. Re: Advisability of Using Table View Instead of List View
                          Mike_Mitchell

                          jbante -

                           

                          Thanks for the tip on the Properties in Table View. Missed that. And yes, like I mentioned before, you can (and probably should, in most circumstances) turn off the client's access to edit schema in Table View. However, since the default in Table View is to have that access directly, it's more likely to lead the client down the primrose path of thinking he has it - meaning you are more likely to create a problem. He's expecting a spreadsheet, and you just gave him something that looks like a spreadsheet, but behaves differently. I'm guessing that this may be why the client wants Table View - because it's "so easy" to add new stuff. The fact that the client has "some" familiarity with FileMaker suggests it.

                           

                          Again, folks can do what they want. Table View is still inherently flat file, not relational; it cripples much of your control as a developer; and it leads the client into thinking he's working with a spreadsheet instead of with a database. If the client thinks he's going to save on development costs, he's typically wrong, because the cost associated with cleaning up the mess created by someone who doesn't understand normalization usually exceeds just doing the job right the first time, and because you end up implementing a bunch of Script Triggers to keep him from screwing something up. Personally, I'm loathe to give the general user access to it for these reasons.

                           

                          jmci wants to know people's opinions about why Table View should or shouldn't be used in comparison to List View. Well, that's my opinion. Basically, I would suggest this path:

                           

                          Step 1: Find out why the client wants Table View.

                          Step 2: Assess why you don't want him to have access to Table View.

                          Step 3: Figure out if the client's needs can be met outside of Table View.

                          Step 4: Make a decision.

                           

                          HTH

                           

                          Mike

                          • 10. Re: Advisability of Using Table View Instead of List View
                            Malcolm

                            On 20/02/2012, at 12:28 PM, Beverly Voth:

                             

                                 sortable columns

                             

                                 columns can be re-arraged

                             

                                 columns can be re-sized

                             

                                   

                            I do limit access to tables and I don't like the ability to "create fields" with tables, but I understand this can be a training point as well.

                             

                            All in all, I like table view. It provides all the benefits listed above, which are considerable.

                             

                            The Create Fields option is only available to users with sufficient access privileges.  If a user is allowed to create fields they "own" the application don't they? It gets in my way, as a developer when I'm working in a table view,  but my users never experience the problem because they access the database through a controlled user privilege set.

                             

                            Others have complained that you can't get buttons into rows. It is completely unnecessary to have buttons on a row. You are able to display header and footer parts. These can display buttons and a button is a button is a button. If you are in record 24 and you hit a button in the header/footer, it's primary context is record 24.

                             

                            malcolm

                            • 11. Re: Advisability of Using Table View Instead of List View
                              jbante

                              Just because a button in a header or footer will technically do something with the active record doesn't make it a good idea. I consider it questionable UI design to put records 1-23 between a button in the header and the record it will act on — it can be done, but it's worth avoiding if possible within the other constraints of the problem.

                              • 12. Re: Advisability of Using Table View Instead of List View

                                Malcolm wrote:

                                . If you are in record 24 and you hit a button in the header/footer, it's primary context is record 24.

                                 

                                Ah, but with one striking exception:  If you make a User click onto the record itself (or the button on the row) then you are guaranteed (actually the User is guaranteed) that they are acting on the record they expect.

                                 

                                By clicking up into a header to perform the same action, they would have to (if they even remember), glance down to see if they are still on the correct record in the list.  The click confirms their choice otherwise scroll could have moved them or they might not have noticed that they clicked into a different record.  I always make them point and shoot. 

                                • 13. Re: Advisability of Using Table View Instead of List View
                                  Oliver_Reid

                                  TIME TO END THIS THREAD. WE ARE WALLOWING IN TRIVIA 

                                   

                                  From:  FileMaker Orders <NoReply@filemaker.com>

                                  Reply-To:  <fmi-1030479029-20u-2-1ix0@fmdev.filemaker.com>

                                  Date:  Mon, 20 Feb 2012 16:46:24 -0800

                                  To:  Oliver Reid <oreid@firstgm.com>

                                  Subject:  Re: Advisability of Using Table View Instead of List View

                                  • 14. Re: Advisability of Using Table View Instead of List View

                                    I believe this is very relevant to the spirit of the thread.  And no need to shout, we are right here.

                                    1 2 Previous Next