Welcome to WebmasterWorld Guest from 220.127.116.11
Forum Moderators: ergophobe
One of our fields will contain group names. There are about 80 different group names. most records will only have one associated group name, but a few records will have 2-4 group names associated with that one record.
In regard to data structure, I had considered using a relational database, but that seemed like overkill. A non-relational database can give us all the functionality we need with just one field. Thre are only fields we need 'last_name', 'first_name', 'groups', and 'comment' fields (plus 'id' and 'date_entered' fields for back end functions).
I'll probably have to split the string with comma delimiter so I can compare it with the approved values. (If you think this is crazy, I'm open to hearing arguments for using a relational database.)
If I use a select (drop-down menu), the menu would be terribly long. So, instead, I'm considering allowing the user to type in the group names, but validate them against the "approved" list of groups.
What do you all think would be the best way to do this? I want maximize usability and minimize errors.
Thanks in advance for any thoughts!
If your single field idea works and you have good methods to extract values when users select multiple groups - then go for it.
As for the issue of usability - before trying to offer suggestions - the main consideration would be the type of user who will be filling out the form.
Are they internal or external? Will they have existing knowledge of the groups? And so on...
Another issue would be whether the group names could be "grouped" in any way (e.g. creating 4 lists of 20 names each)
However even 80 items in a drop-down menu may not be too long - especially if they suit being displayed in some order i.e. alphabetical.
Just look at the size of lists that one uses when selecting 'country' on some forms.
Finally - if you are going to have the user manually enter in the group - and then validate it - perhaps some type of predictive 'on-screen' matching would help.
The idea of allowing user to manually enter the names really depends on their familiarity with the group names and the possibility of errors in their attempts.
Would be a good case of some old fashioned usability testing...
The options will be organized alphabetically, so that'll help users search them. Most of the users will be at least minimally familiar with the categories.
It'd be great if it were possible in a form's select element to show major categories in bold and then indent each category's entries. Can a drop down menu do that?
In terms of categorizing within a select element - using just plain text - you could do something like:
- group a1
- group a2
- group b1
- group b2
- group b3
and so on....
Another idea would be to test out the form using CheckBoxes (yes, 80 of them :)
Actually you might find that this is the most "easy to use, fool proof" approach in terms of usability and reducing error rate.
<option value="">Category A</option>
<option value="a1">- group a1</option>
<option value="a2">- group a2</option>
<option value="">Category B</option>
<option value="b1">- group b1</option>
The problem with it is that there are 'empty' values that a user could select - you'd just need to validate these.
At least this approach keeps things simple - is accessible to most - and can easily be generated from a database list of groups, or manually entered when setting up the form.
Whether it's a preferred approach in terms of usability...
<optgroup label="Category A">
<option value="a1">Group a1</option>
<option value="a2">Group a2</option>
<optgroup label="Category B">
<option value="b1">Group b1</option>
<option value="b2">Group b2</option>
<option value="b3">Group b3</option>