Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hiding Structured and Procurement Menus upon opening #9268

Open
rachelkg opened this issue Nov 20, 2024 · 5 comments · Fixed by #9298
Open

Hiding Structured and Procurement Menus upon opening #9268

rachelkg opened this issue Nov 20, 2024 · 5 comments · Fixed by #9298
Assignees

Comments

@rachelkg
Copy link
Contributor

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
Copy link
Contributor

Patowhiz commented Nov 21, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor

@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.

@rachelkg
Copy link
Contributor Author

rachelkg commented Dec 2, 2024

@Patowhiz Thanks for your reply. The idea of modulization is interesting. I wonder if we could apply it somewhat in the documentation. We often struggle to appeal to everyone, but now I wonder it it might sometimes be better to slip options into parallel activity options. Good food for thought. Thanks!

@rdstern
Copy link
Collaborator

rdstern commented Dec 19, 2024

@N-thony I am re-opening, because I suggest the changes now work too well! So they work fine, but we now always start with Climatic shown and the other Optional Menus hidden. I would like us to be able to change them - as we can, but then those changes remain remembered the next time R-Instat is opened. @MeSophie is that something you can do easily? Otherwise maybe Derrick can?

Note it should also work for Climatic, i.e. if you chose to hide Climatic, then is would be hidden initially the next time you open R-Instat.

@rdstern rdstern reopened this Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants