Skip to content

Convert Matrix to Group View: Table; Page to Group View: Page

Right now, code (like relevance statements, apicompose and initialize) are applied to the entire question entity. Unfortunately, this means that we cannot apply code to individual pieces of the matrix question. For groups like Pasa, this has a significant impact on usability, for example:

  1. Some questions must be confirmed answered, even if they are blank. Ex. is in a planting matrix, there is an option to enter a date for termination. However, it's possible termination didn't occur. This, the ideal is to have a required 'did you terminate?' checkbox, and if yes, to show the date and make that date required.
  2. Often, matrix questions can have an overwhelming number of rows. A better design would allow rows to be hidden until the user fills in information to expand them. Ex. In a planting matrix, most plantings don't have seed or seedling treatments. Ideally you would have a checkbox asking 'did you have any seed or seedling treatments' that's required. If it's checked, you can then ask more information about those items.
  3. Another use case example is log events (like mowing) which can occur one time or occur on a schedule (weekly, every other week, etc.). If one time, the user should just enter a single date. If on a schedule, the user should enter start, end, and frequency. Right now, we have 2 separate questions for the same activity - one for single date, one for scheduled dates. This works, but duplicates work and isn't an ideal user experience. Better would be to have a single 'mowing' option in which each row can be specified as 'single' or 'scheduled', specified through a dropdown, which then provides logic to show the appropriate date options.

Direct description of problem (from Serena)

Serena Xu Good morning! I'm seeing a pattern that farmers with overwintered crops like winter wheat or cover crops don't record a termination date. This makes sense since they haven't terminated the crop yet, but we need to know that this is the case. Right now we just provide a termination date field which is not required. One option is to make termination date required and tell them to use 12/31 for unterminated crops but that might be confusing. Have you seen any better solutions? gbathree Well - the way the survey is designed that they would add a termination date in the following year's survey. That's why we ask that initial question about 'where there any crops from last year that weren't terminated yet' or, alternatively, they could enter a future termination date if they know they'll terminate later in the winter (after they complete the survety) Serena Xu The problem is it's hard to tell if they left it out because they forgot/don't know gbathree ah ha the old blank vs. NA problem Serena Xu ya it'd be cool if they could choose not terminated instead of a date, but i've never seen a combination dropdown/datepicker

Implementation ideas

  1. Make a super simple, no code, matrix specific relevance option for checkbox or dropdown questions only. This would say something like 'if user checks box, show/hide next X questions'. This is probably least effort option.
    • 👎 this is ok for a specific solution, but seems inferior to actually fixing the problem.
  2. Change the way relevance works so that you can return true (as now) or return an object where each individual matrix column is returned as true or false (so like { column_1: true, column_2: false }). We would probably want to design this so it could apply to all other code panes (relevance, initialize, apiCompose, and future items like validate).
  3. ⭐ Maybe we should change the matrix question completely, and consider it actually a view, more like 'Pages'. Maybe even change "Pages" to "Views" and give options for the view type = 'page' or 'spreadsheet'. it's possible we could consolidate 'groups' into this as well where view type = 'none' or something.

Review of Option 3

SurveyStack Survey for testing

  • Most thinking happened in miro board go there
  • ❓ Maybe we could wrap this into a feature request to ensure all question options are visible in the Spreadsheet (matrix) View (currently, some are not available in spreadsheet view).
  • ❓ how would (if at all) this change how the data looks when flattened in the Results page?
  • ❓ review that all current code panes (relevance, initialize, validate, etc.) to ensure that there's no changes needed to the return statement structures, and no failures
  • ❓ do we continue to support the old Matrix view? Or migrate it? Are there failure points there?
    • 📋 IMO migrate, but will take some effort.
    • yes migrate! there would be way too much legacy code to be maintained to keep the matrix alive (@manuel-ch)
  • ❓ what else should we consider updating (improving, refactoring, adding tests, adding schemas?) while we do this work?
  • ❓ I'm sure there's more here... requires fairly significant review
  • ❓ See Task 6 here #318. Does implementing this feature change how that would be designed? I think (?) it probably does... it would mean that a "View" question with the "View Types" option of "Pages" and "Spreadsheet" would also have this "Validate" option which occurs when the user presses the button to add a new row or to click to the next page. Worth reviewing.
  • ❓ need to ensure we know what the design looks like when one row has a column 'turned on' and another does not. I would assume the rows for which relevance = false would show as greyed out or something. This is all pretty custom, but it'd be a great feature IMO.
    • 👍 see miro board for example - seems doable and OK.
  • ❓ what about script question types? How about location? What do they look like?
    • ❓ see miro board for proposed structure. I think this can work, and actually I think there's a set of questions (script, location, map, ...) that will all react the same (popup modal).
  • ❓ how does this affect our ability to add new question types? What new constraints will there be, or how much more effort will it take to add one in the future? Are there ways to design for that.

⭐ Option 3 direct benefits for Pasa are

  • We can now auto-generate "Planting Name" question (using Initialize code) - no need for other custom solutions (like the proposed very custom field/crop/date question).
    • This is a big deal - identified as a significant improvement by Pasa. Avoids a lot of confusion as new plantings aren't organized by their Field, so it's helpful to have the Field name as part of the Planting name.
  • In Planting QS, we can now have a required checkbox for "did you terminate this planting" and if and only if true then show a required Date question. Similar for things like Seed / Seedling treatments (not required, but do reduce messiness for simple data input).
  • Would eliminate the 'did you do X less than 2 times, or more than 2 times' question. Now users could select, row by row, if something occurred only one time or with a frequency.
  • If we did this in the same spring as Task 6 "General Validation or (at a minimum) Matrix Validation" (#318), we would save some time because the dev would have their head in this section of the code and it's possible we could have a slightly more elegant / simpler implementation.

Option 3, general benefits

  • It's more user intuitive. From the user's perspective these are views (pages v. spreadsheets, etc). Also there may be other future views that could be selected.
  • This allows our existing, native code panes to be used with matrix questions without modification (from the user perspective). Obviously there's still work on SurveyStack's end to correctly evaluation js expressions in the spreadsheet 'view' versus a normal 'view'... but from the users perspective it's consistent and works/feels the same (so relevance still just returns true or false, but now it applies either to the appearance of the full question, the question on a page, or the question as a column in the matrix).
  • Most question types right now are effectively duplicated inside Matrix questions. This creates extra code and maintenance. Imagine if the same question types could simply be dragged into a matrix question like in a group - then those UI elements wouldn't be duplicated. Probably also on a more considerate refactor, more code could be saved and simplified.
  • As we move towards truly schematized question types (text, number, date, etc.), this allows question types to be rock solid schemas which look and validate the same everywhere (no more weird custom data implementations in the matrix). This also helps with AI tools for auto-building surveys, auto-populating results, communication between services, etc.
  • It's easier to pull those questions now back out and use them elsewhere if a survey creator wanted to do so.
Edited by Manuel H.