You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have hit a limitation with the ggplot2 graphics. There are some graphs where the code provided is more complicated than is possible - at least for me - using the dialogues. Here is an example:
Here is an example:
This is a simple example of a presentation bar chart. The code is relatively simple. It is in Chapter 3 of an introductory book on (ggplot2) graphics, written by someone who works for RStudio. It is designed as a problem-solving book, and I would like to be able to solve as many of these problems as possible using R-Instat.
We can already do most things. The problem is the label = part of the command.
If we could type into the control, that would provide a solution. But it adds many problems/risks, so I am assuming we really don't want that option. So, my solution is to add a Script option to the right-click. This then has the following properties:
a) It does something (e.g. colour) to the control, so you know it has been added.
b) If clicked again it reverses. So no harm in trying it.
c) If activated, then it adds something to the code that is generated, e.g. or ..script..
d) It also disables the Ok button.
e) It changes the action of the Script button, so when Script is pressed, then it closes the dialogue.
So, then you have a script to "tweak" and then run.
What do you think? I think it is pretty neat as an idea! It builds on the fact we have To Script, on each dialogue. And it provides a clear indicator that we are keen to make life easy for users, where possible - through click and point. But we are not against the language and want to also make it as easy as possible when the tasks exceed what can be done conveniently through the front-end.
A simpler example (which can be done another way) is here:
The code is here and the problem is how to give the variable ..count.., which can also be given as stat(count), I gather:
And a third is here - this is different, because we should correct it in the dialogues, but I suspect they are sufficiently complicated - and changing - that our menu system will often need to be tweaked.
The problem here is to position the labels correctly. Here is the code:
Our problem is that in the aes's for geom_text we have the option for position, so it can be given as dodge. What we don't (yet) have is the possibility for position = position_dodge(0.9). Now we should add that to the sub-dialogue, but (until we are perfect!) there could always be such instances. Also sometimes being perfect might be more complicated for the user, than occasionally having to tweak a command. I suggest that getting just the right presentation graph - the right visualisation - is where we are likely to appreciate this facility.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have hit a limitation with the ggplot2 graphics. There are some graphs where the code provided is more complicated than is possible - at least for me - using the dialogues. Here is an example:
Here is an example:
This is a simple example of a presentation bar chart. The code is relatively simple. It is in Chapter 3 of an introductory book on (ggplot2) graphics, written by someone who works for RStudio. It is designed as a problem-solving book, and I would like to be able to solve as many of these problems as possible using R-Instat.
The R-code is here:
We can already do most things. The problem is the
label =
part of the command.If we could type into the control, that would provide a solution. But it adds many problems/risks, so I am assuming we really don't want that option. So, my solution is to add a
Script
option to the right-click. This then has the following properties:a) It does something (e.g. colour) to the control, so you know it has been added.
b) If clicked again it reverses. So no harm in trying it.
c) If activated, then it adds something to the code that is generated, e.g. or
..script..
d) It also disables the Ok button.
e) It changes the action of the Script button, so when Script is pressed, then it closes the dialogue.
So, then you have a script to "tweak" and then run.
What do you think? I think it is pretty neat as an idea! It builds on the fact we have
To Script
, on each dialogue. And it provides a clear indicator that we are keen to make life easy for users, where possible - through click and point. But we are not against the language and want to also make it as easy as possible when the tasks exceed what can be done conveniently through the front-end.A simpler example (which can be done another way) is here:
The code is here and the problem is how to give the variable ..count.., which can also be given as stat(count), I gather:
And a third is here - this is different, because we should correct it in the dialogues, but I suspect they are sufficiently complicated - and changing - that our menu system will often need to be tweaked.
The problem here is to position the labels correctly. Here is the code:
Our problem is that in the aes's for geom_text we have the option for position, so it can be given as dodge. What we don't (yet) have is the possibility for
position = position_dodge(0.9)
. Now we should add that to the sub-dialogue, but (until we are perfect!) there could always be such instances. Also sometimes being perfect might be more complicated for the user, than occasionally having to tweak a command. I suggest that getting just the right presentation graph - the right visualisation - is where we are likely to appreciate this facility.Beta Was this translation helpful? Give feedback.
All reactions