1 2 Previous Next 16 Replies Latest reply on Mar 19, 2012 9:47 AM by Stephen Huston

    Expanding Lists design method

    MicheleOlson

      I am looking for a design method I have seen several times, but I don't know what it is called, so I can't locate it.

       

      It is a list view ... not a portal ... with arrows/triangles to indicate there are sub records. When the arrow is clicked additional sub records show for the selected record. I am likely not explaining this well, but I know what I want to see visually and think this method will do the trick. Here is a pseudo sample to help.

       

      > Cats

      > Dogs

      > Fish

      > Birds

       

      When the arrow beside Cats is clicked, something like this would display [still in the list view].

       

      > Cats

      > Gray

      > Tabby

      > Calico

      > Dogs

      > Fish

      > Birds

       

      When the arrow beside Calico is clicked, something like this might display [still in list view].

      > Cats

      > Gray

      > Tabby

      > Calico

      > Kitty

      > Bessie

      > Lilly

      > Dogs

      > Fish

      > Birds

       

       

      Thanks.

        • 1. Re: Expanding Lists design method
          MicheleOlson

          Ok. I have *dug more deeply* in my pile of examples and find three nice ones that are what I am remembering.

           

          The techinique is a hierarchy and my examples are all using portals.

           

          The three examples are from Excelysis [Andrew Persons], Seed Code [CCHierarchy PortalTree], and Mikael Edoshin.

           

          This is definitely what I am remembering, but... if you know these techniques, do you remember seeing something similar using a list view and perhaps subsummary parts?

           

          Thanks.

           

          Michele

          • 2. Re: Expanding Lists design method
            Malcolm

            There is another one based on Bruce Robertson's virtual lists.

             

            Malcolm

            1 of 1 people found this helpful
            • 3. Re: Expanding Lists design method
              beverly

              http://honza.24usoftware.com/infinite-hierarchy

              (based on Matt Petrowsky's example, IIRC)

               

              -- sent from my iPhone4 --

              Beverly Voth

              --

              1 of 1 people found this helpful
              • 4. Re: Expanding Lists design method
                MicheleOlson

                Thank you Malcoln and Bev. I will look in my archives.

                • 5. Re: Expanding Lists design method
                  MicheleOlson

                  Adding to my previous post, here is what is in place:

                   

                  3 tables: suppliers     products     locations

                  products: contains all the products a company has manufacturered outside the US

                  suppliers: the outside sources that manufacture/supply products

                  locations: the places to which the manufactured products are shipped

                   

                  there are 2 join tables: productCost and locationBuyList

                   

                  this is because:

                        each supplier can produce many products [ but not all], each at their price [cost to purchasing company]

                       each location can receive many products [but not all], which can originate from any of the suppliers

                  so there are many to many relationships between suppliers and products & between products and locations

                   

                  thus the join tables

                   

                  What I want to change is the point of view for the entry person; it is too complicated

                   

                  products lists ALL the products the co. has manufactured

                  but a supplier only supplies some of the products

                  so the user currently must go to the supplier page to edit/enter pricing changes for the product for the supplier

                  and go to the location page to add/remove products from various suppliers that can be shipped to the location

                   

                  again, products list ALL the products the co. has manufactured

                  but each location only receives some of the products from some of the suppliers

                  and each supplier only supplies some of the products

                   

                  as a po is generated the supplier is selected, then the shipping location

                  this narrows the list of available products [only the products from the supplier to the location are listed]

                   

                  po's are easy to generate and work nicely for the user, what doesn't work nicely is updating pricing and location

                   

                  so....

                   

                  my vision is to view this from the point of the product, which is where the user would think to go

                   

                  he needs to see the list of products, click one and see the sublist of suppliers and sublist of locations

                   

                  if pricing needs updating, he can change it there

                  if the product needs to be removed from or added to a location he can change it there

                   

                  one place, the product list, where he naturally tends to go

                   

                  i've also looked at ray cologon's dynamic summary example [in the 8 for 8 group] which has some potential

                   

                  but what i see in my mind is an arrow on either side of the product which when clicked on the supplier side will display the suppliers suppling the product with editing for pricing and when clicked on the location side will show the locations that can receive the product with ability to add or remove them

                   

                  perhaps portals are what i am needing but i still think i have seen something like this in a list view

                   

                  ;-)

                  • 6. Re: Expanding Lists design method
                    Oliver_Reid

                    Michelle:

                     

                    Set up an outer join from Products to Products

                     

                    In Product layout show three portals

                     

                    Outer Join to Self

                     

                    related productCost records - with editable fields

                     

                    related locationBuyList records - with editable fields

                     

                    The rows in the first portal show all the products with a GTRR using the self same layout to show the target record

                     

                     

                    You can slick this up by typeahead filter the first portal by product name, or maybe putting each of the other  portals in a tab so as to unclutter the view.

                     

                    With view more TO’s you could also limit the first portal to products produce by a particular supplier, or received by a particular location. Feel free to send me some sample tables and I’ll mock it up: I love this stuff!

                     

                    I think the design method you are thinking of is an “exploding parts list” that uses a “linked list” to cost out product component costs recursively.

                     

                    But I don’t think you need that here unless Location A is supplying products for Location  B to assemble to another product that is supply to Location C at price that is calculated out from A’s original prices to B. Then maybe A buys C’s product which contains part originally made by A, and supplies to Location D etc...

                    • 7. Re: Expanding Lists design method
                      MicheleOlson

                      Olliver,

                       

                      Thanks much for the reply and the ideas. I will work on them and send you a sample for your input.

                       

                      Regards,

                       

                      Michele

                      • 8. Re: Expanding Lists design method
                        comment

                        MicheleOlson wrote:

                         

                        he needs to see the list of products, click one and see the sublist of suppliers and sublist of locations

                         

                        If I follow your description correctly, this cannot happen purely in a list view because no single table has all the data required for such display. Why don't you show the selected product in form view (perhaps in a new window), with the associated portals?

                         

                        Alternatively, you could (I think) show the portals in a sub-summary part that would be showing only for the selected product.

                        On second thought, that would only work in Print/Preview.

                         

                        Message was edited by: Michael Horak

                        • 9. Re: Expanding Lists design method
                          Stephen Huston

                          Actually, sorted Sub-summary parts work fine in browse mode in current FM versions -- doesn't require print/preview to show sub-sum items.

                           

                          I have implemented multiple  sub-sum parts with options from buttons on the various parts to trigger different sorting to accomplish  what Michele is describing. The only issue is that one must build the layout based on the TO representing the finest level of record detail that will be included, and then create sub-sum parts for all levels of sorting, including the record level that would normally be the body of the layout. Such layouts should have NO body part at all, just sub-sum parts which appear or disappear based on the sorts triggered.

                           

                          And, of course, one cannot control the detail level on inidividual records in the list. The same level of detail will appear for all of the found set based on the sorting level. The portal method described earlier may allow drilling down on individual records rather than the entire found set.

                          • 10. Re: Expanding Lists design method
                            comment

                            Stephen Huston wrote:

                             

                            Actually, sorted Sub-summary parts work fine in browse mode

                             

                            I am well aware of that. However, sliding does not.

                             

                             

                            Stephen Huston wrote:

                             

                            The same level of detail will appear for all of the found set based on the sorting level.

                             

                            Then what's the point?

                            • 12. Re: Expanding Lists design method
                              MicheleOlson

                              Stephen,

                               

                              I think your description is what I recall seeing ... and it was not too long ago. Did you post an example file for this somewhere?

                               

                              Michele

                              • 13. Re: Expanding Lists design method
                                BeatriceBeaubien

                                Hi Michele,

                                 

                                Ernest Koe presented the accordion list at last year's DevCon as a fundamental design pattern, implementable in FMP. His description is here:

                                <http://fmpatterns.com/pattern/accordion-menu>

                                 

                                I have an example file he produced. Would this be what you were after? Just let me know.

                                 

                                All the best,

                                 

                                Beatrice Beaubien, PhD

                                i2eye, Toronto, Canada

                                 

                                FileMaker Business Alliance

                                FileMaker 11 Certified Developer

                                • 14. Re: Expanding Lists design method
                                  MicheleOlson

                                  Hi Beatrice,

                                   

                                  This does look similar to what I have in mind. An example file would be great. Thanks.

                                   

                                  Michele

                                  1 2 Previous Next