Fake an Apple Accordian in FM

[Genx]

Solution: Apple Accordion Thingy

Description: A UI element based on calculated repetitions and designed to mimic the behavior of the apple accordion widget seen all over the apple website, particularly here: http://www.apple.com/support/

The sample file and an overview video are available off Harry and I's (indeed with the lack of grammar) new blog: www.filemakerdesign.com/blog/?bid=1

Please let us know what you think (of both the site and the blog posts : )

Working Under:8.5 Advanced

Solution Status: Demo

Author(s): Genx

Date: 08/13/08

Credits: Apple

Disclaimer:

FM Forums does not endorse or warrantee these files are fit for any particular purpose. Do not post or distribute files without written approval from the copyright owner. All files are deemed public domain unless otherwise indictated. Please backup every file that you intend to modify.

[The Gardener]

Hello,

Interesting. Great video, except for the music. Registered, but could not login. What are the login fields requiring, obviously one must be my password. Tried to contact on your Contact page but the 'send form' does not work. Using FireFox.

Disappointed

[Genx]

Okay:

1) Your login is your email address, I think it says that on the login page though I suppose it could be made clearer. [EDIT]Made some changes and it should be more obvious now[/EDIT]

2) The site has been tested on FF 2+ (FF2 was actually the primary browser used during development), IE 6+, Safari 3+, Netscape 9+ and Opera 9+. The forms will not however submit when you hit return etc. You will actually need to press the submit button... If you are still having issues, please send me a private topic, the last thing we want is for accessing the example files to be difficult.

