Hiding "Ghost" Radio Buttons in IWP

[David Mars]

Hiding Ghost Radio Buttons in IWP

I am doing an image database for a client who will be hosting it for his customers using IWP. The images are for film locations, and as there is no convention for naming location ‘keywords’, my client wants to display all of the keywords together using radio buttons. There are 100 keywords. He needs the customers to be able to look at different groupings of keywords. A hierarchical menu doesn’t do the job as there is no clean way to organize the info. It is not as if we had a list of cities, each of which uniquely belonged to one state.

Here’s a subset of the list, to give an idea of the (hopefully) logical grouping structure:

Animal Farms

Padi Fields

Plantations

Barren Land

Hills

Open Fields

Highways

Trunk Roads

Lanes

Paths

Tunnels

Beaches

Coral Reefs

Lakes

Waterfalls

My question is whether there is a way to get rid of the ‘ghost’ radio buttons that appear when these radio buttons are displayed in IWP, as per the attached JPG of a subset of my IWP display. The spaces between the radio button groups are essential to make the groups distinct. However, it looks amateurish to have the spaces shown as blank radio buttons.

I do have a work around that looks great, but it is massively labour intensive and I’ll have to redo it all if my client changes a single word. I’ve prototyped taking the native FMP screen showing the radio buttons, and taking a screen shot. I then used that as an image map and put 100 invisible buttons over the radio buttons (3 in my prototype). Customers could then see the image map in IWP and click on a button. That would then take them to another image with the ‘highlighted’ word shown in color to give visual feedback on the clicking. But this means 100 different layouts and 100 scripts for the buttons, and changing them all if the client changes, e.g. “Waterfalls” to “Falling Water”.

Thanks.

[Genx]

It is not as if we had a list of cities, each of which uniquely belonged to one state.

Please expand on that statement -- they're grouped but surely 3 or four key words could be used here to describe each group. There are various ways you could achieve this with heirarchical menu's, join-tables and / or possibly a multi-key but you're going to have to go into a bit more detail.

[David Mars]

What I meant when I said the list of 100 Locations was not like a list of States and subordinate cities is that anyone looking for Chicago would know (if they are American) to look in the State of Illinois, so a hierearchical menu would be useful.

In our case, people will be looking for something 'wild', for example, but they don't know whether to look for 'jungle' or 'plantation', and unless they can visually scan the entire set of groupings and options all at one time, they won't have a sense of the diversity and structure of the options. Certainly we could coerce this into a hierarchical structure, but from the point of view of making the information useful to the novice customer, we feel the display of all keywords in clusters is most efficient.

Cheers,

David

[Genx]

Yes but still, couldn't you group them under multiple categories so to speak...

e.g. (note the groups are just examples)

Animal Farms - Land Scapes, Animals

Padi Fields - Vegitation, Land Scapes

Plantations - Vegitation, Land Scapes

Barren Land - Nature, Land Scapes

Hills - Nature, Land Scape

Open Fields - Nature, Land Scapes

Then... selecting Vegitation froma menu would bring up Padi fields and plantations, where as selecting land scapes would bring up all of them.

[Søren Dyhr]

Radio button under IWP needs special threatment to avoid looking like a dogs breakfast:

http://network.datatude.net/viewtopic.php?t=125

In short cut up in single item "lists"...

--sd

[David Mars]

Søren;

Brilliant! Perfect! Thanks very much.

David

[Genx]

Søren - out of curiousity, how is your name pronounced anyway?

[David Mars]

I have this working perfectly in FMP, but it crashes in IWP. The IWP implementation gives me two buttons per field, instead of 1, and I cannot perform a selection. I have a screenshot of the FMP working smoothly, and the IWP looking pretty sad. In the Value Lists, I have a carriage return after each of the first three values, and no carriage return after each of the next 3 values. It does not appear to affect the display.

Any thoughts? Thanks, David

Radio button under IWP needs special threatment to avoid looking like a dogs breakfast:

http://network.datatude.net/viewtopic.php?t=125

In short cut up in single item "lists"...

--sd

[Søren Dyhr]

Søren - out of curiousity, how is your name pronounced anyway?

Firstname - Only the first vowel is pronounced, and goes like the u-sound in "burden"... but then is the "r" pronounced without the roling sound - by and large not far from the irish Sean, but without the j'ish sound.

Lastname - somewhere in between Deer and Dewar. The problem with the sound of the german ü is that i usually are followed by a rolling r - which is isn't!

--sd

[Søren Dyhr]

In the Value Lists, I have a carriage return after each of the first three values, and no carriage return after each of the next 3 values

It's the wrong interpretation of Ilyse's words - Each list is boiled down to one word sans any returns what so ever, any groupings are done by hand alignment. Ditch the returns - one list with a radio-button turns off similar when selected.

--sd

[David Mars]

Søren;

I'm sorry to be a bit slow here, I'm still not getting this to work. I set up the first three Value Lists with carriage returns as a test, the second three Value Lists without carriage returns. Both display the same way (incorrectly) in IWP. I have now changed all of the Value Lists to show a single value, without carriage returns. And I still get the same look as the screen shots above, and I cannot change the value by clicking on the buttons in IWP, only in FMP.

I've got the hand alignment of the groupings and the group headers working fine.

Thanks, David

It's the wrong interpretation of Ilyse's words - Each list is boiled down to one word sans any returns what so ever, any groupings are done by hand alignment. Ditch the returns - one list with a radio-button turns off similar when selected.

--sd

[Søren Dyhr]

Sorry David, we do hardly ever use radiobuttons - we tend to use two portal with buttons in each and when one is selected is it strained from the other portal.

But I would gladly admit that radiobuttons as such require quite a "treat" in the layout dept to behave under IWP. First off weren't we promised particular reliable rendering in IWP at all. Secondly is the commiting of a choise nessersary, so eventhough we split the list up, do we have to put a scripts execution ontop of the ordinary radiobutton behaviour, since the setting and the commitstep can't be done in less than 2 steps, fortunately comes scriptparamters here handy.

I toyed a little to see what I could come up with, and I managed to get a pretty decent behaviour in both Safari and Firefox... check with other browsers and operatingsystems before deploying it in a solution!!

Tear my solution appart and learn by replicating it, because there are a few not so obvious gotchas hidden in it.

--sd

radioGaga.zip

[David Mars]

Søren;

Thanks very much for the example. As you say, it seems simple but there is a fair bit of complexity there, at my level. I'll study it carefully.

An alternate solution I am thinking of is putting my script buttons on top of an image map of the keywords. That way, the relationship between the script buttons and the image remains fixed as the user cannot distort the spatial relationships via changing the font size. I think my script can do the job with:

Set Field [ Locations::Keywords; "Animal Farms" ]

Commit Records/Requests

[ No dialog ]

Cheers, David