Hiding Structured and Procurement Menus upon opening

[rachelkg]

Hello @rdstern, @N-thony and @Patowhiz,

While I think that it is great that R-Instat offers a wide range of options. I sometimes think this contributes to the program feeling complicated and inaccessible. As such I want to question whether we should hide more of the infrequently used or currently unfinished menus on opening.

I question whether we could hide:

• Model (as i understand it this menu is not really ready for use? Perhaps I am wrong? If it is usable then not)
• Structured (as i understand it this menu is not really ready for use? Perhaps I am wrong? If it is usable then not)
• Procurement (as i understand it this is a specialized menu that is not fully developed.)
• Experiments (as i understand it this is a specialized menu that is not fully developed.)

This is just an idea. If people feel strongly against, I am interested to hear your thoughts. Thanks,

Rachel

[Patowhiz]

Thanks, @rachelkg, for raising this, I completely agree with your points. I brought up a similar issue back in 2019, but it didn’t seem to gain much traction then. It’s great to see someone else sharing the same perspective now.

I’d even go further and suggest eliminating R-specific jargon, like “data frames” and “factors,” from the dialogs. I raised this in 2021, emphasising the importance of simplicity, but that also didn’t resonate much at the time.

If it were up to me, I’d advocate for a setup that’s more contextualised to user needs. For example, there’s a lot of complexity in R-Instat that a typical climate user doesn’t require. Unfortunately, I recognise that the underlying technologies in R-Instat limit the ability to implement such contextualisation.

Looking forward to the day when these ideas can become a reality!

[rachelkg]

Hi @Patowhiz,

Thanks for your response. It is interesting to hear what others, think about enhancing accessibility!

I think R-Instat is in a complex position because it is indented to appeal to many groups and therefore meet diverse needs. For example, while I agree that the use of R jargon can be alienating for beginners; I think it can be useful for those who wish to go on an transition into using scripts and R. How to do meet all these needs without being inaccessible?

I think your idea of contextualised setups is interesting. What do you mean by this? That there might be multiple versions for download by different users? If so, are there any elements of this that you could see working within the current technology?

Thanks,

Rachel

[Patowhiz]

@rachelkg yes, I was referring to creating multiple versions tailored to different user groups. Achieving this would require careful planning and a team of diverse product managers who thoroughly understand the unique needs and operations of each user group. It would also necessitate modularising the core components to ensure they are reusable across different versions.

I believe the current technologies in use could support such modularisation (though I would advocate for diversifying them further). However, the main limitation lies in the resources needed to implement and maintain this approach.

I also agree that catering to diverse needs inherently introduces complexity. This complexity must be managed in a way that minimises learning barriers for users (again a key task for product managers). For example, in meteorological services in developing countries, I think that most staff may never transition to using R (only those that do research). Additionally, I can envision a future where scripting becomes obsolete due to advancements in AI, though that’s a separate discussion.

In the meantime, I still find that the current contextualised menu system is a good balance that aims to address my points above. As you have suggested, we could initially start with improving this concept further.