3) As for the music, well I need some sort of reward for spending time on putting these examples together - and remember, you can always turn the volume down or off altogether :(

[Tanner]

I liked the music, maybe that's just me though. I like this idea, good job. I really wish filemaker would allow 2 way communication with the web viewer though (without a plugin), then we could do this just like apple does on their website.

[The Gardener]

Hello,

So, I was pretty cranky yesterday. And, I was hungry - a family trait leading to being cranky. I have been back, signed in, like the music much more. This is a great idea, much impressed and look forward to much more on your website. Apologies.

[Lee Smith]

If you click on the speaker, you can turn it down, or off. :giggle:

[grubber]

Thanks Genx, real nice.

[bruceR]

Here's a simple example using my array technique and a portal and a custom function. Very bare-bones at the moment.

accordion.zip

Edited August 26, 2008 by Guest

[comment]

I promised Genx to publish a simpler method to achieve this. But first I need to make clear what "this" is:

The 'accordion' could be used to show either commands (buttons that trigger actions) or actual data from a table. It seems that both Genx and BruceR have chosen to show commands, so I'll stick to that for the moment.

I see two problems with the proposed methods, the first being the amount of resources required to implement the method:

Genx (not counting the "construction" section)

3 tables

5 TO's

23 fields

1 script

BruceR:

2 tables

2 TO's

8 fields

1 custom function

2 scripts

The second problem is much more serious: in both methods, no matter where in the accordion you click - it MUST trigger the same script. This ONE script must either change the display (if you have clicked a menu header) or perform an action (if you have clicked a menu item). Now, this may be fine for showing "You have selected Broccoli" or for going to a layout. But I want to be able to connect each menu item to a script of its own, so that I can have:

Customers:

• Show All Customers

• Show Active Customers

• New Customer

Invoices:

• Show All Invoices

• Show Due Invoices

• New Invoice

etc.

The only way to achieve this with the shown methods would be to have a giant "router" script along the lines of:

If [ Get (ScriptParameter) = "Show All Customers" ]

Perform Script [ Show All Customers ]

Else If [ Get (ScriptParameter) = "Show Active Customers" ]

Perform Script [ Show Active Customers ]

Else If [ ... ]

etc.

OK, so how can we assign an individual script to each menu item, and keep it simple at the same time? Let's take a look at what this 'accordion' really is. It's a device for showing a lot of buttons in a limited space. It does this by showing only SOME of the buttons at a time. To see another set of buttons, you need to click a menu header. Does this sound familiar? It should, because that's exactly what Filemaker's tab control does.

So all I would need to do is create two blocks of buttons like this:

[color:blue]Customers - Do Nothing

• Show All Customers - Perform Script [show All Customers]

• Show Active Customers - Perform Script [show Active Customers]

• New Customer - Perform Script [New Customer]

[color:gray]Invoices - Go to Object ["invoices" ]

[color:gray]Customers - Go to Object ["customers" ]

[color:blue]Invoices - Do Nothing

• Show All Invoices - Perform Script [show All Invoices]

• Show Due Invoices - Perform Script [show Due Invoices]

• New Invoice - Perform Script [New Invoice]

and place each block into a panel of a tab control object (with named panels). Add more buttons and panels as required. Note that each menu header can have any number of items, so that the 'accordion' can expand and contract.

[bruceR]

I promised Genx to publish a simpler method to achieve this. But first I need to make clear what "this" is:

The 'accordion' could be used to show either commands (buttons that trigger actions) or actual data from a table. It seems that both Genx and BruceR have chosen to show commands, so I'll stick to that for the moment.

I see two problems with the proposed methods, the first being the amount of resources required to implement the method:

Genx (not counting the "construction" section)

3 tables

5 TO's

23 fields

1 script

BruceR:

2 tables

2 TO's

8 fields

1 custom function

2 scripts

The second problem is much more serious: in both methods, no matter where in the accordion you click - it MUST trigger the same script. This ONE script must either change the display (if you have clicked a menu header) or perform an action (if you have clicked a menu item). Now, this may be fine for showing "You have selected Broccoli" or for going to a layout. But I want to be able to connect each menu item to a script of its own, so that I can have:

Customers:

• Show All Customers

• Show Active Customers

• New Customer

Invoices:

• Show All Invoices

• Show Due Invoices

• New Invoice

etc.

The only way to achieve this with the shown methods would be to have a giant "router" script along the lines of:

If [ Get (ScriptParameter) = "Show All Customers" ]

Perform Script [ Show All Customers ]

Else If [ Get (ScriptParameter) = "Show Active Customers" ]

Perform Script [ Show Active Customers ]

Else If [ ... ]

etc.

OK, so how can we assign an individual script to each menu item, and keep it simple at the same time? Let's take a look at what this 'accordion' really is. It's a device for showing a lot of buttons in a limited space. It does this by showing only SOME of the buttons at a time. To see another set of buttons, you need to click a menu header. Does this sound familiar? It should, because that's exactly what Filemaker's tab control does.

So all I would need to do is create two blocks of buttons like this:

[color:blue]Customers - Do Nothing

• Show All Customers - Perform Script [show All Customers]

• Show Active Customers - Perform Script [show Active Customers]

• New Customer - Perform Script [New Customer]

[color:gray]Invoices - Go to Object ["invoices" ]

[color:gray]Customers - Go to Object ["customers" ]

[color:blue]Invoices - Do Nothing

• Show All Invoices - Perform Script [show All Invoices]

• Show Due Invoices - Perform Script [show Due Invoices]

• New Invoice - Perform Script [New Invoice]

and place each block into a panel of a tab control object (with named panels). Add more buttons and panels as required. Note that each menu header can have any number of items, so that the 'accordion' can expand and contract.

So now I have deployed your "simpler" solution on 100 layouts.

Oops; I need to change or add a feature or correct a mistake or correct an item title.

I can modify my table of menu data once. Done.

Or modify my "problem" router script once. Done.

Or do it 100 times your way.

I fail to see the advantage of your proposal, though it would be good to see an example file. It might be useful when deployed across a very limited set of layouts.

[Genx]

Okay, so I'm not going to say it quite as sarcastically.... but I agree with Bruce. This is definitely command oriented and my main issue is: what if i want to add a new command?

I need to go through 10 layouts in a smaller solution and add 10 buttons, exactly placed, with 10 new text labels, exactly placed... Or what if I want to change the script attached to a specific button etc. etc.

It becomes a real pain to have to run through each of these layouts and add an element per command - I'd rather bear the 5 TO's or an Extra script and a CF than go around doing manual labor through my DB trying to find the locations where the object actually exists... I HATE point and click, which incidentally is why I like web development so much over FM development.

With web development, in a properly constructed solution, you should only ever have to change one file to modify an interface element through the system - with FM, you have to point, click, drag and select on how ever many layouts exist to achieve the same thing.

[comment]

Oh for crying out loud: come up with some real ones, won't you?

A tab control is an object - you can copy/paste it with all its enclosed elements included. Make the change ONCE and replicate it to all the other layouts - a monkey could do this in 5 seconds per layout. How often do you plan to make these changes anyway? You'd rather keep 3 tables and 5 TO's PERMANENTLY in the solution to save the time it takes to make this change? Why don't you make calculation fields for ALL the labels in the solution, too - just in case the font needs to be changed?

And it's not like you can make the change in one place in your solution either - you still need to go to your script and point it to the correct REAL script.

I can see no difference between this and a row of buttons placed in the header. It's just a bunch of buttons. There are techniques to store the button labels in a global repeating field and if you like any of them, you can use it just as well here.

[bruceR]

Oh for crying out loud: come up with some real ones, won't you?

A tab control is an object - you can copy/paste it with all its enclosed elements included. Make the change ONCE and replicate it to all the other layouts - a monkey could do this in 5 seconds per layout. How often do you plan to make these changes anyway? You'd rather keep 3 tables and 5 TO's PERMANENTLY in the solution to save the time it takes to make this change? Why don't you make calculation fields for ALL the labels in the solution, too - just in case the font needs to be changed?

And it's not like you can make the change in one place in your solution either - you still need to go to your script and point it to the correct REAL script.

I can see no difference between this and a row of buttons placed in the header. It's just a bunch of buttons. There are techniques to store the button labels in a global repeating field and if you like any of them, you can use it just as well here.

You have a vision of an entirely static solution. Which has its place, but is still hard to maintain.

It is a relatively common practice, ever since the advent of script parameters, to have fewer scripts and more conditional routing within a script. So I don't see that argument as having much merit. You could of course have each button in your repeat scheme pass its rep number to a routing script, and I have built systems that do exactly that.

The advantage of a portal is that it can use the actual data in the portal row.

It is possible with the portal technique to have very dynamic menus.

However, if find mode appearance is an issue, the global rep approach does work better there as the data is retained and visible in Find mode.

Perhaps the disappearance of the portal menu items in find mode might even be viewed as an advantage, you may not want the user to be navigating while initiating a find operation and you might add some kind of mode indicator.

[comment]

I don't intend turning this into a discussion about the general philosophy of solutions. As I said, it's just a bunch of buttons. Whether buttons should be dynamic or static is an entirely different question - one that has very little to do with the 'accordion' technique, which I believe is about placing many buttons in a small area.

I have seen many methods for dynamic buttons, and so far I didn't like any of them - for much the same reasons I have stated above. But again, this is irrelevant.

It's not like the 'accordion' UI element is suitable to be placed on every layout anyway. And you can't have it on list/table views at all. I believe it's best used by placing it on the solution's "main page", and perhaps on a few selected layouts as well. If your solution has well-defined modules, you could have such element on each module's "main page". Of course, by using a tab control you could very easily have a DIFFERENT 'accordion' for each module.

BTW, I mentioned the need for a central "routing" script only as an illustration to point out what I saw as a weak point of the concept. I didn't think anyone would actually consider implementing this.

[bruceR]

BTW, I mentioned the need for a central "routing" script only as an illustration to point out what I saw as a weak point of the concept. I didn't think anyone would actually consider implementing this.

It is quite unclear what your point is here. Certainly, as I mentioned, parameter driven routing scripts are an common general practice now.

[comment]

I don't know of a general practice of the kind that would be required here. It's one thing to have a "New Record" script, and have it branch according to the script parameter which would tell it in which context. It's something else altogether when the script parameter must be used to tell a generic script which script needs to be actually run. OK, so it's "New Record", but with what parameter?

Suppose there's one script that takes the layout name as the parameter, and another that needs data from a global field. If these two must be triggered by a common script, then the common script must load both the layout name AND the global data into its parameter (or into variables) so that it can pass one of them to the actual script. Multiply that by the amount of scripts that you plan to cram into the accordion (after all, that's what it's for). So now you need to manage not only a script router but also a parameter 'stock exchange' (or perhaps attach a formula to each script in the accordion table, which the script parameter will then evaluate).

I'm not saying it couldn't be done - but who would want to? And for what? Sure, the 'accordion' is a nice layout element, an eye candy, and I am going to use it. But not at the price you or Genx would have me pay.

[bruceR]

Still don't get your point. There is (quite conceivably) ONE script. With an if else-if sequence. That all the routing I meant. Though if your vision is to complicate things, go right ahead.

If you're going to use an accordion, then you START with a hierarchy, that's what it's about. So maybe you have 4 high level choices and some subtopic parameter that you pass to the four options. Can't see the difficulty there.

[comment]

Still don't get your point.

Perhaps you should read it again, particularly this part:

the script parameter must be used to tell a generic script which script needs to be actually run. OK, so it's "New Record", but with what parameter?

I'm afraid I don't know how to make it any clearer.

if your vision is to complicate things

Hm, is that what it looks like? In any case, I'd prefer you leave me and my vision out of this discussion and restrict your remarks to the topic.

[Genx]

Guys,

Each to their own, these are two very different methods with two entirely separate uses.

Lets just leave it at they both have benefits and issues.

Cheers.

[bruceR]

Perhaps you should read it again, particularly this part:

I'm afraid I don't know how to make it any clearer.

Well, that could be done with an example file. Examples have been created and posted for the other techniques. Could you post one please? Attached is a modified version of my example with a new tab "Tab Method" plus some buttons and scripts. You could modify this to help illustrate your technique, or perhaps you'll find it easier to start with your own.

accordion.zip

Edited September 1, 2008 by Guest

[bruceR]

Add some script options to make this a slightly more realistic example.

accordion.zip

Edited September 1, 2008 by Guest

[comment]

Sorry, but I don't think this is necessary. The point is rather minor compared to the rest, and I think the pros and cons of each method have been made sufficiently clear by now. I only came to this thread because I promised Genx to post a simpler method. I believe I have done that, and I don't see why I should be punished for it.

[bruceR]

Sorry, but I don't think this is necessary. The point is rather minor compared to the rest, and I think the pros and cons of each method have been made sufficiently clear by now. I only came to this thread because I promised Genx to post a simpler method. I believe I have done that, and I don't see why I should be punished for it.

Stunning. If it was simpler, it would take you two minutes to build an example. Providing a clear example so others can understand and evaluate a technique is punishment?

[comment]

Understand and evaluate, yes. Ridicule and condescend, no. I think I have explained my method well enough, and the only reason I haven't posted a demo is the way you reacted to it.

[bruceR]

Understand and evaluate, yes. Ridicule and condescend, no. I think I have explained my method well enough, and the only reason I haven't posted a demo is the way you reacted to it.

Well, I'm sorry you feel that way; but I have absolutely no idea what that's all about.

I can't really control or predict your emotions or interpretation; they are your responsibility. Unfortunately this is a general problem area with electronic communications.

Here was my request, which doesn't really seem out of order to me. Please; perhaps; initiative taken to offer you a starting point but recognition that you may wish to roll your own.

Well, that could be done with an example file. Examples have been created and posted for the other techniques. Could you post one please? Attached is a modified version of my example with a new tab "Tab Method" plus some buttons and scripts. You could modify this to help illustrate your technique, or perhaps you'll find it easier to start with your own.

Asking for an example is a problem? Why?

Edited September 1, 2008 by Guest

[Lee Smith]

Add some script options to make this a slightly more realistic example.

Nice Job Bruce,

[comment]

I am sorry, it was my mistake: I should never have let things continue this far. I don't even know what it's about anymore and - in case you haven't noticed - I've been trying to end this as quietly and politely as I can. If you don't understand why, that's too bad but I won't be going into that either. It seems all I have done in this thread is explain, clarify and justify myself. I've had enough.

[grubber]

Whilst this thread wasn't much of a love-in it introduced me to some excellent techniques.

Thanks all.

Olly

ps. Bruce: Extra thanks for your recent demo files/CF's they are freakin awesome.

[Agnès]

Hello,

and Thanks for your files.

my English is not good enough for any understanding on this topic.

but, thank you, 2 files are really nice, but I do not understand why their construction is so complex.

Here is an example of construction that I used for my menus, I have a script single dispatch using DoScript, also with external parameters.

it's simple it seems to me, I had used the idea of a "Hierarchy" that I found here one moment ago.

There are certainly subtleties who I do not understand, thank you for explain to me.

Agnès

Edit : oh... ok, I think I just understand one of subtleties of Genx file's : the number of lines displayed is always the same, display does not jump, and the main lines go down. Very sorry, I did not understand, I'm out ! but thanks a lot, it interests me very much.

TiteFleche_Hierarchie.fp7.zip

Edited September 3, 2008 by Guest

[Lee Smith]

Hi Agnès,

I'll guarantee you that your English is a lot better than my French.

Thanks for sharing the file.

Lee

[Genx]

This has turned into quite a handy topic :

[Agnès]

Hello,

Thanks for sharing the file

then, I share my new revised and corrected version

I do not really know if it's usable, but it's the air to operate

thanks you

Agnès

TiteFleche_Hierarchie_V2.fp7.zip

[Agnès]

Hello,

Sorry me again ! I come back !

I tested the accordion with differente views....

I made use of a tab panel, it surely needs accurate interface adjustements, but the result can be

I let you click anywhere

thank M'sieur Alex !

Agnès

MenuAccordeon.fp7.zip

[fabriceN]

Thanks, my glossy MacBook screen is now full of finger prints. :

Thank you for sharing ! Really nice.

[Genx]

Agnès, awesome work. You've really taken this concept far beyond what I had originally envisaged... I love community :