1 2 Previous Next 18 Replies Latest reply on May 10, 2017 12:10 AM by HammerOz

    dashboard layout


      I want to create a "dashboard" layout which I see as being a layout with several portals on it, displaying data from several lists in different ways.  It would serve as a "starting point" for the user... this is for an automotive service business, so I'd show a list of open repair orders, incomplete repair orders, completed repair orders, customers, estimates, maybe scheduled appointments, etc.  The idea is this is the first place the user would start, and clicking on any item will take you to the details of that item (different layout).


      My question is: what list might I associate with this layout?  How would this typically be done?  Would I create a "dashboard" list that has only one record containing key fields?


      This seems like the most obvious way to go about it, but I'd be curious to know what others have done

        • 1. Re: dashboard layout

          The simplest approach is to use one or more portals to list these different orders. A portal filter can limit the orders listed to a specific type and you can sort the portal to list the newest first if that is useful. A button in the portal row can use Go To Related Records to bring up that record on a different layout.

          • 2. Re: dashboard layout

            Right, that was the plan.  The question is, would you create a list specifically for the dashboard layout or just pick an existing list even though it's records will not be used?

            • 3. Re: dashboard layout

              I imagine a 'join table' would serve best for this type of display (i.e. a new table with foreign keys to to the primary keys of other tables you want to correlate), as it allows the many-to-many relationships you probably need


              FileMaker Join Table - YouTube

              Filemaker Simple Relationships - Join table - YouTube


              you probably want to also look at the selector-connector technique (although that's a bit more mind-bending), as this would allow data from different sources to be shown in the same portal:

              Selector Connector - YouTube


              hope that helps


              • 4. Re: dashboard layout

                I like the 'connector' idea.  Since this layout might display data from anywhere, it might as well be, in the context of a connector table.  It's arbitrary, but neater.  The data will all be in filtered portals. 

                • 5. Re: dashboard layout

                  I see no need for a join table. You should be able to link the table occurrence for your dashboard layout directly to orders. A Cartesian join with portal filter may be used for this.

                  • 6. Re: dashboard layout

                    I would suggest ignoring portals and instead using reports activated by a search script. Reports are thousands of times more powerful than a portal since you can build hierarchies, etc.


                    What often happens is that rather than understand a clients needs, a designer just throws a lot of ideas into menu choices, buttons, etc.


                    Working with mostly the iPhone, I have been forced to abandon all of the layout gimmicks that impressed me and try to make simple list like displays and most of all to begin to understand what the user would want to see.


                    Replaccing dozens of portals, etc that may only confuse the user with a few starting buttons that then move to another layout with a few other options is quick and simple (just don't extend the drill down past three or four layouts as one accountant/developer did in the 80s with a bookkeeping application which after 12 drill throughs still could not change the amount entered for a check).


                    For instance, in a personal shopping cart app for groceries, etc, I first created a complex interface and after much stress finaly limited it an opening screen with a few choices:

                    View all items

                    View all stores

                    View shopping cart

                    and one or two more.


                    Basically I look at the items to see what I need to buy. A button shows me the ones not selected and I can check items to buy. Then I pick the store I am in or going to and all of the items I've checked show up in that stores report. Oh, the items that are available at any store will show up there. Buying one and unchecking it unchecks them for all stores.


                    I can also email a list of items to pick up to anyone who is at a store.


                    Rather than overwhelm myself with 6 portals on one layout, I use a few buttons to run a report that gives me all the info.


                    Of course there are times when many portals and graphs are needed providing real time views of sensors.


                    I would suggest that rather than try to use all of the FMP technology you can, that you ask the users what it is they need and provide that.

                    • 7. Re: dashboard layout

                      I understand what you're saying, but in this case, I'm the client (this is for my own automotive business),  The concept is to re-create something similar to the paper systems typically used which, in part, you'd call a "rack" of repair orders.  The dashboard concept, as I see it, is rather like that of a car where everything you need to do the job is lined up in front of you.  The basic front desk functions are to create estimates, appointments and repair orders from customers on the phone and who walk in, take payments and print invoices and receipts. I want this to be done in the simplest way, with the fewest user inputs possible, in part because the "user" isn't necessarily much of a computer person.  Portals seem to me the best, if not the only way to do this.  I'm just starting to put it together now, so we'll see how it goes...

                      • 8. Re: dashboard layout

                        For something like this you would start from a "session" table and user login record specific. I create a new session record each time a user logs in, they operate from and through that session relationship. This serves two purposes as it records the login attempts as well. You will also need the concept of a "constant" value or unifying field where you keep a single record in every table you wish to display in the display equal to that of the session, in my case I use, 1.


                        Does this make sense? I can go further but this might be enough!


                        Hope it helps!!



                        • 9. Re: dashboard layout

                          Since this is for your own use, you don't need support for multiple sessions. All you need is this relationship:


                          Dashboard::AnyField X RepairOrders::AnyField


                          To list your repair orders orders with a status of "open", use a portal to RepairOrders with this portal filter expression:

                          RepairOrders::Status = "Open"


                          To get a portal listing incomplete repair orders, make a copy of this portal and change the portal filter to filter for incomplete repair orders.


                          Note that hat you will need at least one record in dashboard.

                          1 of 1 people found this helpful
                          • 10. Re: dashboard layout

                            Good idea, but since my company is now two people, and if all goes well, as many as four later this year, it's not really needed yet, but if this works out well (if I finish it!) I'd imagined sending it out as share ware.  This would be a good feature for the "released" version!

                            • 11. Re: dashboard layout

                              Maybe, maybe not.


                              Will each user need anything different from the other?


                              Dashbords are not normally used to edit data but rather to view it--with buttons like you describe to pull up detail views where the actual editing takes place.


                              If that's the case here, then I see no need to complicate your solution with support for different sessions for each user.

                              • 12. Re: dashboard layout

                                Its simple to link to 2 fields rather than just one for an easy filter of a portal.


                                Each record has the created by Account Name field plus the ID field.


                                On the dashboard there are two global fields. One for data entry and the other which is a calc for Account Name. Thus each record is now linked by creator and data entry in the global.


                                So, two layouts one links with creator and one just uses one field for data field.

                                • 13. Re: dashboard layout

                                  I agree and thus no need for managing "sessions". Also, the original description here does not seem to indicate the need for even that as I think that you'd want to see all "open" or "incomplete" work orders in most cases and not just those by the current user.


                                  But I freely admit that I may be making an incorrect assumption as to the scale of this business.

                                  • 14. Re: dashboard layout

                                    There is also the issue of not wanting employees to see some information.


                                    For instance in the construction industry a sucessful contractor has to deal with the problem of employees wanting to become a competing contractor and finding the customer list interesting and the bids. Hey, I can under bid and get the job.

                                    1 2 Previous Next