The shinyuieditor grew out of early experimentation with a grid layout helper app, and in particular out of the recognition of the user value in such an experience.
However, as the foundational layer of the shinyuieditor, the grid editor distances itself from the apps that most users learn to write when they are first learning Shiny. These users are likely to be the primary user base for shinyuieditor and are the users who will most benefit from the editor interface.
Proposal
I propose that the shinyuieditor retain the grid layout interface as an advanced mode for app building, for intermediate users who are ready to learn and use grid and the gridlayout package. In it's typical usage, I propose the shinyuieditor should provide an interface to create apps that more closely resemble the apps we feature in our documentation, learning materials, etc. I do think it's reasonable to nudge users in the direction we are headed, i.e. using bslib::page_*() functions instead of the shiny::*Page() equivalents. I would also recommending prioritizing features with overlapping APIs in both R and Python.
My experience
After my recent experience of teaching the shinyuieditor at a workshop, there are a few things I noticed that make the grid layout interface less effective for the users most likely to benefit from shinyuieditor.
In particular, grid is a core metaphor and concept of the current UI. Any new user approaching the shinyuieditor will have to learn (or look past) some of the language of grid to use the editor effectively.
They'll be required to give grid areas names when creating new columns/rows, most likely without knowing why that's necessary.
They'll also quickly run into questions about how grid columns and rows are sized.
They'll also see components, like grid_card(), grid_card_text() and grid_card_plot(), in the example apps without having much to help contextualize how these are different from other components.
Finally, they end up creating an app that requires a package that is not available on CRAN and is somewhat tangential to the task they set out to accomplish with the shinyuieditor.
The first two items are easy to look past as a new user (maybe I don't need to understand this, I'll just click OK), but the second two are a much bigger problem, imho. gridlayout is certainly a useful package -- it's complimentary to many other packages in the Shiny ecosystem and can be used alongside shiny and bslib -- but it's not directly related to the core value proposition of the shinyuieditor.
To a new user, it's not clear that gridlayout is going to be required learning or why the apps built with the shinyuieditor require gridlayout. As an educator, if you're choosing to teach the shinyuieditor to students you either need to hand-wave over the grid layout aspect or wait until students are ready for grid concepts, which is typically far past the moment where shinyuieditor would have been helpful to new users.
Background
The shinyuieditor grew out of early experimentation with a grid layout helper app, and in particular out of the recognition of the user value in such an experience.
However, as the foundational layer of the shinyuieditor, the grid editor distances itself from the apps that most users learn to write when they are first learning Shiny. These users are likely to be the primary user base for shinyuieditor and are the users who will most benefit from the editor interface.
Proposal
I propose that the shinyuieditor retain the grid layout interface as an advanced mode for app building, for intermediate users who are ready to learn and use grid and the
gridlayoutpackage. In it's typical usage, I propose the shinyuieditor should provide an interface to create apps that more closely resemble the apps we feature in our documentation, learning materials, etc. I do think it's reasonable to nudge users in the direction we are headed, i.e. usingbslib::page_*()functions instead of theshiny::*Page()equivalents. I would also recommending prioritizing features with overlapping APIs in both R and Python.My experience
After my recent experience of teaching the shinyuieditor at a workshop, there are a few things I noticed that make the grid layout interface less effective for the users most likely to benefit from shinyuieditor.
In particular, grid is a core metaphor and concept of the current UI. Any new user approaching the shinyuieditor will have to learn (or look past) some of the language of grid to use the editor effectively.
grid_card(),grid_card_text()andgrid_card_plot(), in the example apps without having much to help contextualize how these are different from other components.The first two items are easy to look past as a new user (maybe I don't need to understand this, I'll just click OK), but the second two are a much bigger problem, imho.
gridlayoutis certainly a useful package -- it's complimentary to many other packages in the Shiny ecosystem and can be used alongsideshinyandbslib-- but it's not directly related to the core value proposition of the shinyuieditor.To a new user, it's not clear that gridlayout is going to be required learning or why the apps built with the shinyuieditor require gridlayout. As an educator, if you're choosing to teach the shinyuieditor to students you either need to hand-wave over the grid layout aspect or wait until students are ready for grid concepts, which is typically far past the moment where shinyuieditor would have been helpful to new users.