Huge Check Box Listing? What are my Alternatives?

[Mark L]

I have a medical application that I am developing. To simplify things

[MoonShadow]

I suggest you consider a filtered portal for User selection. You can search here or I'd be happy to provide sample (or others can) of the technique.

User can click buttons A - Z (or any combination you wish) and, based upon script parameter, display the filtered compounds for selection. Determine what a User might wish/need to select to provide a proper filter. I still wouldn't have over 50 items in a portal. It's easier for Users if the portal is easily readable without scrolling (too much).

You can also turn your button selections for conditional display - or use two sets of criteria buttons (which exist in portals) so only the appropriate second set of buttons shows when the first filter is selected. Options are endless. The reason this is nice is that the business can type what the button labels should say and even determine the filter criteria itself. This will allow expansion and change over time without need of going into design again. And you will never outgrow, outchange such a system.

[Mark L]

MoonShadow-

Thanks for the quick response.

If I understand you correctly

[comment]

This sounds familiar... somethings with vitamins, right?

I agree with MoonShadow - 325 items is an awful lot to choose from. Let me suggest you put all you know about Filemaker aside and ask yourself (or the user) this:

What should this look like, ideally? Can you think of some other application whose user interface could serve as a model for this?

Once you have a picture of the ideal interface, you can start considering how to implement it in Filemaker.

[Mark L]

comment-

In pure theory you are 110% correct!

Unfortunately a deadline looms nearby on the horizon - and this is one of a relatively small number of items that stand in the way. As it is, this Compound selection process should be used very, very rarely in the application - but this is how it was mocked up and they liked it that way. Usually I'm very user interface oriented - at this point, if the customer can accept it for Version 1 and it will be rarely used, I'm willing to go with it.

Put in a more metaphysical way:

In theory, theory and reality are the same. In reality, theory and reality are not the same.

(I

[MoonShadow]

Since this is little used and you are on a deadline, you might try this quick test (you can always enhance it later very easily). Just add global text in Main (gFilter). In your Compound file, create a calculation (text) which can be indexed. It could be something like:

Left(CompoundName; 1)

Join gFilter in Main to this calculation in Compounds on =. This should reduce the load on your portal to 20-30 entries max (depending upon their starting letters).

Create a value list of this calculation based upon records from Compounds, all values. Attach this VL to the global. Users select a starting letter and associated compounds are listed. You might only use a Compound Type field and join on that to keep your global popup small but then your list will be longer - it's a balance. See where we're going?

If your portal is still too long or you wish to exhance it further, Michael (Comment) has recently presented a sweet demo called Enhanced VL. I don't have time to search for it here on Forums but I have a copy of it. Maybe he or I can attach it for you. It allows one to include several VL criteria to produce your portal results (based upon multiiple data from your related file).

Theory and reality may never be exactly the same but we should strive to hit theory whenever possible. How far you decide to take this (depending upon time, etc.) will be, as Michael suggests, only your decision. I (unfortunately) sometimes settle on less-than-perfect design solutions just to get a job finished in a pinch. Luckily with FM, flexibility and change allow enhancements to be added later.

[comment]

I absolutely, categorically, unequivocally (add more synonyms here) disagree. If theory and reality are not the same, it only means your theory is not a very good one.

Mostly (not you, of course) when people say things like "Oh, we don't have the time to theorize about this, we need to act now!" they mean "Let's act without thinking." The resulting action usually resembles the running around of a headless chicken.

If time is short, it only means you gotta think fast.

Now, the question is: is it acceptable to somehow group the items for selection or not? That is, can the user select from Group A first, then from Group B, etc., when he/she can only see items from the current group?

[Mark L]

comment-

I'm trying to think as fast as I can (with your help.)

In answer to your question - the client showed me a printed page with a list of Compounds and check boxes next to them - kind of similar to what you get from the doctor or dentist after a visit for insurance. Tiny print with lots of stuff listed with tiny check boxes next to it.

In this case it's not insurance related

[Kristin Green]

I would also do the portal thing but I would make it so that a list of compounds on one side allowed you to select what compounds were added to the list on the other side. Think of the SORT dialog box in FMP. On the left you have a list of all the fields by which you could sort. On the right, your sort criteria. Clicking on items on the left adds them to the right.

I would make sure that the compounds and tests have a unique id (serial number) and use that as your link if you haven't already.

I like the idea above where you break the list down by some kind of filter. I might be inclined to use a category. I'm sure these compounds can be categorized in some way, right? I would make a table for the category names and link it. This allows you to display a list of categories. Again use an id in case someone corrects a spelling mistake in the name - you don't want the link to break.

Think of it in three columns. The first column is categories. The second is compounds. The third is the list of compunds for this test. Click on a category and the second column updates to show the compounds for that category. Click on a compound and it is added to the third column.

That's the concept I would use. Let me know if you need help implementing it.

Cheers,

[comment]

Well, I guess that means no. So the question is how to present 325 items for selection.

Three options come to mind:

1. Checkboxes - 325 items is actually doable. The field needs to be as wide as the screen allows, and as tall as to fit all items. Some vertical scrolling may be required, but that seems acceptable to me.

2. List view of the compounds, with indication what is selected (actually a toggle thing, like a checkbox). Vertical scrolling definitely required.

3. A simulation of checkbox field with a split portal (multiple instances of the same portal, each instance starting with the following row). Depending on the width needed, you can fit this in a grid of 3x109 or 4x82 or 5x65, etc.

BTW, I am speaking of on-screen selection only. Printing should be done from a list layout (possibly in columns) of the Compounds table.

[Mark L]

Kristin-

Thanks so much for your reply.

My big thing is that I really feel that I can't categorize, that the users need to see the whole (*******) list. But your idea of a three field portal is definately an idea I will keep in mind for other aspects of the application.

As you will see in my reply that I'm about to post to the response below yours - I think I figured out the whole issue - basically were I started.

A special thanks for not only offering your posting, but also any help implementing the idea.

Sincerely,

Mark

[Mark L]

comment-

Thanks to your help in exploring all the options here - I think I've come 360 degrees on this one.

Like you suggest, I can do just a really, really big checkbox - and my tests in the past few minutes finds that this works far better than I thought. In creating a new window for use with this box, I forgot, that the window itself has a scroll bar - and this seems to function pretty well.

Only sticking point now is when I hide the Status Bar, I loose the default

[comment]

A button defined to 'Resume Script' is the same as 'Continue'. Pressing the Enter key does it too, BTW. 'Halt Script' or 'Exit script' would be equivalent to 'Cancel'.

I lost you on the second question.

[Mark L]

Thanks to you comment, my new "Resume Script" button, labeled "Continue", works a simple, yet important wonder!

Scrap the second question - in my exhaustion, I think I'm making stupid mistakes - like having a script run amok accidently closing my database.

With Gratitude,

Mark

[Søren Dyhr]

When I saw the question, did I think - yet another 1NF violator ...if he ever should think of making any sort of statistics on the entries, he's getting punished accodingly. Then I desided to make a template taking care of that particular issue... and you'll notice it's the shortes valuelist you could imagine!!!

--sd

hugenumber.zip

[comment]

This is a many-to-many, so you are violating normalization rules as well.

As for getting a count of selected items - a calc of ValueCount(Checkboxes) can provide this. Similarly, a count of related parents can provide the number of times an item has been selected. All this without a script.

[Søren Dyhr]

This is a many-to-many, so you are violating normalization rules as well.

I'm not relating anything from the repeater ...explain yourself!!!

--sd

[comment]

In the table which you call "ThePortal" (meaningful names?!), you create n records for every parent record (n would be 325 in the current example). If there were 100 parent records, there would be 32,500 records in the child table. Only a portion of these records is checked. The unchecked records do not carry any information, therefore are redundant.

[Søren Dyhr]

The unchecked records do not carry any information, therefore are redundant.

Good point indeed - so does records with only unchecked boxes, but demising it with "labelling" as many2many isn't correct is it??

"ThePortal" (meaningful names?!)

I think the distinction goes - with firing blank verses with algebraic substitutions scattered or sprinkled all over the place in questions trying to get closer to the core vs. exemplification where the naming actually tells the purpose ...but not what the purpose is in a broader sence - dare I say an abstracttion???

--sd

[comment]

I prefer 'Parent' and 'Child' as an abstraction. This is not always appropriate, but in any case I do not like 'Portal' as an abstraction for a related TO. A portal is NOT the related TO nor is it the relationship (and many threads here prove how easy it is to confuse between these). 'Items' would also be a good choice, IMHO, as would be 'Groups' and 'Members'.

but demising it with "labelling" as many2many isn't correct is it??

I am not sure what you're saying here. This is "a classic many-to-many sans join table", to quote you from another thread. A Test can have several Compounds, and a Compound can be selected in more than one Test.

[Søren Dyhr]

A Test can have several Compounds, and a Compound can be selected in more than one Test.

But there is no link from compounds to a set of tests, where what I consider "classic" is bidirectional in which GTRR (Go TO Related Record) can be utilized ...the tough question to ask here in which of the tests are this particular compound chosen as well and another compound chosen??

Jon Rosens ANDFIND comes in handy here though...

--sd

[comment]

there is no link from compounds to a set of tests

Well, we can't be sure of that (it might be a future requirement), but suppose it's true. So the Compound table is just an editable value list. Still, there's no reason to duplicate the list for each Test record, is there? So it seems to me best to treat it just like a many-to-many.

[Søren Dyhr]

Meanwhile have I realized what you said ...admitted I didn't pull the entire work thru all normalforms to land on safe ground, because I via expirience know that Many2many sans the join are buggars to make any statistics on, the same could be said about a pilcrowdelimited dataset. Indstead did I seek to make the checking of boxes posible in smaller portions via a scrollbar.

--sd