NTWS UpdateForm with many potential selections

[Johan van Zyl]

NTWS 10.33 Clarion 10

I need help with my Locum app/db. medxinfo.co.za
When a locum is registered they fill in the normal stuff like name, cellno, email address etc.
Then I will require PreferredAreas, RegisteredWithPharmacyGroups and DispensingApplications, etc. With each there could be one or many selected.
What will be best way to achieve this in WebUpdateForm?  Because each of those could have multiple choices that could result in a very long UpdateForm.
I would think that each choice would a Boolean checkbox?

[bshields]

Hi Johan,

Not knowing anything about your application, i'm really just guessing, but i'll have a go.

If each of the PreferredAreas, RegisteresWithPhamacyGroups and DispensingApplications are all known (ie, they can choose one or mnay options from an existing list - even its its a very long list). You could hide/show a Browse that acts as a multi select screen.

Maybe you can give some feedback and we could go from there.

Regards
Bill

[Johan van Zyl]

Thx!
The Form can be sen here.
medxinfo.co.za|My Profile|Create My Own Profile

[bshields]

Hi Johan,

What do the "Preferred Areas" look like: is it a list of suburbs or postal codes, or some other geographic construct like states or localities?

Is there 5 of them or 500 or 5000?

Is a Locum, likely to select 1 or 2 or 10 of these?

All these aspects matter when considering the UX.

Regards
Bill

[Bruce]

>> Then I will require PreferredAreas, RegisteredWithPharmacyGroups and DispensingApplications, etc. With each there could be one or many selected.

Sounds like these are child browses of the parent form?

cheers
Bruce

[Johan van Zyl]

Preferred Areas can be Cities/Towns , smaller towns grouped together like Somerset West/Stellenbosch/Paarl, East Rand, West Rand  and/or Provinces specially the smaller and/or sparsely populated ones.
Areas should not be more than a few dozen.

Example:
Johannesburg, Pretoria, Cape Town, Durban, Somerset West/Stellenbosch/Paarl, East Rand, West Rand, Northern Cape, Limpopo.
A locum may choose one or more "areas". Looks like must be via a Browse, by clicking on one or more, the choices will then be written to a text field on form, maybe sorted alphabetically inside this text field.

Hi Johan,

What do the "Preferred Areas" look like: is it a list of suburbs or postal codes, or some other geographic construct like states or localities?

Is there 5 of them or 500 or 5000?

Is a Locum, likely to select 1 or 2 or 10 of these?

All these aspects matter when considering the UX.

Regards
Bill

[bshields]

Hi Johan,

When I have a smaller list of options where they can select more than one, I use a browse of all possible choices and let the user tick the options that apply.

I've added a screen shot (this example is outside of a form, but also works inside a form).

You could also use a multi-select list box, but I find them less flexible in case there are too many entries.

Regards
Bill

[Johan van Zyl]

Thx!
Which theme are you using there?

Hi Johan,

When I have a smaller list of options where they can select more than one, I use a browse of all possible choices and let the user tick the options that apply.

I've added a screen shot (this example is outside of a form, but also works inside a form).

You could also use a multi-select list box, but I find them less flexible in case there are too many entries.

Regards
Bill

[Bruce]

Hi Johan,

>> the choices will then be written to a text field on form, maybe sorted alphabetically inside this text field.

why a text field? That sounds like a really bad way to store it.
It sounds to me like you have a Locum table, an area table, (and a multi-to-multi relationship between the two).

M-2-M means you should have a LocumArea table which links a locum to an area.That way you can easily list all locums for one area, or show what areas a locum belongs to.

Basically I think you are struggling because you have not designed your database correctly yet.

Cheers
Bruce

[Johan van Zyl]

when you browse the locum table (and column search) you can see everything at a glance. Without having to click anything, unless you want to edit.

Name and all other personal info
Dispensing apps used
Areas willing to work in
Registered with which pharmacy groups
etc


They must all be selected from lookups to assure correct spelling as opposed to typing info in free hand with the inevitable spelling mistakes.


Basically I think you are struggling because you have not designed your database correctly yet.

Cheers
Bruce
[/quote]

[bshields]

Hi Johan,

I'm with Bruce on this.

It might be tempting to keep your database design "simple" to make working with it easier.

But, this will bite you in the end.

Its best to design your database based on how the data exists and interacts in the real world.

Sometimes I use triggers to store data in a redundant fashion to make programming easy or for speed requirements (but rarely).

The screen example I showed was implementing a M<->M relationship.

The theme is based on bootstrap but wrapped in an Admin style template.

Regards
Bill

[Bruce]

>> when you browse the locum table (and column search) you can see everything at a glance. Without having to click anything, unless you want to edit.

I'm not sure how doing the correct database design would prevent the above?

cheers
Bruce