Likert scale control in AIM

JonP

In case "Likert scale" is unfamiliar, it is a scale (such as -3 to 3) that is represented/masked by terms (such as Very Weak, Fairly Weak, Somewhat Weak, Neutral, Somewhat Strong, Fairly Strong, Very Strong).

Generally when creating a control for a Likert scale, you have a masking array that looks something like this: {-3:Very Weak, -2:Fairly Weak, -1:Somewhat Weak, 0:Neutral, 1:Somewhat Strong, 2:Fairly Strong, 3:Very Strong}.

But AIM's combo-box, radio button and slider controls don't seem to allow either negative numbers in choices/ranges for a number attribute or an array to represent/mask numbers.

So it would seem my only option is to create two attributes for every Likert scale:

A plain text with a combo-box or radio button widget with the Likert terms as choices.
A number that I don't include on the form.

I then create a WAS CHANGED TO rule that updates the number attribute with whatever the text attribute was changed to.

If that's what I have to do, then that's what I have to do, but can anyone think of a more elegant solution?

PointsWell

Instead of using direct text in combo boxes how about using references to another BO

BO Likert
Likert.scale = -3, -2, -1
Likert.text = V Weak, Weak etc

You can then show the scale and text in the referencing field.

tford

Instead of using direct text in combo boxes how about using references to another BO

BO Likert
Likert.scale = -3, -2, -1
Likert.text = V Weak, Weak etc

You can then shortcut the number scale into the BO where you need it.

JonP

Thanks guys, I hadn't thought of that and it's worth considering. The advantages include:

Easier to implement.
I can set up alternative Likerts to choose from as well as allow custom Likerts (though the corner cases could be a headache).

But I'm hesitant to go that route for 3 reasons:

There would be a performance penalty, both in taking the survey and calculating the results.
That adds another relationship, which could cause problems for me down the road given AIMs SQL limitations (flatter is better).
I will be implementing the locale feature (AIM is awesome in this respect) and I don't want to store terms as data, which I would think would make implementing that feature more problematic.

PointsWell

But I'm hesitant to go that route for 3 reasons:

There would be a performance penalty, both in taking the survey and calculating the results.

That adds another relationship, which could cause problems for me down the road given AIMs SQL limitations (flatter is better).

I will be implementing the locale feature (AIM is awesome in this respect) and I don't want to store terms as data, which I would think would make implementing that feature more problematic.

Depending on how large your survey is and how complex your questions are you may be creating a rod to beat yourself with later on - maintaining the option lists and then maintaining the code to update two fields.

If there is a multilingual requirement (and assuming the the issue of greatest importance is the score (i.e. you are not going to try to find all answers based on the answer key) then you can overcome the multilingual aspect by use of an additional attribute on the Likert.BO.

BO - Likert
Likert.scale
Likert.text
Likert.locale

There is a record overhead with this approach in that your Likert records will grow at a linear rate: 10 records per language would require 30 records for a 3 language implementation.

You can then filter the values within the field based locale (assuming you can capture locale as an attribute on the LIRU or elsewhere). I'd build a query and then reuse that across the questions that you are using likert scales on. And as you mentioned you get the added benefit of being able to generate a scale of -10 to 10 and use variations of that so -5 to 5 on one question and -10 to 10 on another while only having one list to maintain.

This doesn't obviously cover your performance concern - though if you are only using single step references then it shouldn't be too bad.

I'm not sure what you mean by the SQL limitations of AIM (other than you can't write direct SQL anymore) - generally complex relationships are manageable either via subqueries or by breaking up the search over multiple process steps and for the super complex you can always use a stored procedure call.

I'd say the maintenance risk and testing effort of repeated use of text fields exceeds the performance issue, but I say that with the luxury of ignorance as to what you are doing.

JonP

...I say that with the luxury of ignorance as to what you are doing.

You and me both. :mrgreen:

What's so exciting about locale is that I can adapt my app to address different industries as well as languages. I expect that option list to grow substantially and because I'm lazy, I want to be able to just send out a spreadsheet to a customer or industry/language expert and then import the results. If I go the Likert BO route, I have to send out 2 whole spreadsheets and come up with an import process for the Likert data. Did I mention I'm lazy? 😃

With regard to SQL limitations, I was referring to the open issues listed in the user guide appendix. I'm probably mixing terms. Without knowing stored procedures (which I haven't yet learned), those issues have gotten me into trouble, so I'm a little gun-shy about adding BO complexity.

Thanks so much for your generous input. It's given me a lot to chew on.