How to change the page layout so that the long questions in type "matrix" have more width?

[durraniu]

Description

I noticed that the following had no effect on the survey output when specified in survey.qmd:

format: 
  html:
    page-layout: full

Rendering just the survey.qmd does show the layout is applied but the running app does not show the same layout.

[jhelvy]

I'll see if I can reproduce this exact issue where the Quarto layouts aren't preserved when running as the shiny app.

In the meantime, have you tried modifying the size of the questions themselves?

[durraniu]

Thanks. I thought that size option was for the text area question only. I'll try it for matrix questions.

[durraniu]

Update: I tried changing the width. It is "100%" by default so increasing it didn't make any difference. It'd be great if Quarto layouts can be used. Thanks.

[jhelvy]

I did some testing using the custom grid values, and I do see differences appear on the rendered survey. For example, when I use this:

---
format:
  html: 
    grid:
      sidebar-width: 500px
      body-width: 400px
      margin-width: 300px
      gutter-width: 1.5rem
echo: false
warning: false
---

I get a less wide overall body width, but if I change body-width to 600 or 800, I get the same width.

So it seems there is still some max width value that is being set that doesn't respect the same layout as the Quarto layout settings.

Internally, what we're doing is actually rendering the survey.qmd file, then parsing it for the survey html content. In that process, some of the styling must be getting lost, which is related to #234 on the brand.yml settings.

We can keep looking into it, though there may be limits to how much everything transfers into Shiny. The resulting Shiny app may not be able to perfectly preserve the same layout as the static html page that gets rendered.

[durraniu]

Thanks for looking into this. Would it be possible to customize the sd_ui()? Since the output is shiny, UI design could be made easier with shiny settings.
Are you open to contributions? I can look into package internals to see where I can help.

[jhelvy]

Of course! The sd_ui() function renders the survey.qmd file, and otherwise returns a simplistic UI layout with mostly just a single main div that shows the output for each page. If you can find a way to better preserve the rendered html content into the UI, that would be great!

If you're going to try it though, I might suggest waiting just a few days, as we're currently working on some changes to how we handle navigation in a different branch (we're adding previous buttons, per your suggestion). This will also affect things that will be related to this, so to avoid conflicts it might be better to wait on forking until that branch is merged.

[durraniu]

Sure, I'll wait. Thanks.

[jhelvy]

In the meantime, this diagram might be helpful to look at to get a high level sense of what goes on when a survey is launched. And the main sd_ui() function is defined here. You'll see that it eventually calls the render_survey_qmd() function, which calls quarto::quarto_render() to render the survey.qmd file. We also run a lua filter in that rendering process that lives inside the package as well. All of this is used to make sure we include all the resources we might need when parsing the rendered survey.html file and serving the parts inside the shiny app. The issue of trying to preserve all of the attributes in the rendered survey.html file could be anywhere in this whole process: the returned UI code, the lua filter, etc.

[durraniu]

Other than the Quarto page layout, one possible way to handle the column widths in question type "matrix" is to use the <colgroup> element. For example:

sd_question2 <- function(
    id,
    type = NULL,
    label = NULL,
    option = NULL,
    row = NULL,
    question_col_width = "50%",  # NEW parameter
    option_col_width = NULL,      # NEW parameter
    ...
) {
  
  if (type == "matrix") {
    
    # Calculate option column widths if not provided
    if (is.null(option_col_width)) {
      # Distribute remaining width equally among option columns
      remaining_width <- 100 - as.numeric(gsub("%", "", question_col_width))
      option_col_width <- paste0(remaining_width / length(option), "%")
    }
    
    # Create colgroup element
    colgroup <- shiny::tags$colgroup(
      # First column for questions
      shiny::tags$col(style = paste0("width: ", question_col_width, ";")),
      # Remaining columns for options
      lapply(seq_along(option), function(i) {
        shiny::tags$col(style = paste0("width: ", option_col_width, ";"))
      })
    )
    

    header <- shiny::tags$tr(
      shiny::tags$th(""),
      lapply(names(option), function(opt) shiny::tags$th(opt))
    )
    

    rows <- lapply(row, function(q_id) {
      full_id <- paste(id, q_id, sep = "_")
      shiny::tags$tr(
        shiny::tags$td(names(row)[row == q_id]),
        shiny::tags$td(
          colspan = length(option),
          sd_question(
            type = "mc",
            id = full_id,
            label = "",
            option = option,
            direction = "horizontal",
            ...
          )
        )
      )
    })
    

    output <- shiny::div(
      class = "matrix-question-container",
      shiny::tags$label(class = "control-label", label),
      shiny::tags$table(
        class = "matrix-question",
        colgroup,  
        header,
        shiny::tags$tbody(rows)
      )
    )    
   output
  }
}

Here's a simple app that shows the result:

ui <- bslib::page_fluid(
  
  sd_question2(
    question_col_width = "70%",
    type   = "matrix",
    id     = "car_preference",
    label  = "Please indicate your agreement with the following statements.",
    row    = c(
      "I would buy a gasoline car." = "buy_gasoline",
      "I would buy an EV."          = "buy_ev"
    ),
    option = c(
      "Disagree" = "disagree",
      "Neutral"  = "neutral",
      "Agree"    = "agree"
    )
  )
)

server <- function(input, output, session) {
  
}

shiny::shinyApp(ui, server)

[jhelvy]

Is the proposed question_col_width and option_col_width parameter something that would only apply to the matrix type question? I assume so. If so, it might be better to use names that are associated directly with the matrix question type, maybe matrix_question_width and matrix_option_width? I just wouldn't want users to be confused if they changed something called question_col_width and then didn't see any change cause it only affects matrix type questions. We do, for example, already have a width parameter for all other question types.

[durraniu]

I agree with using matrix_question_width and matrix_option_width. Makes more sense and not confusing for the users.

[jhelvy]

This is a good suggestion, do you want to add this to a PR? As with the other issue, I'm still suggesting waiting just a bit longer until we sort out the revisions we're making. Hopefully we can get that all wrapped up this week.

[durraniu]

Yes, I'll wait until you're done and then make a PR. Thanks for the rapid discussion and development.

[jhelvy]

We've now merged our latest round of edits. We have released this as v1.0.0 as with these changes the overall UI is now pretty stable. So if you want to work from a copy of the main branch, now would be a good time.

[durraniu]

Thanks. I'm on it.

[durraniu]

I put the changes in PR #240 for your review.